C++ shared_ptr控制块 引用计数存储位置

shared_ptr的控制块包含强引用计数、弱引用计数、删除器、分配器和类型擦除信息，独立于被管理对象存储，确保生命周期管理分离，支持多所有权与weak_ptr安全访问，避免循环引用问题。使用make_shared时对象与控制块连续分配，提升性能但可能延长内存占用；直接构造则分离分配，灵活性高但开销大。

的引用计数，准确地说，是强引用计数（use_count）和弱引用计数（weak_count），它们都存储在一个被称为“控制块”（control block）的独立内存区域里。这个控制块是在第一个实例创建或通过分配时一同创建的，它与被管理的对象是分离的（除非使用优化）。

当我们谈论C++

的引用计数，其实是在聊它背后那个默默无闻但至关重要的“控制块”。这个控制块，在我看来，是机制的真正核心，它承载了所有关于对象生命周期管理的关键信息。引用计数，无论是决定对象何时销毁的强引用计数，还是用于观察但不延长对象生命周期的弱引用计数，都安稳地躺在这个控制块里。

为什么是独立的控制块呢？想象一下，如果引用计数直接放在对象内部，那当对象被销毁时，我们怎么知道还有没有

在观察它？或者，如果多个实例指向同一个对象，它们各自的引用计数又该如何同步？独立的控制块完美解决了这些问题。它是一个专门为家族服务的数据结构，通常包含以下几个关键部分：

1. 强引用计数（use_count）：这是最直接的计数器，记录有多少个

   shared_ptr

   登录后复制
   实例正在“拥有”这个对象。当这个计数降到零时，就意味着没有

   shared_ptr

   登录后复制
   再关心这个对象了，此时被管理的对象会被销毁。
2. 弱引用计数（weak_count）：这个计数器记录了有多少个

   weak_ptr

   登录后复制
   实例正在“观察”这个对象。

   weak_ptr

   登录后复制
   不会增加强引用计数，因此它们的存在不会阻止对象的销毁。当强引用计数归零，对象被销毁后，即使

   weak_count

   登录后复制
   不为零，对象也已经不在了。

   weak_ptr

   登录后复制
   的存在，主要是为了在对象被销毁后，还能安全地判断出“对象已不存在”的状态，避免悬空指针。
3. 删除器（deleter）：这通常是一个函数对象或Lambda表达式，负责在强引用计数归零时，正确地销毁被管理的对象。这提供了极大的灵活性，比如可以自定义删除数组、文件句柄等。
4. 分配器（allocator）：如果在使用

   shared_ptr

   登录后复制
   时指定了自定义分配器，那么这个信息也会存储在控制块中，以便在销毁对象和控制块时使用相同的分配策略。
5. 类型擦除信息：控制块内部通常会通过某种类型擦除（type erasure）的机制，存储被管理对象的实际类型信息，以便正确调用其析构函数。

这个控制块的生命周期，是独立于被管理对象的。它会一直存在，直到强引用计数和弱引用计数都降为零。这意味着即使对象已经被销毁，只要还有

存在，控制块就会继续“存活”，直到最后一个也失效。这种设计，我认为是能够优雅处理循环引用和弱引用场景的关键。

立即学习“C++免费学习笔记（深入）”；

shared_ptr控制块具体包含哪些核心组成部分？

的控制块并非只是一个简单的计数器，它是一个精心设计的结构，旨在全面管理被共享对象。除了我们前面提到的强引用计数和弱引用计数，它内部还封装了几个非常核心的组件，它们共同协作，确保了机制的健壮性与灵活性。

强引用计数（use_count）无疑是最显眼的，它直接决定了被管理对象的生命周期。每当一个

实例被创建、复制或赋值给另一个，这个计数就会增加；当实例被销毁或重新赋值时，计数会减少。当它降至零，被管理的对象就会被安全地销毁。

紧随其后的是弱引用计数（weak_count）。这个计数器管理着

实例的数量。的存在不会影响被管理对象的生命周期，它的主要作用是“观察”对象是否存在。当强引用计数归零，对象被销毁后，可能仍然大于零。只有当也归零时，控制块本身的内存才会被释放。这种分离设计对于解决循环引用问题至关重要，它允许我们创建一种非拥有性的引用。

控制块内部还存储着一个删除器（deleter）。这其实是一个可调用对象，负责在强引用计数为零时，执行被管理对象的实际销毁操作。这个特性非常强大，它允许我们对对象的销毁方式进行自定义。比如，如果你

管理的是一个通过分配的数组，你可以提供一个自定义删除器来调用而不是默认的。或者，管理的是一个文件句柄、网络连接等资源，你可以提供一个关闭资源的函数。这种灵活性是超越裸指针和简单RAII包装器的地方。

如果

