智能指针

前面的文章中我们介绍了C++中的异常有关的知识点，同时在其中我们遇到了有关内存方面的问题，如下所示：

int div() {
	int a, b;
	cin >> a >> b;
	if (b == 0)
	throw invalid_argument("除0错误");
	return a / b;
}
void Func() {
	// 1、如果p1这里new 抛异常会如何？
	// 2、如果p2这里new 抛异常会如何？
	// 3、如果div调用这里又会抛异常会如何？
	int* p1 = new int;
	int* p2 = new int;
	cout << div() << endl;
	delete p1;
	delete p2;
}
int main() {
	try {
		Func();
	}
	catch (exception& e) {
	cout << e.what() << endl;
	}
	return 0;
}

在上述的代码中如果出现了除零的异常，那么对于new出来的指针p1和p2资源的处理就会非常的麻烦，很容易就会造成内存泄漏。

内存泄漏

什么是内存泄漏，内存泄露的危害

什么是内存泄漏：内存泄漏指因为疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并不是指内存在物理上的消失，而是应用程序分配某段内存后，因为设计错误，失去了对该段内存的控制，因而造成了内存的浪费。
内存泄漏的危害：长期运行的程序出现内存泄漏，影响很大，如操作系统、后台服务等等，出现内存泄漏会导致响应越来越慢，最终卡死。

内存泄漏分类

C/C++程序中一般我们关心两种方面的内存泄漏：

堆内存泄漏(Heap leak)
堆内存指的是程序执行中依据须要分配通过malloc / calloc / realloc / new等从堆中分配的一块内存，用完后必须通过调用相应的 free或者delete 删掉。假设程序的设计错误导致这部分内存没有被释放，那么以后这部分空间将无法再被使用，就会产生Heap Leak。
系统资源泄漏
指程序使用系统分配的资源，比方套接字、文件描述符、管道等没有使用对应的函数释放
掉，导致系统资源的浪费，严重可导致系统效能减少，系统执行不稳定。

如何检测内存泄漏

关于这部分的内容本文不做过多的叙述，详情可以参考下面的文章：

在linux下内存泄漏检测：linux下几款内存泄漏检测工具
在windows下使用第三方工具：VLD工具说明
其他工具：内存泄漏工具比较

内存泄漏非常常见，解决方案分为两种：

事前预防型。如智能指针等
事后查错型。如泄漏检测工具等

在本文中我们就将讲述有关智能指针有关的知识点。

智能指针的使用即原理

RAII

RAII（Resource Acquisition Is Initialization）是一种利用对象生命周期来控制程序资源（如内
存、文件句柄、网络连接、互斥量等等）的简单技术。
在对象构造时获取资源，接着控制对资源的访问使之在对象的生命周期内始终保持有效，最后在对象析构的时候释放资源。借此，我们实际上把管理一份资源的责任托管给了一个对象。这种做法有两大好处：

不需要显式地释放资源。
采用这种方式，对象所需的资源在其生命期内始终保持有效

下面我们就根据上述的思想来简单的设计一下智能指针：

template<class T>
class SmartPtr {
public:
	SmartPtr(T* ptr = nullptr)
		: _ptr(ptr)
	{}
	T& operator*() {return *_ptr;}
	T* operator->() {return _ptr;}
	~SmartPtr() {
		cout << "delete:" << _ptr << endl;
		delete _ptr;
	}
private:
	T* _ptr;
};

上述的就是一个简单的有着RAII思想的智能指针类，同时具有着像指针一样的行为。但是这个类有着一个问题就是如果遇到这样的情况SmartPtr<int> sp3(sp1);上述实现的类是一个浅拷贝的类，那么就会有两个智能指针指向同一块区域的情况出现，对于指针来说需要的就是浅拷贝，但是在这里智能指针需要管理资源的释放，不能是单纯的浅拷贝。

总结一下智能指针的原理:

RAII特性
重载operator*和operator->，具有像指针一样的行为

std::auto_ptr

C++98版本的库中就提供了auto_ptr的智能指针。下面演示的auto_ptr的使用及问题。
auto_ptr的实现原理：管理权转移的思想

template<class T>
class auto_ptr
{
public:
	auto_ptr(T* ptr) :_ptr(ptr)
	{}
	~auto_ptr() {
		if (_ptr) {
			cout << "delete:" << _ptr << endl;
			delete _ptr;
		}
	}
	// 管理权转移
	auto_ptr(auto_ptr<T>& ap) :_ptr(ap._ptr) {
		ap._ptr = nullptr;
	}
	T& operator*() {
		return *_ptr;
	}
	T* operator->() {
		return _ptr;
	}
private:
	T* _ptr;
};
void test_auto(){
	auto_ptr<int> ap1(new int(1));
	auto_ptr<int> ap2(ap1);

	*ap1 = 1; // 管理权转移以后导致ap1悬空，不能访问
	*ap2 = 1;
}
// auto_ptr虽然实现了管理权的转移，但是同样也会导致有旧的指针悬空的问题。设计的不是很理想。

