1. 内存泄漏

1.1 什么是内存泄漏

什么是内存泄漏：内存泄漏指因为疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并不是指内存在物理上的消失，而是应用程序分配某段内存后，因为设计错误，失去了对该段内存的控制，因而造成了内存的浪费。

内存泄漏的危害：长期运行的程序出现内存泄漏，影响很大，如操作系统、后台服务等等，出现内存泄漏会导致响应越来越慢，最终卡死。

1.2 内存泄漏分类

C/C++程序中一般我们关心两种方面的内存泄漏：
堆内存泄漏(Heap leak)：
堆内存指的是程序执行中依据须要分配通过malloc / calloc / realloc / new等从堆中分配的一块内存，用完后必须通过调用相应的 free或者delete 删掉。假设程序的设计错误导致这部分内存没有被释放，那么以后这部分空间将无法再被使用，就会产生Heap Leak。

系统资源泄漏：
指程序使用系统分配的资源，比方套接字、文件描述符、管道等没有使用对应的函数释放掉，导致系统资源的浪费，严重可导致系统效能减少，系统执行不稳定。

2. 为什么需要智能指针

我们可以采用RAII思想或者智能指针来管理资源，来避免内存泄漏。

举个例子：

这里有两个new出来的数组，如果new出现了异常，那么就会直接被main函数catch到。如果是第一个出现异常，可以直接被捕捉去。如果是第二个出现异常，被main里面的catch捕捉，那么第一个new就没有办法释放。久而久之，可能就会造成内存泄漏。如果我们把第二个new放到try里面，如果第二个new出现异常，被catch到，但是第二个new失败了，怎么能delete呢？所以这些都不是一个好方法，所以我们需要用到智能指针。

3. 智能指针的使用及原理

3.1 RAII

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

总而言之，获取到资源以后去初始化一个对象，将资料交给对象管理。

这种做法有两大好处：
1.不需要显式地释放资源。
2.采用这种方式，对象所需的资源在其生命期内始终保持有效。

3.2 使用RAII思想设计的SmartPtr类

我们这里把构造函数和析构函数先写出来。我们再去申请资源的时候就用这个类来管理：


在析构函数这里加上一个打印函数。方便我们观察。

不抛异常，可以正常释放。

抛异常也可以正常释放。如果是第一个new出现错误，直接被main里面的catch捕捉，没有事情。如果是第二个new出现错误，也会直接被捕捉，当函数栈帧销毁的时候，这个类会自动调用它的析构函数完成销毁。div()也是一样的道理，如果里面抛了除0错误，那么前面两个就会自动调用析构函数销毁。

3.3 让SmartPtr像指针一样

虽然上面管理了资源，但是我们想使用的时候就不好办了。我们需要让这个类像指针一样去使用：

当我们把解引用和箭头都写上时，我们就可以把这个类当指针一样去使用了。

3.3 SmartPtr的拷贝

举个例子：

因为这里是内置类型，会形成值拷贝，那么析构的时候就会析构两次，发生错误。

那么这里能不能使用深拷贝呢？
答案是：不能的。因为智能指针的目的就是托管我们这个地值的资源，如果你深拷贝了，就不是这部分资源了，所以这里必须是浅拷贝。

下面我们就说一说怎么解决这种问题。

3.4 auto_ptr

C++98版本的库中就提供了auto_ptr的智能指针。

文档链接 auto_ptr的实现原理：管理权转移的思想。

这里sp1被构造出来初始化了，我们再进行下一步。

拷贝构造后，sp1就不能使用了。

auto_ptr拷贝构造的代码实现：

这些解决方法除了拷贝构造的原理不一样，其它的都和SmartPtr类一样。但是这个auto_ptr在日常中不建议使用。

3.5 unique_ptr

在C++11标准库中，出现了一些比较好的解决方法，第一个就是unique_ptr，它包含在< memory >头文件中。

文档链接 unique_ptr的实现原理：不让拷贝。

它就是直接不让你拷贝了。

unique_ptr拷贝构造的代码实现：

方法一：只声明，不实现，并且声明设置成私有。

如果我们不声明，那么编译器会默认生成一个。如果不设置成私有，那么可能会模板特化自己定义。

