make_shared和直接构造shared_ptr有什么区别 性能与内存分配对比

make_shared更优的核心原因在于其将对象与控制块合并为一次内存分配，从而提升性能与内存局部性。1. make_shared通过单次内存分配同时创建对象和控制块，减少系统调用开销并优化缓存利用率；2. 直接构造shared_ptr需两次独立分配，影响效率且降低内存局部性；3. 特定场景如需自定义删除器、接管原始指针或精细控制weak_ptr生命周期时，应使用直接构造方式。

简而言之，

通常是更优的选择，因为它能带来性能和内存上的优势，核心在于它能将对象的创建和其管理块（控制块）的创建合并为一次内存分配。而直接使用 构造 ，则通常需要两次独立的内存分配。

核心差异与选择依据

当我们谈论

和直接构造的区别时，最核心的在于它们背后内存分配的策略。 会在堆上分配一块足够大的内存，同时容纳类型的对象本身以及所需的控制块（其中包含引用计数等信息）。这就像一次性预定了一个套间，所有东西都安排妥当。

而如果采用

这种方式，情况就不同了。会先在堆上为对象分配一次内存，然后的构造函数在接手这个原始指针时，会再为自己的控制块进行另一次独立的内存分配。这就像你先买了一套房子，然后又去租了一个仓库来存放家具，是两个独立的动作。

这种差异直接影响到性能和内存使用效率。我个人在项目实践中，几乎总是优先考虑

，除非有非常明确的理由不这样做。它不仅仅是少敲几个字符的事，背后是更深层次的优化考量。

make_shared

登录后复制

为什么通常更优？

之所以被广泛推荐，并不仅仅是C++11引入的新特性那么简单，它带来了实实在在的工程收益。

首先是性能优势。进行一次内存分配操作通常比两次要快，这减少了系统调用的开销。尤其是在需要频繁创建大量

对象的场景下，这种累积的性能提升会非常明显。想象一下，如果你的程序每秒要创建成千上万个对象，那么每次节省一点点时间，最终就会汇聚成巨大的性能差异。

其次是内存局部性。由于对象和其控制块被分配在同一块连续的内存区域，它们在内存中的位置是相邻的。这对于CPU缓存来说非常友好。当程序访问对象时，很有可能其控制块的数据也已经被加载到缓存中，反之亦然。这种良好的内存局部性可以有效减少缓存未命中的情况，从而提高程序的运行效率。在现代CPU架构下，缓存的效率对程序性能的影响是巨大的，甚至可能比原始的指令执行速度更重要。

举个例子，假设我们有一个简单的结构体：

在

的例子中，对象和的管理信息（如引用计数）都在一个内存块里。而在的例子中，会分配一块内存，的构造又会分配另一块内存来存放管理信息。这在内存层面是截然不同的布局。

直接构造

shared_ptr

登录后复制

的场景与考量

尽管

在多数情况下表现优异，但它并非万能药。有些特定场景下，你不得不，或者说更适合，直接使用的方式。

一个非常常见的例子是当你需要自定义删除器（custom deleter）时。

的接口设计没有直接提供传入自定义删除器的途径。如果你需要在对象生命周期结束时执行一些特殊的清理操作（比如关闭文件句柄、释放C风格的内存等），你就必须使用直接构造的方式：

在这种情况下，

就无能为力了。

另一个重要的场景是当你需要从已有的原始指针创建

并接管其所有权时。这通常发生在与C风格API交互的边界处，或者当你需要将一个非分配的内存块包装成时。例如，一个函数返回了一个堆分配的指针，但你不想在函数外部立即它，而是希望来管理：

这里你不能用

，因为它会尝试，而不是使用你传入的。

还有一种比较微妙但很重要的场景，与

和对象的生命周期有关。如果你的类中包含成员，并且这个可能指向对象自身（例如，为了打破循环引用），那么使用可能会导致一个轻微的内存“泄露”或者说延迟释放问题。当的引用计数降为零时，对象的析构函数会被调用，但分配的整个内存块（包括对象和控制块）只有当的引用计数也降为零时才会被释放。这意味着即使对象本身已经析构，它所占用的内存空间可能仍然被保留着，直到所有指向该控制块的都失效。而如果使用，对象和控制块是分开的，当引用计数归零时，对象内存会立即释放，只有控制块会保留到计数归零。在内存极其敏感的系统或某些特定设计模式下，这可能是需要考虑的因素。我曾遇到过一些复杂的图结构，就因为这个细节导致了额外的内存驻留，不得不退回使用来构造。

内存分配细节与生命周期管理

深入到内存分配层面，

的核心在于其内部的“控制块”（control block）。这个控制块存储了两个关键的引用计数：强引用计数（strong reference count）和弱引用计数（weak reference count）。强引用计数决定了被管理对象的生命周期，当它降到零时，被管理对象会被析构。弱引用计数则决定了控制块本身的生命周期，当它也降到零时，控制块的内存才会被释放。

使用

时，内存分配器会一次性分配一块内存，这块内存会同时容纳类型的对象实例和所需的控制块。它们是紧密相连的，就像一个整体。这种设计的好处显而易见：更少的系统调用，更好的缓存利用率。

而当你通过

来构造时，首先进行一次内存分配，用于存储的对象。然后，的构造函数会进行第二次独立的内存分配，用于创建其控制块。这两块内存可能在堆上相距甚远。

这种分离的内存布局，就是导致前述“弱引用延迟释放”问题的根源。如果对象内部有一个

指向自身，即使外部所有都销毁了，对象的析构函数被调用了，但由于那个还存活，控制块仍然存在。在使用时，由于对象和控制块在同一块内存中，这块内存无法被完全释放，直到所有也失效。而直接构造则不同，对象内存会先释放，只剩下控制块的内存，相对来说，对象的内存释放更及时。

因此，在大多数情况下，

是首选，它提供了性能和内存效率上的优势。但在需要自定义删除器，或接管现有原始指针，以及极少数涉及和对象生命周期精细控制的场景下，直接构造是不可或缺的。选择哪种方式，最终还是取决于具体的应用场景和对性能、内存的精细化需求。

以上就是make_shared和直接构造shared_ptr有什么区别 性能与内存分配对比的详细内容，更多请关注php中文网其它相关文章！