shared_ptr的引用计数，准确地说，是强引用计数（use_count）和弱引用计数（weak_count），它们都存储在一个被称为“控制块”（control block）的独立内存区域里。这个控制块是在第一个
shared_ptr实例创建或通过
make_shared分配时一同创建的，它与被管理的对象是分离的（除非使用
make_shared优化）。
当我们谈论C++
shared_ptr的引用计数，其实是在聊它背后那个默默无闻但至关重要的“控制块”。这个控制块，在我看来，是
shared_ptr机制的真正核心，它承载了所有关于对象生命周期管理的关键信息。引用计数，无论是决定对象何时销毁的强引用计数，还是用于观察但不延长对象生命周期的弱引用计数，都安稳地躺在这个控制块里。
为什么是独立的控制块呢？想象一下，如果引用计数直接放在对象内部，那当对象被销毁时，我们怎么知道还有没有
weak_ptr在观察它？或者，如果多个
shared_ptr实例指向同一个对象，它们各自的引用计数又该如何同步？独立的控制块完美解决了这些问题。它是一个专门为
shared_ptr家族服务的数据结构，通常包含以下几个关键部分：
-
强引用计数（use_count）：这是最直接的计数器，记录有多少个
shared_ptr
实例正在“拥有”这个对象。当这个计数降到零时，就意味着没有shared_ptr
再关心这个对象了，此时被管理的对象会被销毁。 -
弱引用计数（weak_count）：这个计数器记录了有多少个
weak_ptr
实例正在“观察”这个对象。weak_ptr
不会增加强引用计数，因此它们的存在不会阻止对象的销毁。当强引用计数归零，对象被销毁后，即使weak_count
不为零，对象也已经不在了。weak_ptr
的存在，主要是为了在对象被销毁后，还能安全地判断出“对象已不存在”的状态，避免悬空指针。 - 删除器（deleter）：这通常是一个函数对象或Lambda表达式，负责在强引用计数归零时，正确地销毁被管理的对象。这提供了极大的灵活性，比如可以自定义删除数组、文件句柄等。
-
分配器（allocator）：如果在使用
shared_ptr
时指定了自定义分配器，那么这个信息也会存储在控制块中，以便在销毁对象和控制块时使用相同的分配策略。 - 类型擦除信息：控制块内部通常会通过某种类型擦除（type erasure）的机制，存储被管理对象的实际类型信息，以便正确调用其析构函数。
这个控制块的生命周期，是独立于被管理对象的。它会一直存在，直到强引用计数和弱引用计数都降为零。这意味着即使对象已经被销毁，只要还有
weak_ptr存在，控制块就会继续“存活”，直到最后一个
weak_ptr也失效。这种设计，我认为是
shared_ptr能够优雅处理循环引用和弱引用场景的关键。 shared_ptr控制块具体包含哪些核心组成部分？
shared_ptr的控制块并非只是一个简单的计数器，它是一个精心设计的结构，旨在全面管理被共享对象。除了我们前面提到的强引用计数和弱引用计数，它内部还封装了几个非常核心的组件，它们共同协作，确保了
shared_ptr机制的健壮性与灵活性。
强引用计数（use_count）无疑是最显眼的，它直接决定了被管理对象的生命周期。每当一个
shared_ptr实例被创建、复制或赋值给另一个
shared_ptr，这个计数就会增加；当
shared_ptr实例被销毁或重新赋值时，计数会减少。当它降至零，被管理的对象就会被安全地销毁。
紧随其后的是弱引用计数（weak_count）。这个计数器管理着
weak_ptr实例的数量。
weak_ptr的存在不会影响被管理对象的生命周期，它的主要作用是“观察”对象是否存在。当强引用计数归零，对象被销毁后，
weak_count可能仍然大于零。只有当
weak_count也归零时，控制块本身的内存才会被释放。这种分离设计对于解决循环引用问题至关重要，它允许我们创建一种非拥有性的引用。
控制块内部还存储着一个删除器（deleter）。这其实是一个可调用对象，负责在强引用计数为零时，执行被管理对象的实际销毁操作。这个特性非常强大，它允许我们对对象的销毁方式进行自定义。比如，如果你
shared_ptr管理的是一个通过
new[]分配的数组，你可以提供一个自定义删除器来调用
delete[]而不是默认的
delete。或者，管理的是一个文件句柄、网络连接等资源，你可以提供一个关闭资源的函数。这种灵活性是
shared_ptr超越裸指针和简单RAII包装器的地方。
如果
shared_ptr是通过自定义分配器创建的，那么这个分配器（allocator）的信息也会被存储在控制块中。这样，在控制块和被管理对象需要被销毁时，系统就能使用最初用于分配它们的相同分配器来释放内存，保持内存管理的一致性。这些组件共同构成了一个自给自足的生命周期管理单元，让
shared_ptr在多线程和复杂对象图中都能游刃有余。 为什么shared_ptr的引用计数不能直接放在被管理对象内部？
这个问题，其实触及了
shared_ptr设计的核心思想之一：解耦。如果
shared_ptr的引用计数直接放在它所管理的对象内部，那我们很快就会遇到一些难以解决的难题，甚至会破坏
shared_ptr的健壮性。
最直接的挑战是生命周期管理的分离。
shared_ptr的引用计数，其目的是为了判断被管理对象何时可以被安全销毁。但如果计数器就在对象内部，那么当计数降到零，对象被销毁后，这个计数器本身也就不存在了。这听起来好像没问题，但考虑
weak_ptr的存在。
weak_ptr需要能够查询对象是否仍然存活，并且在对象销毁后，它仍然需要知道“对象已不存在”的状态。如果引用计数随对象一起销毁，
weak_ptr就无法完成这个任务，它将无法安全地判断
lock()操作是否成功。独立的控制块则能保证，即使对象已经销毁，只要还有
weak_ptr存在，控制块就会继续存在，
weak_ptr就能通过它安全地判断对象状态。
多所有权模型的实现会变得异常复杂。
shared_ptr的核心是允许多个智能指针实例共同拥有同一个对象。如果计数器在对象内部，那么每个
shared_ptr实例都需要访问并修改同一个内存位置。这在单线程环境下可能还行，但在并发环境下，就需要复杂的同步机制来保护对象内部的计数器，而且这种同步机制本身又可能引入新的开销和复杂性。将计数器放在一个独立的、专门为此目的设计的控制块中，使得
shared_ptr可以更灵活、更高效地处理多线程环境下的引用计数更新（通常通过原子操作实现），而无需直接干扰被管理对象的数据布局。
类型擦除和自定义删除器的灵活性也会受到限制。
shared_ptr能够管理任何类型的对象，并且支持自定义的删除逻辑。如果计数器和删除器信息都必须嵌入到对象内部，那就意味着被管理的对象必须知道自己是如何被
shared_ptr管理的，甚至可能需要修改其类结构来包含这些管理信息。这显然违背了C++的面向对象设计原则，也限制了
shared_ptr管理第三方库或基本类型对象的能力。独立的控制块则可以透明地处理这些元数据，使得被管理对象无需感知
shared_ptr的存在，保持了其纯粹性。
所以，将引用计数和相关管理信息放在一个独立的控制块中，是
shared_ptr设计哲学中的一个精妙之处，它确保了
shared_ptr在各种复杂场景下都能提供安全、灵活且高效的内存管理。 shared_ptr控制块的内存分配机制及其对性能的影响
shared_ptr控制块的内存分配方式，其实是一个值得深入探讨的细节，因为它直接关系到程序的性能和内存使用效率。这里面主要有两种不同的分配策略，理解它们对于优化代码是很有帮助的。
第一种，也是我个人非常推崇的，是使用
std::make_shared来创建
shared_ptr。当你使用
make_shared时，它会进行一次性内存分配。这意味着被管理的对象和
shared_ptr的控制块会被分配在一块连续的内存区域中。这种方式的好处显而易见：
-
减少内存分配次数：从两次独立的
new
操作（一次为对象，一次为控制块）减少到一次。这显著降低了系统调用的开销，因为内存分配本身就是一项相对昂贵的操作。 - 提高缓存局部性：由于对象和控制块紧邻，当程序访问其中一个时，另一个很可能也已经被加载到CPU缓存中，从而减少了缓存未命中的几率，提升了数据访问速度。这在高性能计算场景下尤为重要。
然而，
make_shared也有一个潜在的“副作用”，虽然在大多数情况下这并非问题：由于对象和控制块在同一块内存中，即使被管理对象已经销毁（强引用计数为零），只要还有
weak_ptr存在，这整块内存就不会被释放，直到弱引用计数也归零。这意味着，如果你的对象很大，并且有很多
weak_ptr长期存在，那么这块大内存可能会被“锁定”更长时间，直到所有
weak_ptr都失效。
第二种分配方式，是当你直接从裸指针构造
shared_ptr时，例如
std::shared_ptr<MyObject> ptr(new MyObject());。在这种情况下，被管理的对象
MyObject会先通过
new MyObject()单独分配内存，然后
shared_ptr的构造函数会另外再分配一块内存来创建控制块。
这种方式的缺点也很明显：
- 两次独立的内存分配：这意味着更多的系统调用开销和潜在的内存碎片。
- 缓存局部性较差：对象和控制块在内存中是分离的，访问它们可能导致更多的缓存未命中。
但它也有其应用场景，比如当你需要管理一个已经存在的对象，或者一个不是通过
new分配的对象（例如，栈上对象，但
shared_ptr通常不管理栈上对象，这里只是举例说明内存来源不同）。
总的来说，在绝大多数情况下，我强烈建议优先使用
std::make_shared。它不仅能带来性能上的优势，还能让代码更简洁、更安全（因为它避免了裸指针的使用）。只有当你确实需要管理一个已存在的对象，或者有非常特殊的内存管理需求时，才考虑直接从裸指针构造`shared
以上就是C++ shared_ptr控制块 引用计数存储位置的详细内容，更多请关注知识资源分享宝库其它相关文章！
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。