std::unique_ptr

在C++11中开始提供更加靠谱的unique_ptr；
unique_ptr的实现原理：简单粗暴地防拷贝。

template<class T>
class unique_ptr {
public:
	unique_ptr(T* ptr) :_ptr(ptr)
	{}
	~unique_ptr() {
		if (_ptr) {
			cout << "delete:" << _ptr << endl;
			delete _ptr;
		}
	}
	T& operator*() {
		return *_ptr;
	}
	T* operator->() {
		return _ptr;
	}
	// 针对防拷贝在C++98和C++11中有着不同的方法
	
	// C++11思路：语法直接支持
	unique_ptr(const unique_ptr<T>& up) = delete;
	unique_ptr<T>& operator=(const unique_ptr<T>& up) = delete;
	
	// C++98思路：将拷贝构造与赋值重载函数卸载private:中，并且只证明不实现
	// 拷贝构造和赋值是默认成员函数，我们不写会自动生成，所以我们必须写
	// 只声明不实现，但是用的人可能会在外面强行定义，所以再加一条，声明为私有
private:
	// unique_ptr(const unique_ptr<T>& up);
	// unique_ptr<T>& operator=(const unique_ptr<T>& up);
private:
	T* _ptr;
};
void test_unique() {
	unique_ptr<int> up1(new int(1));
	//unique_ptr<int> up2(up1);
}

std::shared_ptr

C++11中开始提供更靠谱的并且支持拷贝的shared_ptr；
shared_ptr的原理：是通过引用计数的方式来实现多个shared_ptr对象之间共享资源。

shared_ptr在其内部，给每个资源都维护了着一份计数，用来记录该份资源被几个对象共享；
在对象被销毁时(也就是析构函数调用)，就说明自己不使用该资源了，对象的引用计数减一；
如果引用计数是0，就说明自己是最后一个使用该资源的对象，必须释放该资源；
如果不是0，就说明除了自己还有其他对象在使用该份资源，不能释放该资源，否则其他对象就成野指针了。

使用引用计数就可以支持多个智能指针指向同一个资源，最后一个对象释放资源。

template<class T>
class shared_ptr
{
public:
	shared_ptr(T* ptr = nullptr) :_ptr(ptr), _pcount(new int(1))
	{}

	~shared_ptr() {
		Release();
	}

	void Release() {
		if (--(*_pcount) == 0) {
			if (_ptr) {
				cout << "delete:" << _ptr << endl;
				delete _ptr;
				delete _pcount;
				_del(_ptr);
			}
		}
	}
	void AddCount(){
		++(*_pcount);
	}

	shared_ptr(const shared_ptr<T>& sp) :_ptr(sp._ptr), _pcount(sp._pcount) {
		AddCount();
	}
	shared_ptr<T>& operator=(const shared_ptr<T>& sp) {
		if (_ptr != sp._ptr) { // 管理的资源的地址是一致的
			Release();
			_ptr = sp._ptr;
			_pcount = sp._pcount;
			AddCount();
		}
		return *this;
	}

	T& operator*() {
		return *_ptr;
	}
	T* operator->() {
		return _ptr;
	}
	T* get() const {
		return _ptr;
	}
	int use_count() {
		return *_pcount;
	}
private:
	T* _ptr;
	int* _pcount;
};

上述的代码就是一个简单的shared_ptr的代码，有一个指针_ptr，还有一个用于记录数据的_pcount，这里不能使用int作为类型，而要使用int*，因为当多个智能指针指向同一块资源时_pcount只需要有一份，要让不同的智能指针的_pcount是同一个。当有又一个新的智能指针要指向已经生成的智能指针时，就需要让(*_pcount)++，当需要将智能指针进行释放的时候就执行--(*_pcount)指令，然后判断其中的值是否等于0，若是等于0就需要释放空间。

另外需要注意的就是赋值重载的问题，一下其中可能会遇到的问题：

