c++如何利用std::make_shared创建对象_c++ 内存分配优化与效率测试【方法】

std::make_shared 为什么比 new + std::shared_ptr 构造更高效

因为 std::make_shared 在一次内存分配中同时构造控制块（control block）和对象本身，而 new T + std::shared_ptr(new T) 需要两次独立分配：一次给对象，一次给控制块。这对小对象尤其明显——减少分配次数 = 减少系统调用开销 + 更好缓存局部性。

注意：这种优化仅在对象类型不为数组、不含自定义删除器、且构造函数不抛异常（或已处理）时稳定生效。

• 控制块包含引用计数、弱引用计数、删除器等元数据，大小固定但不可忽略（通常 16–32 字节）
• 若对象本身只有几个字节（如 int、std::pair），两次分配的开销可能超过对象本身的内存占用
• 使用 std::make_shared 后，对象与控制块大概率位于同一 cache line，降低 false sharing 风险

std::make_shared 的正确调用方式与常见误用

必须严格匹配目标类型的构造函数签名；不能用于需要自定义删除器或分配器的场景；不支持数组类型（C++20 前）。

auto p1 = std::make_shared("hello");           // ✅ 正常构造
auto p2 = std::make_shared>(10, 42);    // ✅ 带参数构造
auto p3 = std::make_shared(123);                      // ✅ 内置类型也支持
// ❌ 错误：无法传入自定义删除器
// auto p4 = std::make_shared(fopen("x.txt", "r"), [](FILE* f) { fclose(f); }); // 编译失败
// ✅ 替代写法（必须用裸指针构造）
auto p4 = std::shared_ptr(fopen("x.txt", "r"), [](FILE* f) { fclose(f); });

• 所有参数都会被完美转发（perfect forwarding），所以 std::move、左值引用、初始化列表都可直接传递
• 若类有 explicit 构造函数，std::make_shared 仍可调用（它不涉及隐式转换）
• 不要试图对继承体系做“向下转型”后再用 make_shared：它返回的是确切模板类型，不是基类指针

如何实测 make_shared 与手写 new 的性能差异

关键不是看单次耗时，而是看大量短生命周期对象下的分配吞吐量与内存碎片趋势。推荐用 std::chrono::high_resolution_clock + 循环 10⁵~10⁶ 次，并禁用 ASLR 和 malloc 调试模式（如 Linux 下避免 export MALLOC_CHECK_=1）。

Proface Avatarize

一个利用AI技术提供高质量专业头像和头像的工具

下载

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

void benchmark_make_shared() {
    constexpr size_t N = 100000;
    auto start = std::chrono::high_resolution_clock::now();
    for (size_t i = 0; i < N; ++i) {
        auto p = std::make_shared>(i, i * 2.0);
    }
    auto end = std::chrono::high_resolution_clock::now();
    auto us = std::chrono::duration_cast(end - start).count();
    std::cout << "make_shared: " << us << " μs\n";
}
void benchmark_raw_new() {
constexpr size_t N = 100000;
auto start = std::chrono::high_resolution_clock::now();
for (size_t i = 0; i < N; ++i) {
auto p = std::shared_ptr>(new std::complex(i, i * 2.0));
}
auto end = std::chrono::high_resolution_clock::now();
auto us = std::chrono::duration_cast(end - start).count();
std::cout << "raw new: " << us << " μs\n";
}

• 测试时关闭编译器优化（-O0）会掩盖真实差异，建议至少用 -O2
• 观察 RSS 内存峰值：手写 new 方式更容易因分配器策略导致碎片升高
• 在容器中反复创建/销毁 shared_ptr（如 std::vector>）时，差异更显著

什么情况下不该用 std::make_shared

当对象构造可能抛异常，且你希望控制块和对象的生命周期解耦时；或者你需要把 shared_ptr 绑定到栈对象、文件描述符、或非 new 分配的内存上。

• 栈对象绑定：int x = 42; auto p = std::shared_ptr(&x, [](int*){}); —— make_shared 无法做到
• 定制分配器：std::make_shared 不接受 allocator 参数（C++20 引入了 std::allocate_shared）
• 构造函数抛异常风险高，且你依赖控制块存活来记录日志：此时分开分配能确保控制块早于对象构造完成，便于异常安全清理
• 多态对象需从派生类构造后向上转型，且基类析构非 virtual：虽然罕见，但 make_shared() 返回的是 shared_ptr，转成 shared_ptr 后仍共享同一控制块，一般没问题；但若 Base 析构不 virtual，行为未定义 —— 这是设计问题，不是 make_shared 的锅

真正容易被忽略的是：std::make_shared 对齐行为由分配器决定，而默认全局 new 的对齐可能和你的 SIMD 类型要求不一致；如果对象含 alignas(32) 成员，某些旧版 libstdc++ 可能未正确对齐控制块区域，导致运行时崩溃 —— 这类边界情况需实测验证。