在C++项目中如何选择使用unique_ptr还是shared_ptr

优先使用unique_ptr，因其性能开销最小且语义清晰；仅在需要共享所有权时使用shared_ptr，以避免不必要的性能损耗和循环引用风险。

在C++项目中选择使用

unique_ptr

shared_ptr

unique_ptr

shared_ptr

unique_ptr

shared_ptr

解决方案

在C++现代编程中，智能指针是管理动态内存不可或缺的工具，它们极大地简化了资源管理，避免了内存泄漏和悬空指针等常见问题。

unique_ptr

shared_ptr

从我个人的经验来看，很多初学者，甚至一些有经验的开发者，在面对动态内存管理时，会不自觉地倾向于

shared_ptr

unique_ptr

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

  登录后复制
  在运行时几乎没有额外的开销。它只存储一个原始指针，并且在销毁时调用

  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

  登录后复制
  就是唯一的选择。
  

  笔目鱼英文论文写作器

  写高质量英文论文，就用笔目鱼

  87

  查看详情
  • 图形场景中的纹理/模型： 多个场景对象可能引用同一个纹理或模型数据。只要有一个对象还在使用它，纹理/模型就应该存在。
  • 缓存系统： 缓存中的数据项可能被多个客户端引用。当所有客户端都释放了对该项的引用后，它才能从缓存中移除。
  • 图结构中的节点： 在复杂的图数据结构中，一个节点可能被多个其他节点引用。

    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

如何避免

shared_ptr

登录后复制

的循环引用问题？

weak_ptr

登录后复制

的作用是什么？

shared_ptr

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

p

c->parent

c

p->child

Parent

Child

为了解决这个问题，C++标准库引入了

std::weak_ptr

weak_ptr

shared_ptr

weak_ptr

weak_ptr

1. 打破循环引用： 在上述父子关系中，我们可以让子节点通过

   weak_ptr

   登录后复制
   引用父节点。这样，子节点可以访问父节点，但不会增加父节点的引用计数，从而避免循环。
2. 安全访问已销毁对象：

   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

Parent

Parent

Child

c

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的详细内容，更多请关注php中文网其它相关文章！