引用计数并不直接存在于对象内部，而是存储在独立的控制块中。1. 控制块包含强引用计数、弱引用计数、自定义删除器、分配器及可选的对象本身；2. 引用计数不放在对象内部的原因包括避免侵入性设计、支持多态和继承、确保 weak_ptr 的安全性以及存储管理信息；3. 使用 std::make_shared 一次性分配对象和控制块内存，提升性能与缓存效率，而 std::shared_ptr(new t()) 需两次分配，导致开销和碎片；4. weak_ptr 通过递增弱引用计数观察对象而不延长生命周期，并通过 lock() 方法检查对象有效性，确保安全访问。
智能指针的引用计数，准确地说，它并不直接存在于你所管理的那个对象内部。相反，它被巧妙地安置在一个独立的数据结构里，我们通常称之为“控制块”（Control Block）。这块内存是智能指针内部机制的核心，它负责追踪对象的生命周期，远比我们想象的要复杂和精巧。
解决方案
要深入理解智能指针的引用计数，就必须从它的“家”——控制块说起。这个控制块，说白了，就是一小块专门为智能指针管理对象而分配的额外内存。它通常包含几个关键要素：
-
强引用计数（Strong Reference Count）：这个是大家最熟悉的，它记录了有多少个
std::shared_ptr实例正在“拥有”这个对象。每当一个新的shared_ptr指向同一个对象时，这个计数就加一；当一个shared_ptr离开作用域或被重置时，它就减一。当强引用计数归零时，意味着没有shared_ptr再关心这个对象了，此时，被管理的对象就会被析构掉。 -
弱引用计数（Weak Reference Count）：这个计数器追踪的是
std::weak_ptr的数量。weak_ptr不拥有对象，它只是一个观察者。它的存在是为了解决shared_ptr循环引用的问题，同时也能让你在不延长对象生命周期的情况下，安全地检查对象是否还存在。当弱引用计数也归零时（前提是强引用计数也已归零），整个控制块的内存才会被释放。 -
自定义删除器（Deleter）：如果你在使用
shared_ptr时提供了自定义的删除函数（例如，管理一个文件句柄而不是普通对象，需要调用fclose），那么这个删除器也会被存储在控制块里。这样，当强引用计数归零时，智能指针就知道该用哪个函数来清理资源。 - 自定义分配器（Allocator）：同理，如果你使用了自定义的内存分配器来创建对象，这个分配器信息也可能被存储在这里。
-
被管理对象本身（可选）：这是一个非常重要的优化点。当你使用
std::make_shared来创建智能指针时，它会一次性分配一块足够大的内存，将控制块和被管理的对象本身都放在这块内存里。这样可以减少一次内存分配，提高缓存命中率，性能自然就好很多。而如果你是std::shared_ptr<t> p(new T())</t>这样构造的，那么new T()会先分配一次内存给T，然后shared_ptr再单独为控制块分配一次内存。
所以，控制块是智能指针实现其复杂生命周期管理的关键，它就像一个幕后总管，默默地协调着资源的分配与释放。
为什么引用计数不直接放在对象内部？
这真是一个很有趣的问题，我个人觉得，这体现了C++设计者对“职责分离”和“通用性”的深刻理解。如果引用计数直接放在对象内部，会带来一系列麻烦，简直是给自己挖坑。
想象一下，如果 MyObject 类内部有个 int ref_count;。
首先，侵入性太强。这意味着任何你想用 shared_ptr 管理的类，都得修改它的定义，加上这个 ref_count 成员。这违背了“非侵入式”设计的原则。很多时候，我们可能要管理第三方库的对象，或者C风格的结构体，它们根本没法改动。智能指针的精髓在于它能管理任何类型的资源，而不需要被管理类型知道自己被智能指针“包裹”了。
其次，多态和继承的复杂性。如果一个基类有引用计数，派生类继承了它，那计数器是基类的还是派生类的？如果一个 shared_ptr<base> 指向一个 Derived 对象，计数器在哪里？当 shared_ptr<base> 释放时，它怎么知道要调用 Derived 的析构函数？把计数器放在外部的控制块里，完美地解决了这个问题。控制块只关心它管理的是哪块内存，以及如何释放它（通过存储的删除器，或者知道它是一个 T*）。它与被管理对象的具体类型无关，只与内存地址相关。
再者，weak_ptr 的存在。weak_ptr 的核心功能是能在不延长对象生命周期的情况下，安全地检查对象是否还“活着”。如果引用计数在对象内部，当强引用计数归零、对象被析构后，weak_ptr 怎么去访问一个已经不存在的内存地址来检查计数呢？这显然是不安全的。而控制块的存在，使得 weak_ptr 即使在对象已经销毁后，仍然可以访问到控制块（因为弱引用计数可能还没归零），从而安全地判断对象是否有效。控制块的生命周期比被管理对象的生命周期更长（只要有 weak_ptr 存在，控制块就不会被释放）。
最后，自定义删除器和分配器的存储。这些额外的管理信息也需要一个地方存放。控制块自然成了最合适的“杂物间”，它把所有与资源管理相关的元数据都集中在一起，保持了被管理对象的纯粹性。
make_shared 与 shared_ptr(new T()) 对控制块内存布局的影响？
这两种构造 shared_ptr 的方式，虽然最终都能让你得到一个智能指针，但它们在底层内存分配和控制块布局上，简直是天壤之别，对性能的影响也挺大的。
当你写 std::shared_ptr<myobject> p(new MyObject());</myobject> 时，内存分配会发生两次：
-
new MyObject()：第一次分配，用于为MyObject对象本身分配内存。 -
shared_ptr构造函数：第二次分配，用于为控制块分配内存。
这意味着你的 MyObject 对象和它的控制块在内存中是分开的，它们可能相距遥远。这会带来几个潜在的问题：
- 性能开销：两次独立的内存分配操作，会增加系统调用的开销，可能导致性能下降。
- 内存碎片：多次小块内存的分配和释放，容易造成内存碎片化，尤其是在长时间运行的程序中。
- 缓存效率：对象和控制块不在同一块连续内存中，当程序需要同时访问它们时，可能会导致更多的缓存未命中，降低CPU缓存的利用率。
而当你使用 std::make_shared<myobject>()</myobject> 时，情况就完全不同了。make_shared 的一个核心优化就是它会只进行一次内存分配。它会计算好 MyObject 对象所需的内存大小和控制块所需的内存大小，然后一次性向操作系统申请一块足够大的连续内存。在这块内存中，MyObject 对象和控制块是紧挨着存放的。
这种单次分配的策略带来了显著的优势：
- 更高的性能：减少了一次内存分配的系统调用开销。
- 更好的缓存局部性：对象和控制块紧密排列，当访问其中一个时，另一个很可能已经在CPU缓存中，从而提高缓存命中率，加速程序运行。
- 减少内存碎片：通过一次性分配大块内存，减少了小块内存的零散分配，有助于降低内存碎片化。
然而，make_shared 也有一个不那么明显的“副作用”：如果你的 shared_ptr 都被释放了，但仍然有 weak_ptr 存在，那么即使被管理的对象已经不再需要了（强引用计数归零），它的内存也不会立即被释放。因为对象和控制块是放在一起的，只要控制块还被 weak_ptr 引用着（弱引用计数不为零），那么包含对象的整块内存就不能被释放。这对于非常大的对象来说，可能会导致内存“滞留”一段时间，直到最后一个 weak_ptr 也被销毁。当然，对于大多数场景，make_shared 的优势远大于这个潜在的劣势，所以它通常是推荐的构造方式。
weak_ptr 如何利用控制块实现其功能？
weak_ptr 这个东西，初看有点神秘，但它在解决 shared_ptr 循环引用问题上简直是神来之笔。它之所以能工作，正是因为它巧妙地利用了控制块的弱引用计数。
weak_ptr 的核心思想是“观察而不拥有”。当一个 weak_ptr 指向一个对象时，它会去递增控制块里的弱引用计数，而不是强引用计数。这意味着 weak_ptr 的存在，不会阻止被管理对象被销毁。
那么，weak_ptr 是怎么判断对象是否还存在的呢？它通过调用 lock() 方法来实现。当 weak_ptr::lock() 被调用时：
- 它会去访问它所指向的那个控制块。
- 它会检查控制块里的强引用计数。
- 如果强引用计数大于零，说明对象仍然存在，并且至少有一个
shared_ptr还在管理它。此时，lock()会成功地创建一个新的shared_ptr实例，并递增强引用计数，然后返回这个新的shared_ptr。 - 如果强引用计数等于零，这表示所有
shared_ptr都已经放弃了对对象的拥有权，对象已经被析构了。在这种情况下，lock()会返回一个空的shared_ptr（即nullptr），告诉你对象已经不在了。
这里的关键点在于，即使强引用计数已经归零，只要还有 weak_ptr 存在（即弱引用计数不为零），控制块就不会被销毁。这使得 weak_ptr 能够安全地访问控制块，检查强引用计数的状态，从而判断被管理对象是否仍然有效。一旦强引用计数和弱引用计数都变为零，那么整个控制块的内存才会被释放。这种机制确保了 weak_ptr 既能安全地观察对象，又不会不必要地延长对象的生命周期，完美地解决了 shared_ptr 带来的循环引用困境。
