unique_ptr独占资源所有权，无引用计数，性能高；shared_ptr共享所有权，通过引用计数管理生命周期，但有性能开销和循环引用风险。
C++内存管理中，
unique_ptr
和
shared_ptr
的核心区别在于它们对资源所有权的管理策略：
unique_ptr
强制独占所有权，即同一时间只有一个指针能管理特定资源；而
shared_ptr
则实现共享所有权，允许多个指针共同管理同一资源，直到所有引用都失效才释放。这种所有权模型的不同，决定了它们各自的适用场景和内存管理开销。
当我们在C++中谈论内存管理，尤其是在现代C++的语境下，智能指针是绕不开的话题。它们被设计出来，就是为了解决传统裸指针带来的内存泄漏、悬空指针等一系列头疼问题，将资源管理自动化。但
unique_ptr
和
shared_ptr
虽然都属于智能指针家族，它们在设计哲学和实际应用中却有着根本性的差异。
unique_ptr
，顾名思义，强调的是“唯一”性。它就像你买了一件限量版的艺术品，只有你拥有它。你可以把它转赠给别人（通过移动语义），但一旦转赠，你就不能再声称拥有了。这意味着
unique_ptr
所指向的资源，在任何时刻都只由一个
unique_ptr
实例来管理。当这个
unique_ptr
的生命周期结束时，它所管理的资源就会被自动释放。这种独占性带来了极低的运行时开销，因为它不需要维护引用计数，性能几乎可以与裸指针媲美。然而，它的代价是不能被复制，只能被移动，这严格限制了资源所有权的传递方式。
shared_ptr
则完全是另一种思路，它强调“共享”。你可以把它想象成你和几个朋友合伙买了一辆车，你们都可以使用，但只有当所有合伙人都放弃了对这辆车的使用权（即所有
shared_ptr
实例都被销毁或重新赋值）时，这辆车才会被处理掉。
shared_ptr
通过内部的引用计数（reference count）机制来追踪有多少个
shared_ptr
实例正在指向同一个资源。每当一个新的
shared_ptr
被创建并指向该资源，引用计数就增加；每当一个
shared_ptr
被销毁或重新赋值，引用计数就减少。只有当引用计数降为零时，资源才会被真正释放。这种机制在处理多方共享资源时非常方便，但它也带来了额外的开销，主要是引用计数需要原子操作来保证多线程安全，以及可能引发循环引用问题。
立即学习“C++免费学习笔记（深入）”；
为什么
unique_ptr
unique_ptr
比
shared_ptr
更“轻量”？（以及何时优先选择它）
“轻量”这个词，在
unique_ptr
这里，不仅仅是一种感觉，更是实实在在的性能优势。
unique_ptr
在设计上，几乎没有额外的运行时开销。它内部通常只存储一个裸指针，不涉及引用计数的增减操作，更没有原子操作带来的性能负担。这意味着，当你需要一个资源具有明确的独占所有权，并且这个资源不会被多个地方共享时，
unique_ptr
是你的不二之选。
比如，一个函数内部创建的对象，或者一个类成员变量，它只由该类实例拥有和管理，那么
unique_ptr
就是最合适的。我个人觉得，很多时候，我们其实并不需要共享所有权，只是懒得手动管理内存。在这种情况下，
unique_ptr
就是那个“刚好够用”的工具，它提供了内存安全，同时保持了接近裸指针的性能。当你发现你的设计中，一个对象的所有权是明确且单一的，不要犹豫，
unique_ptr
往往是更好的选择。它甚至可以作为工厂函数的返回类型，明确地将新创建对象的所有权转移给调用者，这在API设计中非常有用。
// 示例：unique_ptr作为函数返回值，转移所有权std::unique_ptr createObject() { // MyObject的创建和管理完全由unique_ptr负责 return std::make_unique(); }// 示例：类成员变量，独占资源class ResourceManager {private: std::unique_ptr _resource; // 资源由ResourceManager独占public: ResourceManager() : _resource(std::make_unique()) { // ... } // ...};
这种独占性让代码意图更加清晰，也避免了不必要的开销。
shared_ptr
shared_ptr
如何解决资源共享的复杂性？它又带来了哪些“甜蜜的负担”？
shared_ptr
的出现，确实解决了C++中一个长期存在的痛点：多个对象需要共同管理同一块内存，并且需要在最后一个使用者释放时才真正销毁。这在很多设计模式中都非常有用，比如观察者模式、缓存管理、或者一些图形渲染场景，多个渲染组件可能需要访问同一个纹理或模型数据。它的“甜蜜”之处在于，你不需要关心谁是最后一个使用者，
shared_ptr
的引用计数机制会自动帮你处理。你可以随意拷贝
shared_ptr
，将其作为函数参数传递，或者存储在容器中，而不用担心资源被提前释放。这种便利性极大地简化了复杂对象图的内存管理。
然而，这种“甜蜜”并非没有代价。首先是性能开销，引用计数的增减通常需要原子操作来保证多线程环境下的正确性，这比简单的指针赋值要慢。其次，也是更隐蔽且棘手的问题：循环引用（circular dependency）。如果对象A持有一个指向B的
shared_ptr
，同时对象B又持有一个指向A的
shared_ptr
，那么即使外部没有其他
shared_ptr
指向A或B，它们的引用计数也永远不会降为零，导致内存泄漏。这就像两个人都在等待对方先放手，结果谁也放不了手，资源就永远得不到释放。
// 示例：循环引用问题class B; // 前向声明class A {public: std::shared_ptr b_ptr; ~A() { std::cout << "A destroyed" << std::endl; }};class B {public: // 如果这里是shared_ptr，就会形成循环引用 std::shared_ptr a_ptr; ~B() { std::cout << "B destroyed" << std::endl; }};void demonstrateCircularReference() { auto a = std::make_shared(); auto b = std::make_shared(); a->b_ptr = b; // b的引用计数变为2 (a->b_ptr和b) b->a_ptr = a; // a的引用计数变为2 (b->a_ptr和a) // 当a和b离开作用域时，它们的引用计数会减到1，但不会到0，导致内存泄漏}
解决循环引用通常需要引入
weak_ptr
。
weak_ptr
是一种不增加引用计数的智能指针，它允许你观察一个
shared_ptr
所管理的对象，但不会影响其生命周期。当你需要访问对象时，可以尝试将其转换为
shared_ptr
（通过
lock()
方法），如果对象已被销毁，
lock()
会返回一个空的
shared_ptr
。
// 解决循环引用：使用weak_ptrclass B_Fixed;class A_Fixed {public: std::shared_ptr b_ptr; ~A_Fixed() { std::cout << "A_Fixed destroyed" << std::endl; }};class B_Fixed {public: std::weak_ptr a_ptr; // 使用weak_ptr打破循环 ~B_Fixed() { std::cout << "B_Fixed destroyed" << std::endl; }};void demonstrateFixedCircularReference() { auto a = std::make_shared(); auto b = std::make_shared(); a->b_ptr = b; // b的引用计数为1 b->a_ptr = a; // a的引用计数为1 (weak_ptr不增加计数) // 当a和b离开作用域时，引用计数会正确降到0，资源会被释放}
weak_ptr
在处理那些“可能存在，也可能不存在”的引用关系时非常有用，它提供了一种安全的访问机制，避免了悬空指针。
什么时候
std::make_unique
std::make_unique
和
std::make_shared
是更好的实践？它们又避免了什么潜在陷阱？
在现代C++编程中，直接使用
new
来创建对象并将其传递给智能指针的构造函数，通常被认为是不太好的实践。而
std::make_unique
和
std::make_shared
正是为了解决这个问题而存在的，它们不仅提供了一种更简洁、更安全的方式来创建智能指针，还避免了某些潜在的资源泄漏。
最主要的陷阱在于异常安全性。考虑这样一个函数调用：
foo(std::shared_ptr(new T()), functionThatMightThrow());
这里涉及到三个操作：
new T()
（分配内存并构造对象），
std::shared_ptr
的构造（接管裸指针），以及
functionThatMightThrow()
（一个可能抛出异常的函数）。C++标准不保证这三个操作的执行顺序。如果
new T()
执行了，但
functionThatMightThrow()
在
std::shared_ptr
构造完成之前抛出了异常，那么
new T()
分配的内存将永远无法被
shared_ptr
接管，从而导致内存泄漏。
而
std::make_shared()
和
std::make_unique()
则能避免这种中间状态。它们会一次性地分配内存，对于
make_shared
，这包括对象本身和智能指针所需的控制块；对于
make_unique
，则仅仅是对象本身。这样，要么整个操作成功，要么整个操作失败并回滚，不会出现资源分配了但智能指针还没来得及接管的情况。它们将裸指针的创建和智能指针的构造绑定在一起，确保了异常安全。
此外，
std::make_shared
还有一个额外的性能优势：它能够将对象数据和智能指针的控制块（包含引用计数等信息）在堆上进行一次性分配。这相比于先
new T()
再构造
shared_ptr
（后者会再次在堆上分配控制块）减少了一次内存分配的开销，并且由于更好的内存局部性，可能带来更好的缓存性能。
std::make_unique
虽然没有控制块的额外开销，但它同样保证了异常安全性和简洁性。
因此，我的建议是，除非有非常特殊的原因（比如需要自定义删除器或者从已有的裸指针接管），否则总是优先使用
std::make_unique
和
std::make_shared
来创建智能指针。它们是现代C++内存管理中，兼顾安全、性能和代码可读性的最佳实践。
// 避免潜在陷阱的示例// 不推荐：可能导致内存泄漏// foo(std::shared_ptr(new MyObject()), potentially_throwing_function());// 推荐：异常安全且高效// foo(std::make_shared(), potentially_throwing_function());// std::make_unique的创建示例auto myUniqueObj = std::make_unique();// std::make_unique也可以用于数组auto myUniqueArray = std::make_unique(10);
这些辅助函数不仅让代码更健壮，也更清晰地表达了程序员的意图。它们是C++智能指针生态中不可或缺的一部分。
以上就是C++内存管理基础中unique_ptr与shared_ptr区别的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1474810.html
微信扫一扫 
支付宝扫一扫 
