为什么应该优先使用std::make_shared而不是直接用new构造shared

为什么应该优先使用std::make_shared而不是直接用new构造shared_ptr

P粉602998670

发布： 2025-09-03 09:39:01

原创

1017人浏览过

使用std::make_shared更高效，因它合并对象和控制块的内存分配为一次，减少开销并提升异常安全性；而用new构造需两次分配，性能更低且有泄漏风险。

为什么应该优先使用std::make_shared而不是直接用new构造shared_ptr

直接使用

std::make_shared

登录后复制

通常更高效，因为它能减少一次内存分配。它将对象本身和 shared_ptr 的控制块（引用计数等信息）分配在同一块连续的内存中。

std::make_shared 通常是首选的 shared_ptr 构造方法，因为它具有性能优势和异常安全性。

为什么使用

new

登录后复制

构造

shared_ptr

登录后复制

会降低性能？

当你使用

new

登录后复制

分配对象，然后用这个指针构造

shared_ptr

登录后复制

时，实际上发生了两次内存分配。第一次是为对象本身分配内存，第二次是为

shared_ptr

登录后复制

的控制块分配内存。

std::make_shared

登录后复制

将这两者合并为一次分配，减少了内存分配的开销，也减少了内存碎片化的可能性。想象一下，你搬家，

std::make_shared

登录后复制

就像一次性打包所有东西，而

new

登录后复制

分配再构造就像先搬家具，再搬杂物，费时费力。

更具体地说，控制块包含了引用计数、weak count（用于

weak_ptr

登录后复制

）以及可能的自定义删除器。这些信息对于

shared_ptr

登录后复制

的正常工作至关重要。

std::make_shared

登录后复制

如何提高异常安全性？

考虑以下代码：

process_widget(std::shared_ptr<Widget>(new Widget), function_that_might_throw());

登录后复制

如果

new Widget

登录后复制

成功执行，但

function_that_might_throw()

登录后复制

抛出了异常，那么

new Widget

登录后复制

返回的指针将会泄漏，因为

shared_ptr

登录后复制

还没有构造成功。

使用

std::make_shared

登录后复制

可以避免这个问题：

AppMall应用商店

AI应用商店，提供即时交付、按需付费的人工智能应用服务

查看详情

process_widget(std::make_shared<Widget>(), function_that_might_throw());

登录后复制

std::make_shared

登录后复制

在一次操作中完成对象的分配和

shared_ptr

登录后复制

的构造，要么全部成功，要么全部失败，从而保证了异常安全性。

std::make_shared

登录后复制

有什么缺点吗？

虽然

std::make_shared

登录后复制

优点很多，但也有一些情况下不适合使用。

自定义删除器： 如果你需要使用自定义删除器，并且删除器的大小很大，那么将其存储在控制块中可能会造成额外的内存开销。在这种情况下，使用
```
new
```
登录后复制
分配对象，然后使用自定义删除器构造
```
shared_ptr
```
登录后复制
可能更合适。
内存占用： 当
```
weak_ptr
```
登录后复制
指向由
```
std::make_shared
```
登录后复制
创建的对象时，即使所有
```
shared_ptr
```
登录后复制
都被销毁，控制块仍然存在，直到所有
```
weak_ptr
```
登录后复制
也被销毁。这意味着对象占用的内存可能无法立即释放。不过，这通常不是一个严重的问题，除非内存资源非常有限。
不完全类型：
```
std::make_shared
```
登录后复制
需要在调用时知道模板参数的完整类型。如果你的类是不完全类型（例如，只有声明而没有定义），则不能使用
```
std::make_shared
```
登录后复制
。