std::make_shared 能减少内存分配次数，因为它将控制块和对象数据合并到一次堆分配中，而直接 new 再构造 shared_ptr 会触发两次独立分配。
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<std::string> ptr(new std::string("hello")); // ❌ 两次分配
即使编译器做了某些优化（如 NRVO 或分配器内联），标准不保证合并；且无法避免控制块中存储的“指向对象的指针”带来的间接访问。
立即学习“C++免费学习笔记（深入）”；
- 控制块中必须保存一个指向对象的指针（用于析构时调用
T的析构函数） - 两次分配导致两块不相邻内存，降低 CPU 缓存命中率
- 异常安全虽有保障（
shared_ptr构造失败会自动清理已分配对象），但性能损失固定存在
make_shared 的限制与容易踩的坑
make_shared 不是万能替代方案，以下情况它无法工作或会出问题：
-
T的构造函数是私有的，且make_shared无法访问（它不参与友元声明，也不像shared_ptr构造函数那样可被显式授权） - 需要自定义删除器（如文件句柄、GPU 内存释放）——
make_shared固定使用delete，必须用shared_ptr<t>(new T, my_deleter)</t> - 类重载了
operator new且逻辑依赖于单独分配对象（例如按类型分页管理），make_shared绕过该重载，改用全局或类模板内的分配逻辑 - 对象大小极大（如百 MB 数组），而控制块很小，合并分配可能导致大块内存无法复用（尤其在小对象频繁分配场景下）
实测分配次数差异（以 libc++ 和 libstdc++ 为例）
可通过重载全局 operator new 或使用 malloc_hook（glibc）粗略验证。更可靠的是查看生成的汇编或用 valgrind --tool=massif 观察堆快照：
auto a = std::make_shared<int>(42); // 1 次 malloc（约 32–48 字节，含控制块） auto b = std::shared_ptr<int>(new int(42)); // 2 次 malloc（1 次给 int，1 次给控制块）
实际大小取决于标准库实现：libstdc++ 控制块通常 16 字节（不含虚表指针），libc++ 是 24 字节；加上对齐填充和 int 本身，make_shared<int></int> 一般只触发一次 32 或 48 字节分配。
真正复杂的地方在于：当 T 是带非平凡构造函数的大结构体，且你又需要自定义销毁逻辑时，就不得不放弃 make_shared ——这时候减少分配次数的目标就得让位于资源管理正确性。
