在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转移到另一个，但不能复制。这就像是你把一本书从一个架子移到另一个架子，书本身还是那一本，只是它的“归属”变了。
而
shared_ptr则引入了共享所有权的概念。多个
shared_ptr可以同时指向并管理同一个资源。它通过内部的引用计数机制来跟踪有多少个
shared_ptr正在共享这个资源。每当一个新的
shared_ptr指向它时，引用计数就增加；当一个
shared_ptr被销毁时，引用计数就减少。只有当引用计数降为零时，资源才会被释放。这种机制在某些场景下非常方便，比如一个数据结构需要多个部分引用同一个对象，并且这些部分各自的生命周期不确定，但又都希望在自己“用完”后，如果没其他人用，对象就能自动销毁。
选择的关键在于你对资源所有权的预期。如果一个对象应该只有一个明确的“主人”，并且这个主人负责它的生老病死，那么
unique_ptr无疑是最佳选择。如果一个对象需要被多个“合作者”共同维护，它的生命周期需要依赖所有合作者的存在，那么
shared_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<MyClass> createMyClass() { return std::make_unique<MyClass>(); } void process() { std::unique_ptr<MyClass> obj = createMyClass(); // obj 独占 MyClass 实例 } -
作为类成员： 当一个类内部拥有一个资源，并且这个资源的生命周期与类实例的生命周期绑定时，
unique_ptr
是完美的成员。class ResourceManager { std::unique_ptr<Resource> resource_; public: ResourceManager() : resource_(std::make_unique<Resource>()) {} // ... };
我个人觉得，如果你发现自己在使用
shared_ptr，但实际上并没有多个对象需要共享这个资源，那多半是过度设计了，或者说，你可能错过了使用
unique_ptr的机会。 何时必须使用
shared_ptr？它解决了哪些
unique_ptr无法处理的场景？
尽管我强调
unique_ptr的优先性，但
shared_ptr在某些特定场景下是不可替代的。它的存在就是为了解决
unique_ptr无法处理的“多所有者”问题。
以下是一些必须使用
shared_ptr的典型场景：
-
真正的共享所有权： 这是最核心的场景。当多个对象确实需要共同拥有一个资源的生命周期时，也就是说，只要这些对象中任何一个还存在，资源就不能被释放，那么
shared_ptr
就是唯一的选择。- 图形场景中的纹理/模型： 多个场景对象可能引用同一个纹理或模型数据。只要有一个对象还在使用它，纹理/模型就应该存在。
- 缓存系统： 缓存中的数据项可能被多个客户端引用。当所有客户端都释放了对该项的引用后，它才能从缓存中移除。
-
图结构中的节点： 在复杂的图数据结构中，一个节点可能被多个其他节点引用。
struct Node { int value; std::vector<std::shared_ptr<Node>> 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> data_; public: MyService(std::shared_ptr<Data> d) : data_(d) {} void startAsyncProcess() { // 假设这是一个异步任务，它需要访问 data_ // data_ 必须在异步任务完成前保持存活 std::thread([this_ptr = data_]() { // 使用拷贝捕获 shared_ptr // 异步操作，安全地访问 *this_ptr std::cout << "Async process using data: " << this_ptr->getValue() << std::endl; }).detach(); } };这里，
data_
被捕获到lambda中，shared_ptr
的引用计数会增加，确保Data
对象在异步任务执行期间不会被销毁。 -
STL容器存储多态对象： 当你需要在一个STL容器中存储指向多态基类的指针，并且这些对象的生命周期需要被容器管理时，
shared_ptr
是一个常见选择。std::vector<std::shared_ptr<BaseClass>> objects; objects.push_back(std::make_shared<DerivedClassA>()); objects.push_back(std::make_shared<DerivedClassB>()); // 容器销毁时，所有对象也会被销毁
使用
shared_ptr的代价是运行时开销，它需要维护一个控制块，其中包含引用计数和弱引用计数，并且这些计数的操作通常是原子性的，以确保多线程安全。这意味着每次拷贝、赋值或销毁
shared_ptr都会比
unique_ptr有更多的CPU指令开销。所以，我的建议是，只有在确实需要共享所有权时，才去接受这份开销。 如何避免
shared_ptr的循环引用问题？
weak_ptr的作用是什么？
shared_ptr虽然强大，但它有一个著名的陷阱：循环引用（Circular References）。这是一种非常隐蔽的内存泄漏形式，它发生在两个或多个
shared_ptr实例相互持有对方的
shared_ptr，导致它们的引用计数永远无法降到零，从而使得它们管理的资源永远不会被释放。
举个例子，假设我们有一个父子关系：父节点拥有子节点，子节点也需要引用父节点。
struct Child; // 前向声明
struct Parent {
std::shared_ptr<Child> child;
~Parent() { std::cout << "Parent destroyed!" << std::endl; }
};
struct Child {
std::shared_ptr<Parent> parent; // 问题所在！
~Child() { std::cout << "Child destroyed!" << std::endl; }
};
void createCycle() {
std::shared_ptr<Parent> p = std::make_shared<Parent>();
std::shared_ptr<Child> c = std::make_shared<Child>();
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> child;
~Parent() { std::cout << "Parent destroyed!" << std::endl; }
};
struct Child {
std::weak_ptr<Parent> 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<Parent> p = std::make_shared<Parent>();
std::shared_ptr<Child> c = std::make_shared<Child>();
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和
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<T>(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的详细内容，更多请关注知识资源分享宝库其它相关文章！
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。