方法二：在C++11中，声明后加个delete。

但是还没有防死，赋值问题没有解决：

我们还需要把赋值重载给写上：

3.6 shared_ptr

C++11中开始提供更靠谱的并且支持拷贝的shared_ptr。

文档链接 shared_ptr的实现原理：引用计数，记录几个对象管理这块资源，析构的时候- -计数，最后一个析构的对象释放资源。

这里就没有任何问题了。

shared_ptr拷贝构造的代码实现：
那么可能有的人会想用static做一个成员变量来计数：

但是这样是不可以的。

前面两个智能指针应该里面的计数应该是2，第三个智能指针里面的计数是1。但是如果是static，它是所有这个类的对象共用一个，所以会出现问题。

正确的解决办法：

我们用指针来指向动态开辟的空间，当有新的智能指针时，我们就new一个。

拷贝构造的时候，我们将需要拷贝的对象的pCount拷贝过来++一下。

析构的时候，当里面为最后一个时候，把空间都给释放掉。

我们可以演示一下：

可以看到前面两个的pCount是2，第三个是1，这些都是没有问题的。

但是我们还需要处理赋值情况：

赋值情况就会出现问题，该加加没有加加，该减减的没有减减。

代码实现：

首先，自己就不需要给自己赋值了，那么我们可以这样去写：

不过这样写还是存在一些问题：

	sp1 = sp1;//可以避免sp1 = sp2;//不可以避免

因为sp2虽然不是和sp1同一个，但是它们的指向空间是同一个，所以第二个防不住，但是不会造成问题，只是没有作用。我们可以直接比较_ptr：

然后我们需要将this的对象进行减减，sp的对象进行加加。

这样还是不行：

	sp1 = sp3;sp2 = sp3;

如果是这种情况，那么原来sp1和sp2指向的空间没有指针去管理了，会造成内存泄漏。

所以我们需要把析构这个部分给加上，如果原来的pCount为0，就把这段空间销毁。

3.6.1 shared_ptr的循环引用

举个例子：

这是我们平时的一种简单用法，如果我们改成智能指针的话：

但是这里出现了问题：node1->_next和node1->_prev是原生指针，而node1和node2是一个指针指针对象，不能相互赋值。
我们需要将上面的也改成智能指针：

虽然编译可以通过，但是不能析构了。

循环引用分析：
1.node1和node2两个智能指针对象指向两个节点，引用计数变成1，我们不需要手动delete。

2. node1的_next指向node2，node2的_prev指向node1，引用计数就会变成2。

3. node1和node2析构，引用计数减到1，但是_next还指向下一个节点。但是_prev还指向上一个节点。

4. 此时的情况是：_next析构了，右边结点才能释放，_prev析构了，左边结点才能释放。所以这就叫循环引用，谁也不会释放。

解决方法如下。

3.6.2 weak_ptr

文档链接 原理就是：node1->_next = node2和node2->_prev = node1时weak_ptr的_next和_prev不会增加node1和node2的引用计数。

weak_ptr其实就是为了辅助shared_ptr，它不参与资源管理。

模拟实现代码：
因为weak_ptr不参与资源管理，所以它不是RAII，我们不需要pCount和析构函数：

最重要的是能够拷贝构造shared_ptr。那么赋值也是一样的道理。

我们只需要指向这段空间，不需要加计数了。

3.7 定制删除器

前面模拟实现的都是new出来的，如果是malloc或者是new []这样的方式，可能就会报错，这里设计了一个删除器来解决这个问题。

举个例子：


这里报错的原因是：delete和new []不匹配。平时我们用的unique_ptr/shared_ptr 默认释放资源用的delete。

如何匹配申请方式去对应释放呢？
答案是：用仿函数来做。

运行结果如下：

其它开辟空间的方式也可以用这样的方法：

shared_ptr虽然和unique_ptr原理类似，但是也有一点区别：

unique_ptr是类模板参数传参，而shared_ptr是构造函数时传参，一个传类型，一个传对象。传对象时，我们用lambda表达式比较方便。

完善unique_ptr和shared_ptr：


但是shared_ptr不能改造，因为标准库里实现的太复杂了。