C++中的std::make_shared为什么比直接new更好？(减少内存分配次数)

std::make_shared 为什么能减少内存分配次数

因为 std::make_shared 把控制块（control block）和对象数据分配在同一块连续内存里，而直接用 new 构造再传给 std::shared_ptr 构造函数时，控制块和对象是两次独立的堆分配。

控制块里存引用计数、弱引用计数、删除器等元数据；对象本身是用户数据。两次分配不仅慢，还增加缓存不友好性和碎片化风险。

• 两次分配：先 new T 分配对象，再由 shared_ptr 内部另一次 operator new 分配控制块
• 一次分配：make_shared 预计算总大小（控制块 + 对齐填充 + T），单次申请，然后在其中分别构造控制块和对象
• 注意：仅对无自定义删除器、无对齐要求超出默认的情况才保证合并分配；若用了 std::allocate_shared 或自定义分配器，行为取决于分配器实现

直接 new + shared_ptr 构造的典型写法与开销

这种写法看似直观，但隐含两次堆分配：

std::shared_ptr ptr(new std::string("hello")); // ❌ 两次分配

即使编译器做了某些优化（如 NRVO 或分配器内联），标准不保证合并；且无法避免控制块中存储的“指向对象的指针”带来的间接访问。

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

MuleRun

全球首个AI Agent交易平台

下载

• 控制块中必须保存一个指向对象的指针（用于析构时调用 T 的析构函数）
• 两次分配导致两块不相邻内存，降低 CPU 缓存命中率
• 异常安全虽有保障（shared_ptr 构造失败会自动清理已分配对象），但性能损失固定存在

make_shared 的限制与容易踩的坑

make_shared 不是万能替代方案，以下情况它无法工作或会出问题：

• T 的构造函数是私有的，且 make_shared 无法访问（它不参与友元声明，也不像 shared_ptr 构造函数那样可被显式授权）
• 需要自定义删除器（如文件句柄、GPU 内存释放）——make_shared 固定使用 delete，必须用 shared_ptr(new T, my_deleter)
• 类重载了 operator new 且逻辑依赖于单独分配对象（例如按类型分页管理），make_shared 绕过该重载，改用全局或类模板内的分配逻辑
• 对象大小极大（如百 MB 数组），而控制块很小，合并分配可能导致大块内存无法复用（尤其在小对象频繁分配场景下）

实测分配次数差异（以 libc++ 和 libstdc++ 为例）

可通过重载全局 operator new 或使用 malloc_hook（glibc）粗略验证。更可靠的是查看生成的汇编或用 valgrind --tool=massif 观察堆快照：

auto a = std::make_shared(42);        // 1 次 malloc（约 32–48 字节，含控制块）  
auto b = std::shared_ptr(new int(42)); // 2 次 malloc（1 次给 int，1 次给控制块）

实际大小取决于标准库实现：libstdc++ 控制块通常 16 字节（不含虚表指针），libc++ 是 24 字节；加上对齐填充和 int 本身，make_shared 一般只触发一次 32 或 48 字节分配。

真正复杂的地方在于：当 T 是带非平凡构造函数的大结构体，且你又需要自定义销毁逻辑时，就不得不放弃 make_shared ——这时候减少分配次数的目标就得让位于资源管理正确性。