Effectiveshared_ptr

由输出结果可以看出&＃xff1a;A 和 B 的析构函数都是没有执行的&＃xff0c;内存泄露&＃xff01;

分析&＃xff1a;众所周知&＃xff0c;new 出来的对象&＃xff0c;必须由程序员自己 delete 掉&＃xff0c;在此运用了智能指针&＃xff1a;shared_ptr来指向 new A&＃xff0c;即现在 delete 的责任落到了 shared_ptr 的身上&＃xff08;在其退出作用域时&＃xff09;。但是分析下上面的代码&＃xff1a;b 先出作用域&＃xff08;析构顺序与构造相反&＃xff09;&＃xff0c;B 的引用计数减为1&＃xff0c;不为0&＃xff0c;故堆上B的空间没有释放&＃xff0c;此时的结果是&＃xff1a;b 走了&＃xff0c;但是 new B 并没有被 delete 掉&＃xff0c;好吧&＃xff0c;现在只有等待 a 来delete了。然后是 a 退出其作用域&＃xff0c;A 的引用计数减少为1&＃xff0c;不为0&＃xff0c;因为B中的 m_a指向它&＃xff0c;结果是&＃xff1a;a 走了&＃xff0c;但是 new A 并没有被 delete 掉&＃xff0c;而此时已经没有 share_ptr 对象可以将他们delete掉了&＃xff0c;不对&＃xff0c;好像还有&＃xff1a;存在于new 出来的A和B对象里&＃xff0c;如果没有delete&＃xff0c;他俩就不会超出作用域&＃xff0c;它们在等待delete&＃xff0c;而 delete 却在等待 shared_ptr 对象自身发出delete&＃xff0c;矛盾产生&＃xff0c;于是就这样死锁了&＃xff01;&＃xff01;&＃xff01;故 new 出 来的 A 和 B 就这样的被遗弃&＃xff0c;从而内存泄露了。

原因&＃xff1a;&＃xff08;1&＃xff09;new 出来的对象必须手动delete掉&＃xff1b;&＃xff08;2&＃xff09;掌握delete的shared_ptr 在 new 出来的对象之中&＃xff1b;&＃xff08;3&＃xff09;两个new 对象里的shared_ptr 互相等待。

解锁&＃xff1a;试想如果只有单向指向&＃xff0c;如上代码&＃xff1a;去掉一行&＃xff1a;b->m_a &＃61;a ;&＃xff0c;但是将 B 引用 A 的信息保存在某处&＃xff0c;且对于 A 和 B的shared_ptr  对象是不可见的&＃xff0c;但是这些信息却可以观察到 指向 A 和 B 的 shared_ptr 对象的行为。再来分析一下&＃xff1a;b 先出作用域&＃xff0c;B的引用计数减少为1&＃xff0c;不为0&＃xff0c;此时 堆上 B 的空间没有释放&＃xff0c;结果依旧&＃xff1a;b 走了&＃xff0c;但是 new B 并没有被 delete 掉。然后是 a 退出作用域&＃xff0c;注意&＃xff1a;此时 A 的引用计数减少为0&＃xff0c;资源A 被释放&＃xff0c;这也导致A 空间中的指向资源B shared_ptr对象超出作用域&＃xff0c;从而 B的引用计数减少为0&＃xff0c;释放B&＃xff0c;如此 A 和 B 均能正确的释放了&＃xff0c;这应该就是weak_ptr 智能指针的原型了。

再来看下原来的例子&＃xff08;加入了 weak_ptr&＃xff09;&＃xff1a;