make_shared更优的核心原因在于其将对象与控制块合并为一次内存分配，从而提升性能与内存局部性。1. make_shared通过单次内存分配同时创建对象和控制块，减少系统调用开销并优化缓存利用率；2. 直接构造shared_ptr需两次独立分配，影响效率且降低内存局部性；3. 特定场景如需自定义删除器、接管原始指针或精细控制weak_ptr生命周期时，应使用直接构造方式。
简而言之，
make_shared
通常是更优的选择，因为它能带来性能和内存上的优势，核心在于它能将对象的创建和其管理块（控制块）的创建合并为一次内存分配。而直接使用
new
构造
shared_ptr
，则通常需要两次独立的内存分配。
核心差异与选择依据
当我们谈论
make_shared
和直接构造
shared_ptr
的区别时，最核心的在于它们背后内存分配的策略。
make_shared(args...)
会在堆上分配一块足够大的内存，同时容纳
T
类型的对象本身以及
shared_ptr
所需的控制块（其中包含引用计数等信息）。这就像一次性预定了一个套间，所有东西都安排妥当。
而如果采用
shared_ptr(new T(args...))
这种方式，情况就不同了。
new T(args...)
会先在堆上为
T
对象分配一次内存，然后
shared_ptr
的构造函数在接手这个原始指针时，会再为自己的控制块进行另一次独立的内存分配。这就像你先买了一套房子，然后又去租了一个仓库来存放家具，是两个独立的动作。
这种差异直接影响到性能和内存使用效率。我个人在项目实践中，几乎总是优先考虑
make_shared
，除非有非常明确的理由不这样做。它不仅仅是少敲几个字符的事，背后是更深层次的优化考量。
make_shared
make_shared
为什么通常更优？
make_shared
之所以被广泛推荐，并不仅仅是C++11引入的新特性那么简单，它带来了实实在在的工程收益。
首先是性能优势。进行一次内存分配操作通常比两次要快，这减少了系统调用的开销。尤其是在需要频繁创建大量
shared_ptr
对象的场景下，这种累积的性能提升会非常明显。想象一下，如果你的程序每秒要创建成千上万个对象，那么每次节省一点点时间，最终就会汇聚成巨大的性能差异。
其次是内存局部性。由于对象和其控制块被分配在同一块连续的内存区域，它们在内存中的位置是相邻的。这对于CPU缓存来说非常友好。当程序访问对象时，很有可能其控制块的数据也已经被加载到缓存中，反之亦然。这种良好的内存局部性可以有效减少缓存未命中的情况，从而提高程序的运行效率。在现代CPU架构下，缓存的效率对程序性能的影响是巨大的，甚至可能比原始的指令执行速度更重要。
举个例子，假设我们有一个简单的结构体：
struct MyData { int value; std::string name; // ... 更多数据};// 使用 make_sharedauto data1 = std::make_shared();// 直接构造auto data2 = std::shared_ptr(new MyData());
在
data1
的例子中，
MyData
对象和
shared_ptr
的管理信息（如引用计数）都在一个内存块里。而在
data2
的例子中，
new MyData()
会分配一块内存，
shared_ptr
的构造又会分配另一块内存来存放管理信息。这在内存层面是截然不同的布局。
直接构造
shared_ptr
shared_ptr
的场景与考量
尽管
make_shared
在多数情况下表现优异，但它并非万能药。有些特定场景下，你不得不，或者说更适合，直接使用
shared_ptr(new T(...))
的方式。
一个非常常见的例子是当你需要自定义删除器（custom deleter）时。
make_shared
的接口设计没有直接提供传入自定义删除器的途径。如果你需要
shared_ptr
在对象生命周期结束时执行一些特殊的清理操作（比如关闭文件句柄、释放C风格的内存等），你就必须使用直接构造的方式：
// 假设有一个C库函数，返回一个需要手动释放的指针void* create_resource();void destroy_resource(void*);// 使用自定义删除器std::shared_ptr resource_ptr(create_resource(), [](void* p) { std::cout << "Custom deleter called for resource." << std::endl; destroy_resource(p);});
在这种情况下，
make_shared
就无能为力了。
另一个重要的场景是当你需要从已有的原始指针创建
shared_ptr
并接管其所有权时。这通常发生在与C风格API交互的边界处，或者当你需要将一个非
new
分配的内存块包装成
shared_ptr
时。例如，一个函数返回了一个堆分配的指针，但你不想在函数外部立即
delete
它，而是希望
shared_ptr
来管理：
// 假设some_c_api_func返回一个堆分配的指针MyClass* raw_ptr = some_c_api_func();// 将原始指针的所有权转移给shared_ptrstd::shared_ptr managed_ptr(raw_ptr);
这里你不能用
make_shared
，因为它会尝试
new MyClass()
，而不是使用你传入的
raw_ptr
。
还有一种比较微妙但很重要的场景，与
weak_ptr
和对象的生命周期有关。如果你的类中包含
weak_ptr
成员，并且这个
weak_ptr
可能指向对象自身（例如，为了打破循环引用），那么使用
make_shared
可能会导致一个轻微的内存“泄露”或者说延迟释放问题。当
shared_ptr
的引用计数降为零时，对象的析构函数会被调用，但
make_shared
分配的整个内存块（包括对象和控制块）只有当
weak_ptr
的引用计数也降为零时才会被释放。这意味着即使对象本身已经析构，它所占用的内存空间可能仍然被保留着，直到所有指向该控制块的
weak_ptr
都失效。而如果使用
shared_ptr(new T())
，对象和控制块是分开的，当
shared_ptr
引用计数归零时，对象内存会立即释放，只有控制块会保留到
weak_ptr
计数归零。在内存极其敏感的系统或某些特定设计模式下，这可能是需要考虑的因素。我曾遇到过一些复杂的图结构，就因为这个细节导致了额外的内存驻留，不得不退回使用
new
来构造。
内存分配细节与生命周期管理
深入到内存分配层面，
shared_ptr
的核心在于其内部的“控制块”（control block）。这个控制块存储了两个关键的引用计数：强引用计数（strong reference count）和弱引用计数（weak reference count）。强引用计数决定了被管理对象的生命周期，当它降到零时，被管理对象会被析构。弱引用计数则决定了控制块本身的生命周期，当它也降到零时，控制块的内存才会被释放。
使用
make_shared()
时，内存分配器会一次性分配一块内存，这块内存会同时容纳
T
类型的对象实例和
shared_ptr
所需的控制块。它们是紧密相连的，就像一个整体。这种设计的好处显而易见：更少的系统调用，更好的缓存利用率。
// 概念上，make_shared的内存布局可能是这样的：// [ MyObject数据 ... | shared_ptr控制块数据 (强/弱引用计数等) ... ]// ^----------------- 单次内存分配 ----------------------------------^
而当你通过
shared_ptr(new T())
来构造时，
new T()
首先进行一次内存分配，用于存储
T
的对象。然后，
shared_ptr
的构造函数会进行第二次独立的内存分配，用于创建其控制块。这两块内存可能在堆上相距甚远。
// 概念上，直接构造的内存布局可能是这样的：// [ MyObject数据 ... ] <-- 第一次内存分配 (by new T())//// [ shared_ptr控制块数据 (强/弱引用计数等) ... ] <-- 第二次内存分配 (by shared_ptr ctor)
这种分离的内存布局，就是导致前述“弱引用延迟释放”问题的根源。如果对象内部有一个
weak_ptr
指向自身，即使外部所有
shared_ptr
都销毁了，对象的析构函数被调用了，但由于那个
weak_ptr
还存活，控制块仍然存在。在使用
make_shared
时，由于对象和控制块在同一块内存中，这块内存无法被完全释放，直到所有
weak_ptr
也失效。而直接构造则不同，对象内存会先释放，只剩下控制块的内存，相对来说，对象的内存释放更及时。
因此，在大多数情况下，
make_shared
是首选，它提供了性能和内存效率上的优势。但在需要自定义删除器，或接管现有原始指针，以及极少数涉及
weak_ptr
和对象生命周期精细控制的场景下，直接构造
shared_ptr
是不可或缺的。选择哪种方式，最终还是取决于具体的应用场景和对性能、内存的精细化需求。
以上就是make_shared和直接构造shared_ptr有什么区别 性能与内存分配对比的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1470321.html
微信扫一扫 
支付宝扫一扫 