shared_ptr<int> sp1(new int(1));
shared_ptr<int> sp2(sp1);
shared_ptr<int> sp3(sp2);
shared_ptr<int> sp4(new int(10));
//sp1 = sp4; // 引用计数为1的智能指针赋给引用计数大于1的智能指针
sp4 = sp1; // 引用计数大于1的智能指针赋给引用计数为1的智能指针
sp1 = sp1; // 自己赋给自己 使用_pcount作为判断依据，因为指向同一块资源的引用计数一定是一致的
sp1 = sp2; // 自己赋给自己

shared_ptr<T>& operator=(const shared_ptr<T>& sp) {
	if (_ptr != sp._ptr) { // 管理的资源的地址是一致的
		Release();
		_ptr = sp._ptr;
		_pcount = sp._pcount;
		AddCount();
	}
	return *this;
}

shared_ptr的线程安全问题

上面我们编写的shared_ptr的代码，当有多线程访问的时候并不是线程安全的，因此需要我们对引用计数的加减操作进行加锁。

template<class T>
class shared_ptr
{
public:
	shared_ptr(T* ptr = nullptr) :_ptr(ptr), _pcount(new int(1)), _pmtx(new mutex)
	{}
	void Release() {
		_pmtx->lock();
		bool deleteFlag = false;
		if (--(*_pcount) == 0) {
			if (_ptr){
				cout << "delete:" << _ptr << endl;
				delete _ptr;
			}
			delete _pcount;
			deleteFlag = true;
		}
		_pmtx->unlock();
		if (deleteFlag == true) {
			delete _pmtx;
		}
	}
	void AddCount(){
		_pmtx->lock();
		++(*_pcount);
		_pmtx->unlock();
	}