是通过自定义分配器创建的，那么这个分配器（allocator）的信息也会被存储在控制块中。这样，在控制块和被管理对象需要被销毁时，系统就能使用最初用于分配它们的相同分配器来释放内存，保持内存管理的一致性。这些组件共同构成了一个自给自足的生命周期管理单元，让在多线程和复杂对象图中都能游刃有余。

为什么shared_ptr的引用计数不能直接放在被管理对象内部？

这个问题，其实触及了

设计的核心思想之一：解耦。如果的引用计数直接放在它所管理的对象内部，那我们很快就会遇到一些难以解决的难题，甚至会破坏的健壮性。

最直接的挑战是生命周期管理的分离。

的引用计数，其目的是为了判断被管理对象何时可以被安全销毁。但如果计数器就在对象内部，那么当计数降到零，对象被销毁后，这个计数器本身也就不存在了。这听起来好像没问题，但考虑的存在。需要能够查询对象是否仍然存活，并且在对象销毁后，它仍然需要知道“对象已不存在”的状态。如果引用计数随对象一起销毁，就无法完成这个任务，它将无法安全地判断操作是否成功。独立的控制块则能保证，即使对象已经销毁，只要还有存在，控制块就会继续存在，就能通过它安全地判断对象状态。

多所有权模型的实现会变得异常复杂。

的核心是允许多个智能指针实例共同拥有同一个对象。如果计数器在对象内部，那么每个实例都需要访问并修改同一个内存位置。这在单线程环境下可能还行，但在并发环境下，就需要复杂的同步机制来保护对象内部的计数器，而且这种同步机制本身又可能引入新的开销和复杂性。将计数器放在一个独立的、专门为此目的设计的控制块中，使得可以更灵活、更高效地处理多线程环境下的引用计数更新（通常通过原子操作实现），而无需直接干扰被管理对象的数据布局。

类型擦除和自定义删除器的灵活性也会受到限制。

能够管理任何类型的对象，并且支持自定义的删除逻辑。如果计数器和删除器信息都必须嵌入到对象内部，那就意味着被管理的对象必须知道自己是如何被管理的，甚至可能需要修改其类结构来包含这些管理信息。这显然违背了C++的面向对象设计原则，也限制了管理第三方库或基本类型对象的能力。独立的控制块则可以透明地处理这些元数据，使得被管理对象无需感知的存在，保持了其纯粹性。

所以，将引用计数和相关管理信息放在一个独立的控制块中，是

设计哲学中的一个精妙之处，它确保了在各种复杂场景下都能提供安全、灵活且高效的内存管理。

shared_ptr控制块的内存分配机制及其对性能的影响

控制块的内存分配方式，其实是一个值得深入探讨的细节，因为它直接关系到程序的性能和内存使用效率。这里面主要有两种不同的分配策略，理解它们对于优化代码是很有帮助的。

第一种，也是我个人非常推崇的，是使用

来创建。当你使用时，它会进行一次性内存分配。这意味着被管理的对象和的控制块会被分配在一块连续的内存区域中。这种方式的好处显而易见：

1. 减少内存分配次数：从两次独立的

   new

   登录后复制
   操作（一次为对象，一次为控制块）减少到一次。这显著降低了系统调用的开销，因为内存分配本身就是一项相对昂贵的操作。
2. 提高缓存局部性：由于对象和控制块紧邻，当程序访问其中一个时，另一个很可能也已经被加载到CPU缓存中，从而减少了缓存未命中的几率，提升了数据访问速度。这在高性能计算场景下尤为重要。

然而，

也有一个潜在的“副作用”，虽然在大多数情况下这并非问题：由于对象和控制块在同一块内存中，即使被管理对象已经销毁（强引用计数为零），只要还有存在，这整块内存就不会被释放，直到弱引用计数也归零。这意味着，如果你的对象很大，并且有很多长期存在，那么这块大内存可能会被“锁定”更长时间，直到所有都失效。

第二种分配方式，是当你直接从裸指针构造

时，例如。在这种情况下，被管理的对象会先通过单独分配内存，然后的构造函数会另外再分配一块内存来创建控制块。

这种方式的缺点也很明显：

1. 两次独立的内存分配：这意味着更多的系统调用开销和潜在的内存碎片。
2. 缓存局部性较差：对象和控制块在内存中是分离的，访问它们可能导致更多的缓存未命中。

但它也有其应用场景，比如当你需要管理一个已经存在的对象，或者一个不是通过

分配的对象（例如，栈上对象，但通常不管理栈上对象，这里只是举例说明内存来源不同）。

总的来说，在绝大多数情况下，我强烈建议优先使用

。它不仅能带来性能上的优势，还能让代码更简洁、更安全（因为它避免了裸指针的使用）。只有当你确实需要管理一个已存在的对象，或者有非常特殊的内存管理需求时，才考虑直接从裸指针构造`shared

以上就是C++ shared_ptr控制块 引用计数存储位置的详细内容，更多请关注php中文网其它相关文章！