目录
1、我们为什么需要智能指针？
2、内存泄露
2.1 什么是内存泄漏，内存泄漏的危害
2.2如何避免内存泄漏
总结一下:
3.智能指针的使用及原理
3.1 RAII
3.2关于深拷贝和浅拷贝更深层次的理解：
3.3 std::auto_ptr
3.4 std::unique_ptr
引用计数的原理：
原码：
很坑的赋值重载函数
智能指针的缺陷：（循环引用）
解决方案：
1、我们为什么需要智能指针？
下面我们先分析一下下面这段程序有没有什么内存方面的问题？
解析：
这里如果是p1的new抛异常了 那么首先p1是申请空间失败的 然后程序跳转到异常处理机制，如果main函数中没有对异常捕捉，那么程序就终止了。
如果是p2的new抛异常了 那么大体和p1抛异常一样。区别在于p1这个指针申请的空间就会内存泄漏，因为p1已经申请成功了但是由于抛异常下面的delete语句不再执行！
div抛异常也一样 只不过这个时候p1和p2开辟的空间都会造成内存泄漏！
2、内存泄露
2.1 什么是内存泄漏，内存泄漏的危害
什么是内存泄漏：内存泄漏指因为疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并不是指内存在物理上的消失，而是应用程序分配某段内存后，因为设计错误，失去了对该段内存的控制，因而造成了内存的浪费。
内存泄漏的危害：长期运行的程序出现内存泄漏，影响很大，如操作系统、后台服务等等，出现内存泄漏会导致响应越来越慢，最终卡死。
void MemoryLeaks()
{
// 1.内存申请了忘记释放
int* p1 = (int*)malloc(sizeof(int));
int* p2 = new int;
// 2.异常安全问题
int* p3 = new int[10];
Func(); // 这里Func函数抛异常导致 delete[] p3未执行，p3没被释放.
delete[] p3;
}2.2如何避免内存泄漏
1. 工程前期良好的设计规范，养成良好的编码规范，申请的内存空间记着匹配的去释放。ps：
这个理想状态。但是如果碰上异常时，就算注意释放了，还是可能会出问题。需要下一条智能指针来管理才有保证。
2. 采用RAII思想或者智能指针来管理资源。
3. 有些公司内部规范使用内部实现的私有内存管理库。这套库自带内存泄漏检测的功能选项。4. 出问题了使用内存泄漏工具检测。ps：不过很多工具都不够靠谱，或者收费昂贵。
总结一下:
内存泄漏非常常见，解决方案分为两种：1、事前预防型。如智能指针等。2、事后查错型。如泄漏检测工具。
3.智能指针的使用及原理
3.1 RAII
RAII（Resource Acquisition Is Initialization资源立即初始化）是一种利用对象生命周期来控制程序资源（如内存、文件句柄、网络连接、互斥量等等）的简单技术。
在对象构造时获取资源，接着控制对资源的访问使之在对象的生命周期内始终保持有效，最后在对象析构的时候释放资源。借此，我们实际上把管理一份资源的责任托管给了一个对象。这种做法有两大好处：
- 不需要显式地释放资源。
- 采用这种方式，对象所需的资源在其生命期内始终保持有效。
所以我们把资源的获取和释放交给了一个智能指针类，让这个类帮我们完成，所以就不需要关心会报错异常导致内存泄漏的问题。并且这个类还得需要将* 、->重载下，才可让其像指针一样去使用。
原码：
template<class T>
class SmartPtr {
public:
SmartPtr(T* ptr = nullptr)
: _ptr(ptr)
{}
~SmartPtr()
{
if(_ptr)
delete _ptr;
}
T& operator*() {return *_ptr;}
T* operator->() {return _ptr;}
private:
T* _ptr;
};总结一下智能指针的原理：
- RAII特性
- 重载operator*和opertaor->，具有像指针一样的行为。
3.2关于深拷贝和浅拷贝更深层次的理解：
vector/list……采用深拷贝的原因：利用资源存储管理数据，资源是自己的，拷贝时，每个对象各自一份资源，各管各的，所以深拷贝。
智能指针/迭代器……采用浅拷贝的原因：本质资源不是自己的，代为持有，方便访问修改数据。他们拷贝的时候期望指向同一个资源，所以浅拷贝！
3.3 std::auto_ptr
C++98版本的库中就提供了auto_ptr的智能指针。下面演示的auto_ptr的使用及问题。
template<class T>
class auto_ptr
{
public:
// RAII
auto_ptr(T* ptr)
:_ptr(ptr)
{}
// ap2(ap1)
auto_ptr(auto_ptr<T>& ap)
{
_ptr = ap._ptr;
ap._ptr = nullptr;
}
~auto_ptr()
{
cout << "delete:" << _ptr << endl;
delete _ptr;
}
// 像指针一样
T& operator*()
{
return *_ptr;
}
T* operator->()
{
return _ptr;
}
private:
T* _ptr;
};
auto_ptr 管理权转移，被拷贝对象把资源管理权转移给拷贝对象，导致被拷贝对象悬空！
注意拷贝过后不能访问被拷贝对象，否则就出现空指针了。很多公司禁止使用它，因为他很坑！
3.4 std::unique_ptr
C++11中开始提供更靠谱的unique_ptr
unique_ptr的实现原理：简单粗暴的防拷贝，禁止拷贝，简单粗暴，适合于不需要拷贝的场景。下面简化模拟实现了一份UniquePtr来了解它的原理
template<class T>
class unique_ptr
{
public:
// RAII
unique_ptr(T* ptr)
:_ptr(ptr)
{}
// ap2(ap1)
//直接将拷贝函数和复制重载函数不实现，赋值为delete
unique_ptr(const unique_ptr<T>& ap) = delete;
unique_ptr<T>& operator=(const unique_ptr<T>& ap) = delete;
~unique_ptr()
{
cout << "delete:" << _ptr << endl;
delete _ptr;
}
// 像指针一样
T& operator*()
{
return *_ptr;
}
T* operator->()
{
return _ptr;
}
private:
T* _ptr;
};3.5 std::shared_ptr
C++11中开始提供更靠谱的并且支持拷贝的shared_ptr
那我们如何才能支持拷贝呢？
我们采取使用引用计数的方式来解决。记录有几个对象参与管理这个资源。
可以直接采用count整形直接++吗？
不可以，我们这里要求每份资源分配一个计数，而这里是每指向一份资源调用的智能指针就分配一个计数，也就是我们要求的是公共计数，而不是每个智能指针单独的计数。
可以采用静态成员变量来解决这个问题吗？
sharedptr 为什么用静态的引用计数不行，因为静态成员属于这个类，属于这个类的所有对象
不可以。因为静态成员属于这个类，属于这个类的所有对象。而我们的需求是每个资源配一个引用计数，而不是全部是一个引用计数。
所以这里只释放了一份资源，另一份资源没有释放
正确的解法是每个对象存一个指向计数的指针，而指针指向的内容只在构造的时候进行初始化构造单独这一份，拷贝的时候，++计数，智能指针析构的时候--计数，只有当引用计数减到0时，才真正释放这份资源！
引用计数的原理：
1. shared_ptr在其内部，给每个资源都维护了着一份计数，用来记录该份资源被几个对象共
享。
2. 在对象被销毁时(也就是析构函数调用)，就说明自己不使用该资源了，对象的引用计数减
一。
3. 如果引用计数是0，就说明自己是最后一个使用该资源的对象，必须释放该资源；
4. 如果不是0，就说明除了自己还有其他对象在使用该份资源，不能释放该资源，否则其他对
象就成野指针了。
原码：
template<class T>
class shared_ptr
{
public:
// RAII
shared_ptr(T* ptr = nullptr)
:_ptr(ptr)
,_pcount(new int(1))
{}
// sp2(sp1)
shared_ptr(const shared_ptr<T>& sp)
{
_ptr = sp._ptr;
_pcount = sp._pcount;
// 拷贝时++计数
++(*_pcount);
}
// sp1 = sp4
// sp4 = sp4;
// sp1 = sp2;
shared_ptr<T>& operator=(const shared_ptr<T>& sp)
{
//if (this != &sp)
if (_ptr != sp._ptr)
{
release();
_ptr = sp._ptr;
_pcount = sp._pcount;
// 拷贝时++计数
++(*_pcount);
}
return *this;
}
void release()
{
// 说明最后一个管理对象析构了，可以释放资源了
if (--(*_pcount) == 0)
{
cout << "delete:" << _ptr << endl;
delete _ptr;
delete _pcount;
}
}
~shared_ptr()
{
// 析构时，--计数，计数减到0，
release();
}
int use_count()
{
return *_pcount;
}
// 像指针一样
T& operator*()
{
return *_ptr;
}
T* operator->()
{
return _ptr;
}
T* get() const
{
return _ptr;
}
private:
T* _ptr;
int* _pcount;
};std::shared_ptr的循环引用（特定场景下的缺陷）
那我们的share_ptr智能指针就是完美的吗？其实也并不是。
很坑的赋值重载函数
这里的sp1 = sp4，会将sp1的指针指向sp4指向的资源，但是原来sp1指向的资源需要--引用计数，不然会引起内存泄露！！！
赋值重载函数很坑，注意先--计数，因为赋值给别人了，
自己可能赋值给自己，很坑！
shared_ptr<T>& operator=(const shared_ptr<T>& sp)
{
//if (this != &sp)防止自己给自己赋值
if (_ptr != sp._ptr)
{
release();
_ptr = sp._ptr;
_pcount = sp._pcount;
// 拷贝时++计数
++(*_pcount);
}
return *this;
}智能指针的缺陷：（循环引用）
这里为什么n2的生命周期先到？因为对象调用构造函数和调用析构函数的顺序相反，这里先构造n1，后构造n2,所以就会先析构n2，因此n2的生命周期先到！
我们只有一个语句时就不会报错，具体分析如下：
首先出了作用域，n2的生命周期先到，那么n2的引用计数就--，变成了1，再紧接着，n1的生命周期到了，所以n1的引用计数就-到了0，因此就要释放掉，就会将n1结点的资源释放掉，这样n2的引用计数就会变成0，所以就会将n2结点的资源也释放掉，因此释放空间没问题，不会造成泄露
但是这两句话同时存在，就会存在循环引用的问题，具体分析如下：
1. node1和node2两个智能指针对象指向两个节点，引用计数变成1，我们不需要手动
delete。
2. node1的_next指向node2，node2的_prev指向node1，引用计数变成2。
3. node1和node2析构，引用计数减到1，但是_next还指向下一个节点。但是_prev还指向上
一个节点。
4. 也就是说node1的_next析构了，node2就释放了。
5. 也就是说node2的_prev析构了，node1就释放了。
6. 但是_next属于node1的成员，node1释放了，_next才会析构，而node1由node2的_prev管理，_prev属于node2成员，所以这就叫循环引用，谁也不会释放，互相牵制！
也就是引用计数一直在1，不会减到0，也就不会析构了。
解决方案：
我们采用weak_ptr不会将引用计数++，不会增加计数。
在引用计数的场景下，把节点中的_prev和_next改成weak_ptr就可以了
原理就是，node1->_next = node2;和node2->_prev = node1;时weak_ptr的_next和
_prev不会增加node1和node2的引用计数。