	shared_ptr(const shared_ptr<T>& sp) :_ptr(sp._ptr), _pcount(sp._pcount), _pmtx(sp._pmtx) {
		AddCount();
	}
	shared_ptr<T>& operator=(const shared_ptr<T>& sp) {
		if (_ptr != sp._ptr) { // 管理的资源的地址是一致的
			Release();
			_ptr = sp._ptr;
			_pcount = sp._pcount;
			_pmtx = sp._pmtx;
			AddCount();
		}
private:
	T* _ptr;
	int* _pcount;
	mutex* _pmtx;
};

在对引用计数进行–操作加锁的时候会遇到问题：

void Release() {
	_pmtx->lock();
	bool deleteFlag = false;
	if (--(*_pcount) == 0) {
		if (_ptr){
			cout << "delete:" << _ptr << endl;
			delete _ptr; // 这里在进行资源释放的时候不能在加锁的情况下直接将锁进行释放，但是我们又不能不对锁进行释放，此时我们可以设置一个bool变量用来记录引用计数的情况，如果引用计数的值归零，那么就将标志位置为true，将其余的资源释放结束之后，再进行判断是否需要释放锁资源。
			delete _pcount;
			deleteFlag = true;
		}
	}
	_pmtx->unlock();
	if (deleteFlag == true) {
		delete _pmtx;
	}
}

当我们进行完加锁之后，shared_ptr 本身是线程安全的，因为计数是加锁保护的。
但此时会有一个新的问题就是：shared_ptr 管理的对象并不是线程安全的，因此在使用智能指针管理对象的时候，有时也需要进行加锁：

void SharePtrFunc(zyq::shared_ptr<Date>& sp, size_t n, mutex& mtx) {
	//cout << sp.get() << endl; // 可以得到sp与线程传入的p的地址是不一样的
	for (size_t i = 0; i < n; ++i) {
		// 这里智能指针拷贝会++计数，智能指针析构会--计数，这里是线程安全的。
		zyq::shared_ptr<Date> copy(sp);

		mtx.lock(); // 这里如果不进行加锁就会出现线程安全问题
		sp->_day++;
		sp->_month++;
		sp->_year++;
		mtx.unlock();
	}
}

void test_shared_safe() {
	zyq::shared_ptr<Date> p(new Date);
	// cout << p.get() << endl;
	const size_t n = 100000;
	mutex mtx;
	thread t1(SharePtrFunc, ref(p), n, ref(mtx)); // ref 作用是让变量是引用传递 线程对象传递的时候直接传会发生报错，会认为是传值传参
	thread t2(SharePtrFunc, ref(p), n, ref(mtx)); // 首先传给线程的构造函数,然后再将变量传递给SharePtrFunc, 可以得到在这这里的p与上面的sp的地址是不同的
	t1.join();
	t2.join();
	cout << p->_day << endl;
	cout << p->_month << endl;
	cout << p->_year << endl;
	cout << p.use_count() << endl;
}

shared_ptr的循环引用的问题

下面我们来看一段代码：

struct ListNode
{
	int _data;
	shared_ptr<ListNode> _prev;
	shared_ptr<ListNode> _next;
	~ListNode(){ cout << "~ListNode()" << endl; }
};
int main()
{
	shared_ptr<ListNode> node1(new ListNode);
	shared_ptr<ListNode> node2(new ListNode);
	cout << node1.use_count() << endl;
	cout << node2.use_count() << endl;
	
	node1->_next = node2;
	// node2->_prev = node1;
	
	cout << node1.use_count() << endl;
	cout << node2.use_count() << endl;
	
	return 0;
}

之前我们编写过链表的相关结构，上文中给出了一个ListNode，按照之前的写法我们可以直接使用ListNode作为_next和_prev的类型，这可以正常的进行资源的释放。现在我们想要使用智能指针来构建链表，但是只有外部的节点使用智能指针是不够的，不能进行链接，那么就需要将内部也变为shared_ptr的类型，当我们将两个节点进行链接的时候，此时就会产生问题，程序结束时这个链表无法正常的释放资源，当我们使用库中的shared_ptr时也会有这样的问题，这就说明并不是我们代码编写的问题，而是逻辑的问题。这个问题就被称为循环引用。
下面就是循环引用的示意图：
在这里插入图片描述
但是当我们屏蔽掉任意的一句链接代码的时候就可以正确的进行释放资源。以第二张图作为例子，当n2j=进行析构的时候，由于还有n1的_next结点对其进行管理，那么此时引用计数就会–变为1，然后n1的节点进行析构，因为其中_next也是shared_ptr类型的，那么此时因为引用计数为1，再次–就会变为0，然后进行资源的释放，最后对n1进行资源的释放，这样就将资源完全释放了。第三张图也就是循环引出现的问题可以这样解释：两个链表的节点相互进行链接，这样引用计数就变为了2，当进行析构的时候按照上述的代码，先对n2智能指针进行析构，但是n2的空间并不能释放，因为还有着n1的_next指针管理着这个空间，这对于n1来说也是一样的，因此上述的情况就变为了n1的_next约束着n2的空间，n2的_prev约束着n1的空间，两者相互钳制，导致无法进行释放，引发内存泄漏。
针对上述的的问题，我们就设计出来了weak_ptr，weak_ptr与shared_ptr相类似，但是不会增加引用计数。weak_ptr不支持RAII，可以指向资源，但是他不参与管理，不增加引用计数。

template<class T>
class weak_ptr
{
public:
	weak_ptr() :_ptr(nullptr)
	{}
	weak_ptr(const shared_ptr<T>& sp) :_ptr(sp.get())
	{}
	T& operator*() {
		return *_ptr;
	}
	T* operator->() {
		return _ptr;
	}
	T* get() {
		return _ptr;
	}
private:
	T* _ptr;
};

智能指针的删除器

上述我们将的shared_ptr都只是new出来一个对象，那么如果我们使用malloc创建对象，又或者new出来的是一个数组，又或者是使用的打开文件的操作，想要自动关闭文件，面对这些不同的释放资源的环境，该怎么办呢？官方就给我们提供了一种解决方案：
template <class U, class D> shared_ptr (U* p, D del);
在函数的参数中传入一个删除对象，通过对删除对象传入不同的方法，即可完成资源的释放。结合我们之前学习过的包装器，我们就可以使用包装器对不同的处理方案进行统一的管理。

// 可以传入仿函数对象
template<class T>
struct DeleteArray {
	void operator()(T* ptr) {
		cout << "void operator()(T* ptr)" << endl;
		delete[] ptr;
	}
};

// 在shared_ptr中封装包装器
template<class T>
class shared_ptr
{
public:
	shared_ptr(T* ptr = nullptr)
		:_ptr(ptr)
		, _pcount(new int(1))
		, _pmtx(new mutex)
	{}

	template<class D>
	shared_ptr(T* ptr, D del)
		:_ptr(ptr)
		, _pcount(new int(1))
		, _pmtx(new mutex)
		, _del(del)
	{}

private:
	// 构建默认针对指针的删除器，同时可以接收不同的对象
	function<void(T*)> _del = [](T* ptr) {
		cout << "lambda delete:" << ptr << endl;
		delete ptr;
	};
};

C++11和boost中智能指针的关系

C++ 98 中产生了第一个智能指针auto_ptr.
C++ boost给出了更实用的scoped_ptr和shared_ptr和weak_ptr.
C++ TR1，引入了shared_ptr等。不过注意的是TR1并不是标准版。
C++ 11，引入了unique_ptr和shared_ptr和weak_ptr。需要注意的是unique_ptr对应boost的scoped_ptr。并且这些智能指针的实现原理是参考boost中的实现的。