智能指针的使用和原理
目录
C++标准库智能指针的使用
auto_ptr的了解
unique_ptr的了解
应用
析构问题
解决办法
方案一：特化
方案二：删除器
智能指针原理
了解weak_ptr
内存泄漏
如何避免内存泄漏
模拟实现智能指针
C++标准库智能指针的使用
- C++标准库中的智能指针都在这个头⽂件下⾯，我们包含就可以是使⽤了， 智能指针有好⼏种，除了weak_ptr他们都符合RAII和像指针⼀样访问的⾏为，原理上⽽⾔主要是解 决智能指针拷⻉时的思路不同。
- auto_ptr是C++98时设计出来的智能指针，他的特点是拷⻉时把被拷⻉对象的资源的管理权转移给 拷⻉对象，这是⼀个⾮常糟糕的设计，因为他会到被拷⻉对象悬空，访问报错的问题，C++11设计 出新的智能指针后，强烈建议不要使⽤auto_ptr。其他C++11出来之前很多公司也是明令禁⽌使⽤ 这个智能指针的。
- unique_ptr是C++11设计出来的智能指针，他的名字翻译出来是唯⼀指针，他的特点的不⽀持拷 ⻉，只⽀持移动。如果不需要拷⻉的场景就⾮常建议使⽤他。
- shared_ptr是C++11设计出来的智能指针，他的名字翻译出来是共享指针，他的特点是⽀持拷⻉， 也⽀持移动。如果需要拷⻉的场景就需要使⽤他了。底层是⽤引⽤计数的⽅式实现的。
- weak_ptr是C++11设计出来的智能指针，他的名字翻译出来是弱指针，他完全不同于上⾯的智能指 针，他不⽀持RAII，也就意味着不能⽤它直接管理资源，weak_ptr的产⽣本质是要解决shared_ptr 的⼀个循环引⽤导致内存泄漏的问题。
- shared_ptr 除了⽀持⽤指向资源的指针构造，还⽀持直接构造。
- shared_ptr 和 unique_ptr 的构造函数都使⽤explicit修饰，防⽌普通指针隐式类型转换 成其他智能指针对象。
auto_ptr的了解
它是拷⻉时把被拷⻉对象的资源的管理权转移给 拷⻉对象。
所以不建议使用auto_ptr!
unique_ptr的了解
它不⽀持拷 ⻉，只⽀持移动。
shared_ptr的了解
他的特点是⽀持拷⻉， 也⽀持移动.
应用
析构问题
解决办法
方案一：特化
方案二：删除器
因为shared_ptr和unique_ptr的不同，我们分开讲解！
有如下函数：
shared_ptr:
unique_ptr:
由于unique_ptr和shared_ptr的设计不同，用法也不同！
unique_ptr不仅要传对象，还要传类型！
注意：
我们也可以这样写：利用make_shared
shared_ptr 和 unique_ptr 的构造函数都使⽤explicit修饰，防⽌普通指针隐式类型转换成其他智能指针对象。（所以禁止隐式类型转换）
智能指针原理
看看shared_ptr是如何设计的，尤其是引⽤计数的设计，主要这⾥⼀份资源就需要⼀个 引⽤计数，所以引⽤计数才⽤静态成员的⽅式是⽆法实现的，要使⽤堆上动态开辟的⽅式，构造智 能指针对象时来⼀份资源，就要new⼀个引⽤计数出来。多个shared_ptr指向资源时就++引⽤计 数，shared_ptr对象析构时就--引⽤计数，引⽤计数减到0时代表当前析构的shared_ptr是最后⼀ 个管理资源的对象，则析构资源。
shared_ptr循环引用问题
有这么一个类：
跑以下程序会有循环引用的问题：
分析：
析构：
此时，继续析构，但是陷入引用循环！
解释：
解决方法：
了解weak_ptr
weak_ptr也没有重载operator*和operator->等，因为他不参与资源管理，那么如果他绑定的 shared_ptr已经释放了资源，那么他去访问资源就是很危险的。weak_ptr⽀持expired检查指向的 资源是否过期，use_count也可获取shared_ptr的引⽤计数，weak_ptr想访问资源时，可以调⽤ lock返回⼀个管理资源的shared_ptr，如果资源已经被释放，返回的shared_ptr是⼀个空对象，如 果资源没有释放，则通过返回的shared_ptr访问资源是安全的。
shared_ptr的线程安全问题
- shared_ptr的引⽤计数对象在堆上，如果多个shared_ptr对象在多个线程中，进⾏shared_ptr的拷 ⻉析构时会访问修改引⽤计数，就会存在线程安全问题，所以shared_ptr引⽤计数是需要加锁或者 原⼦操作保证线程安全的。
- shared_ptr指向的对象也是有线程安全的问题的，但是这个对象的线程安全问题不归shared_ptr 管，它也管不了，应该有外层使⽤shared_ptr的⼈进⾏线程安全的控制。
- 引⽤计数从int*改成atomic*就可以保证 引⽤计数的线程安全问题，或者使⽤互斥锁加锁也可以。
内存泄漏
什么是内存泄漏：内存泄漏指因为疏忽或错误造成程序未能释放已经不再使⽤的内存，⼀般是忘记释 放或者发⽣异常释放程序未能执⾏导致的。内存泄漏并不是指内存在物理上的消失，⽽是应⽤程序分 配某段内存后，因为设计错误，失去了对该段内存的控制，因⽽造成了内存的浪费。
内存泄漏的危害：普通程序运⾏⼀会就结束了出现内存泄漏问题也不⼤，进程正常结束，⻚表的映射 关系解除，物理内存也可以释放。⻓期运⾏的程序出现内存泄漏，影响很⼤，如操作系统、后台服 务、⻓时间运⾏的客⼾端等等，不断出现内存泄漏会导致可⽤内存不断变少，各种功能响应越来越 慢，最终卡死。
如何避免内存泄漏
⼯程前期良好的设计规范，养成良好的编码规范，申请的内存空间记着匹配的去释放。ps：这个理 想状态。但是如果碰上异常时，就算注意释放了，还是可能会出问题。需要下⼀条智能指针来管理 才有保证。
尽量使⽤智能指针来管理资源，如果⾃⼰场景⽐较特殊，采⽤RAII思想⾃⼰造个轮⼦管理。
定期使⽤内存泄漏⼯具检测，尤其是每次项⽬快上线前，不过有些⼯具不够靠谱，或者是收费。
总结⼀下：内存泄漏⾮常常⻅，解决⽅案分为两种：1、事前预防型。如智能指针等。2、事后查错 型。如泄漏检测⼯具。
模拟实现智能指针
namespace bit
{
template<class T>
class shared_ptr
{
public:
explicit shared_ptr(T* ptr = nullptr)
: _ptr(ptr)
, _pcount(new atomic<int>(1))
{}
template<class D>
explicit shared_ptr(T* ptr, D del)
: _ptr(ptr)
, _pcount(new atomic<int>(1))
, _del(del)
{}
shared_ptr(const shared_ptr<T>& sp)
:_ptr(sp._ptr)
, _pcount(sp._pcount)
, _del(sp._del)
{
++(*_pcount);
}
void release()
{
if (--(*_pcount) == 0)
{
//delete _ptr;
_del(_ptr);
delete _pcount;
_ptr = nullptr;
_pcount = nullptr;
}
}
// sp1 = sp4;
shared_ptr<T>& operator=(const shared_ptr<T>& sp)
{
if (this != &sp)
{
release();
_ptr = sp._ptr;
_pcount = sp._pcount;
_del = sp._del;
++(*_pcount);
}
return *this;
}
~shared_ptr()
{
release();
}
T& operator*()
{
return *_ptr;
}
T* operator->()
{
return _ptr;
}
T* get() const
{
return _ptr;
}
int use_count() const
{
return *_pcount;
}
operator bool()
{
return _ptr != nullptr;
}
private:
T* _ptr;
//int* _pcount;
atomic<int>* _pcount;
std::function<void(T*)> _del = [](T* ptr) {delete ptr; };
};
template<class T>
class weak_ptr
{
public:
weak_ptr()
{}
weak_ptr(const shared_ptr<T>& sp)
:_ptr(sp.get())
{}
weak_ptr<T>& operator=(const shared_ptr<T>& sp)
{
_ptr = sp.get();
return *this;
}
private:
T* _ptr = nullptr;
//T* _pcount
};
}好了，C++之旅基本结束，我们linux再见！！！