优先使用unique_ptr，因其性能开销最小且语义清晰；仅在需要共享所有权时使用shared_ptr，以避免不必要的性能损耗和循环引用风险。
在C++项目中选择使用
unique_ptr
还是
shared_ptr
，核心原则是：优先考虑
unique_ptr
，因为它代表了独占所有权，性能开销最小，语义也最清晰。只有当确实需要多个对象共同管理一个资源的生命周期时，才应该考虑
shared_ptr
。简单来说，如果你能用
unique_ptr
，就用它；不能用的时候，再看
shared_ptr
是否是合适的解决方案。
解决方案
在C++现代编程中，智能指针是管理动态内存不可或缺的工具，它们极大地简化了资源管理，避免了内存泄漏和悬空指针等常见问题。
unique_ptr
和
shared_ptr
是其中最常用的两种，它们各自承载了不同的所有权语义，理解并正确运用它们是写出健壮、高效C++代码的关键。
从我个人的经验来看，很多初学者，甚至一些有经验的开发者，在面对动态内存管理时，会不自觉地倾向于
shared_ptr
，觉得它“更安全”，因为它能自动处理共享资源的生命周期。但说实话，这种思维方式有时会带来不必要的性能开销和潜在的复杂性。我更倾向于把
unique_ptr
看作是默认选项，因为它最接近原始指针的性能，同时提供了RAII（Resource Acquisition Is Initialization）的强大保障。
unique_ptr
顾名思义，代表着独占所有权。一个资源在任何时刻都只被一个
unique_ptr
拥有。当这个
unique_ptr
超出作用域时，它所指向的资源就会被自动释放。这种独占性使得它的开销几乎可以忽略不计，和原始指针相差无几。它支持移动语义，这意味着所有权可以从一个
unique_ptr
转移到另一个，但不能复制。这就像是你把一本书从一个架子移到另一个架子，书本身还是那一本，只是它的“归属”变了。
立即学习“C++免费学习笔记（深入）”；
而
shared_ptr
则引入了共享所有权的概念。多个
shared_ptr
可以同时指向并管理同一个资源。它通过内部的引用计数机制来跟踪有多少个
shared_ptr
正在共享这个资源。每当一个新的
shared_ptr
指向它时，引用计数就增加；当一个
shared_ptr
被销毁时，引用计数就减少。只有当引用计数降为零时，资源才会被释放。这种机制在某些场景下非常方便，比如一个数据结构需要多个部分引用同一个对象，并且这些部分各自的生命周期不确定，但又都希望在自己“用完”后，如果没其他人用，对象就能自动销毁。
选择的关键在于你对资源所有权的预期。如果一个对象应该只有一个明确的“主人”，并且这个主人负责它的生老病死，那么
unique_ptr
无疑是最佳选择。如果一个对象需要被多个“合作者”共同维护，它的生命周期需要依赖所有合作者的存在，那么
shared_ptr
就成了必需品。
为什么
unique_ptr
unique_ptr
通常是首选，它带来了哪些具体优势？
在我看来，
unique_ptr
之所以是首选，不仅仅是因为它的性能优势，更因为它在语义上的清晰度。当你看到一个
unique_ptr
，你就知道这个资源在这里是独占的，没有其他地方会意外地修改或删除它。这种明确性极大地降低了代码的认知负担和出错的可能性。
具体来说，
unique_ptr
的优势体现在几个方面：
零运行时开销： 这是它最吸引人的地方。
unique_ptr
在运行时几乎没有额外的开销。它只存储一个原始指针，并且在销毁时调用
delete
。没有引用计数，也就没有原子操作（在多线程环境下，
shared_ptr
的引用计数需要原子操作来保证线程安全，这会带来额外的性能成本），这使得它在性能敏感的应用中表现出色。
明确的所有权语义： 它强制执行独占所有权。你不能简单地复制一个
unique_ptr
，只能通过
std::move
来转移所有权。这种限制反而是一种设计上的优势，它让你不得不思考资源的归属问题，避免了无意中的共享和由此引发的复杂生命周期问题。
更好的局部性： 通常，
unique_ptr
管理的资源往往与其所有者在内存上更接近，这有助于提高缓存命中率。
作为工厂函数的返回值：
unique_ptr
非常适合作为工厂函数的返回值。例如，一个函数创建了一个对象并返回其
unique_ptr
，意味着这个函数将所有权交给了调用者。
std::unique_ptr createMyClass() { return std::make_unique();}void process() { std::unique_ptr obj = createMyClass(); // obj 独占 MyClass 实例}
作为类成员： 当一个类内部拥有一个资源，并且这个资源的生命周期与类实例的生命周期绑定时，
unique_ptr
是完美的成员。
class ResourceManager { std::unique_ptr resource_;public: ResourceManager() : resource_(std::make_unique()) {} // ...};
我个人觉得，如果你发现自己在使用
shared_ptr
，但实际上并没有多个对象需要共享这个资源，那多半是过度设计了，或者说，你可能错过了使用
unique_ptr
的机会。
何时必须使用
shared_ptr
shared_ptr
？它解决了哪些
unique_ptr
无法处理的场景？
尽管我强调
unique_ptr
的优先性，但
shared_ptr
在某些特定场景下是不可替代的。它的存在就是为了解决
unique_ptr
无法处理的“多所有者”问题。
以下是一些必须使用
shared_ptr
的典型场景：
真正的共享所有权： 这是最核心的场景。当多个对象确实需要共同拥有一个资源的生命周期时，也就是说，只要这些对象中任何一个还存在，资源就不能被释放，那么
shared_ptr
就是唯一的选择。
图形场景中的纹理/模型： 多个场景对象可能引用同一个纹理或模型数据。只要有一个对象还在使用它，纹理/模型就应该存在。缓存系统： 缓存中的数据项可能被多个客户端引用。当所有客户端都释放了对该项的引用后，它才能从缓存中移除。图结构中的节点： 在复杂的图数据结构中，一个节点可能被多个其他节点引用。
struct Node {int value;std::vector<std::shared_ptr> neighbors; // 邻居共享所有权Node(int v) : value(v) {}};
std::shared_ptrnodeA = std::make_shared(10);std::shared_ptr nodeB = std::make_shared(20);nodeA->neighbors.push_back(nodeB);nodeB->neighbors.push_back(nodeA); // 注意：这里可能引入循环引用，下面会讨论
回调函数和异步操作： 在异步编程或使用回调函数时，一个对象可能需要在原始作用域结束后仍然存活，以便回调函数能够安全地访问它。
class MyService { std::shared_ptr data_;public: MyService(std::shared_ptr d) : data_(d) {} void startAsyncProcess() { // 假设这是一个异步任务，它需要访问 data_ // data_ 必须在异步任务完成前保持存活 std::thread([this_ptr = data_]() { // 使用拷贝捕获 shared_ptr // 异步操作，安全地访问 *this_ptr std::cout << "Async process using data: " <getValue() << std::endl; }).detach(); }};
这里，
data_
被捕获到lambda中，
shared_ptr
的引用计数会增加，确保
Data
对象在异步任务执行期间不会被销毁。
STL容器存储多态对象： 当你需要在一个STL容器中存储指向多态基类的指针，并且这些对象的生命周期需要被容器管理时，
shared_ptr
是一个常见选择。
std::vector<std::shared_ptr> objects;objects.push_back(std::make_shared());objects.push_back(std::make_shared());// 容器销毁时，所有对象也会被销毁
使用
shared_ptr
的代价是运行时开销，它需要维护一个控制块，其中包含引用计数和弱引用计数，并且这些计数的操作通常是原子性的，以确保多线程安全。这意味着每次拷贝、赋值或销毁
shared_ptr
都会比
unique_ptr
有更多的CPU指令开销。所以，我的建议是，只有在确实需要共享所有权时，才去接受这份开销。
如何避免
shared_ptr
shared_ptr
的循环引用问题？
weak_ptr
的作用是什么？
shared_ptr
虽然强大，但它有一个著名的陷阱：循环引用（Circular References）。这是一种非常隐蔽的内存泄漏形式，它发生在两个或多个
shared_ptr
实例相互持有对方的
shared_ptr
，导致它们的引用计数永远无法降到零，从而使得它们管理的资源永远不会被释放。
举个例子，假设我们有一个父子关系：父节点拥有子节点，子节点也需要引用父节点。
struct Child; // 前向声明struct Parent { std::shared_ptr child; ~Parent() { std::cout << "Parent destroyed!" << std::endl; }};struct Child { std::shared_ptr parent; // 问题所在！ ~Child() { std::cout << "Child destroyed!" << std::endl; }};void createCycle() { std::shared_ptr p = std::make_shared(); std::shared_ptr c = std::make_shared(); p->child = c; // p 拥有 c c->parent = p; // c 拥有 p // 此时 p 的引用计数为 2 (p 和 c->parent) // c 的引用计数为 2 (c 和 p->child)} // p 和 c 离开作用域，引用计数各自减 1，但都仍为 1，导致内存泄漏
当
createCycle
函数结束时，
p
和
c
这两个
shared_ptr
局部变量会被销毁，它们的引用计数会减1。但由于它们互相引用，
p
的引用计数仍然是1（来自
c->parent
），
c
的引用计数也是1（来自
p->child
）。结果是，
Parent
和
Child
对象都不会被销毁，造成内存泄漏。
为了解决这个问题，C++标准库引入了
std::weak_ptr
。
weak_ptr
是一种非拥有型（non-owning）的智能指针。它指向一个由
shared_ptr
管理的对象，但它本身不增加对象的引用计数。这意味着
weak_ptr
的存在不会阻止对象被销毁。
weak_ptr
的主要作用就是：
打破循环引用： 在上述父子关系中，我们可以让子节点通过
weak_ptr
引用父节点。这样，子节点可以访问父节点，但不会增加父节点的引用计数，从而避免循环。安全访问已销毁对象：
weak_ptr
不能直接访问它指向的对象。你需要先通过调用其
lock()
方法，尝试将其转换为一个
shared_ptr
。如果对象仍然存在（即其
shared_ptr
引用计数大于0），
lock()
会返回一个有效的
shared_ptr
；否则，它会返回一个空的
shared_ptr
。这提供了一种安全的机制来检查对象是否仍然存活。
修改上述循环引用示例：
struct Child; // 前向声明struct Parent { std::shared_ptr child; ~Parent() { std::cout << "Parent destroyed!" << std::endl; }};struct Child { std::weak_ptr parent; // 使用 weak_ptr 引用父节点 ~Child() { std::cout << "Child destroyed!" << std::endl; } void accessParent() { if (auto p_locked = parent.lock()) { // 尝试锁定为 shared_ptr std::cout << "Child is accessing a live parent." << std::endl; } else { std::cout << "Parent has been destroyed." << std::endl; } }};void createNoCycle() { std::shared_ptr p = std::make_shared(); std::shared_ptr c = std::make_shared(); p->child = c; // Parent 拥有 Child c->parent = p; // Child 弱引用 Parent // 此时 p 的引用计数为 1 (p) // c 的引用计数为 2 (c 和 p->child)} // p 和 c 离开作用域，引用计数各自减 1，最终都会降到 0，对象被正确销毁
在这个修正后的版本中，
Parent
仍然通过
shared_ptr
拥有
Child
，所以
Child
的生命周期依赖于
Parent
。但是
Child
通过
weak_ptr
引用
Parent
，它只是一个观察者，不参与
Parent
的生命周期管理。当
createNoCycle
函数结束时，
p
和
c
的局部
shared_ptr
被销毁，
p
的引用计数变为0，
Parent
对象被销毁。接着，
Parent
的析构函数会销毁其
Child
成员，
c
的引用计数也随之降为0，
Child
对象也被销毁。这样就避免了内存泄漏。
所以，在设计数据结构时，如果发现有相互引用的情况，并且其中一个引用不应该承担所有权责任，那么
weak_ptr
就是那个打破僵局的关键。它让你可以建立复杂的对象关系，同时保持清晰的生命周期管理。
在性能敏感的场景下，
unique_ptr
unique_ptr
和
shared_ptr
的性能差异有多大？
在性能敏感的场景下，
unique_ptr
和
shared_ptr
的性能差异确实是值得关注的。这不仅仅是理论上的，在实际的“热点”代码路径中，这些差异可以累积成显著的性能瓶颈。
unique_ptr
的性能：
几乎零开销：
unique_ptr
的开销与原始指针几乎相同。它只存储一个原始指针，没有额外的控制块分配，没有引用计数，也没有原子操作。构造/析构： 创建一个
unique_ptr
（例如通过
std::make_unique
）通常只涉及一次堆内存分配（针对被管理的对象本身）和一次指针赋值。销毁时也只是调用一次
delete
。移动：
unique_ptr
的移动操作是极其高效的，它只是简单地复制原始指针并置空源指针。内存占用： 仅占用一个指针的大小。
shared_ptr
的性能：
控制块开销：
shared_ptr
需要管理一个“控制块”（control block），这个控制块通常在堆上分配，包含了引用计数和弱引用计数，以及一个自定义删除器（如果指定了）。这意味着，每当你通过
std::make_shared
或
std::shared_ptr(new T())
创建一个新的
shared_ptr
时，至少会发生两次堆内存分配（一次是对象本身，一次是控制块）。
std::make_shared
通常更优，因为它可以在一次分配中完成对象和控制块的创建，减少了内存碎片和分配开销。引用计数操作： 每次拷贝
shared_ptr
、赋值
shared_ptr
或销毁
shared_ptr
时，都需要对引用计数进行原子增减操作。原子操作比普通的非原子操作要慢，因为它们涉及到内存屏障和CPU缓存同步，以确保在多线程环境下的正确性。在单线程环境中，一些实现可能会优化掉原子操作的开销，但这并不总是保证的。内存占用：
shared_ptr
通常占用两个指针的大小（一个指向被管理对象，一个指向控制块）。缓存效应： 由于控制块通常与被管理对象分开存储，这可能对CPU缓存的局部性产生负面影响，尤其是在频繁创建和销毁
shared_ptr
的场景下。
量化差异：具体性能差异很难给出精确的数字，因为它高度依赖于CPU架构、编译器优化、内存子系统性能以及具体的使用模式。但大致上，我们可以这样理解：
内存分配/释放：
shared_ptr
在创建和销毁时通常会涉及更多的堆操作，尤其是在没有使用
make_shared
的情况下。引用计数操作： 每次引用计数的增减，即使在单线程环境下，也至少是一次内存写入操作。而在多线程环境下，原子操作的开销可能比非原子操作高出10倍甚至更多。内存占用：
shared_ptr
比
unique_ptr
多占用一个指针的内存。在存储大量智能指针的容器中，这会累积成可观的内存消耗。
总结：对于大多数业务逻辑代码，
shared_ptr
的性能开销是完全可以接受的，它带来的便利性和安全性远远超过了这点开销。然而，在以下场景中，你可能需要仔细考虑并优先使用
unique_ptr
：
高性能计算： 例如游戏引擎、实时系统、科学计算等，其中每个CPU周期都很宝贵。高并发系统： 大量
shared_ptr
在多个线程之间频繁拷贝和传递，会导致引用计数原子操作成为竞争热点，严重影响扩展性。内存受限环境： 嵌入式系统或需要处理海量对象的应用，额外的内存占用和堆分配开销可能成为问题。
我的建议是，始终从
unique_ptr
开始，只有在确实需要共享所有权时，才引入
shared_ptr
。如果你的代码在性能分析后发现
shared_ptr
是瓶颈，那么才值得投入精力去优化其使用方式，例如通过
std::make_shared
减少分配，或者重新审视设计，看是否能用
unique_ptr
或
weak_ptr
替代。
以上就是在C++项目中如何选择使用unique_ptr还是shared_ptr的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1473772.html
微信扫一扫 
支付宝扫一扫 
