C++如何实现shared_ptr引用计数机制（如何实现.计数.引用.机制.shared_ptr...）

shared_ptr通过独立控制块实现引用计数，控制块包含指向对象的指针、强弱引用计数及删除器；多个shared_ptr共享同一控制块，构造、拷贝时增加强引用计数，析构或赋值时减少，归零则销毁对象；weak_ptr通过弱引用计数观察对象而不影响其生命周期；控制块支持自定义删除器与非侵入式管理，解耦计数与对象；多线程下引用计数操作为原子操作，保证线程安全；简化实现需注意原子性、控制块生命周期、自赋值检查与异常安全；相比unique_ptr的独占所有权，shared_ptr适用于共享所有权场景，但有性能开销。

C++中

shared_ptr

实现引用计数的核心机制，在于它将对象所有权的管理与实际对象的生命周期解耦，通过一个独立的“控制块”（Control Block）来维护引用计数。这个控制块通常包含指向实际对象的指针、强引用计数（

shared_ptr

的数量）和弱引用计数（

weak_ptr

的数量），以及可能的自定义删除器和分配器。每当一个

shared_ptr

被创建、拷贝或赋值时，其内部的强引用计数会相应地增加；当一个

shared_ptr

被销毁或重新赋值时，强引用计数则会减少。当强引用计数归零时，

shared_ptr

便会负责销毁它所管理的对象。 解决方案

shared_ptr

的引用计数机制主要依赖于以下几个关键组件和操作：

1. 控制块（Control Block）：

   • 这是一个动态分配的辅助数据结构，与被管理对象（Managed Object）生命周期独立。
   • 它至少包含：

     • T* ptr

       ：指向实际被管理对象的裸指针。

     • std::atomic_long shared_count

       ：强引用计数，记录有多少个

       shared_ptr

       实例正在引用该对象。

     • std::atomic_long weak_count

       ：弱引用计数，记录有多少个

       weak_ptr

       实例正在观察该对象。
     • 可选的自定义删除器（

       Deleter

       ）和分配器（

       Allocator

       ）。
   • 一个被多个

     shared_ptr

     共同管理的对象，只对应一个控制块。

2. shared_ptr

   实例：
   • 每个

     shared_ptr

     实例内部都存储两个指针：
     • 一个是指向被管理对象的裸指针（

       T*

       ）。
     • 另一个是指向其对应的控制块的指针（

       ControlBlock*

       ）。

3. 引用计数的生命周期管理：

   • 构造函数：
     • 当从一个裸指针或另一个

       shared_ptr

       构造时，如果这是第一个

       shared_ptr

       ，会创建一个新的控制块，将强引用计数初始化为1，弱引用计数初始化为0。
     • 如果是拷贝构造，则简单地将源

       shared_ptr

       的控制块指针和对象指针复制过来，并将控制块中的强引用计数原子性地增加1。
   • 拷贝赋值运算符：
     • 首先，它会递减当前

       shared_ptr

       所管理对象的强引用计数。
     • 接着，它会复制源

       shared_ptr

       的控制块指针和对象指针，并将新管理对象的强引用计数原子性地增加1。
     • 如果旧的强引用计数归零，则会检查并可能删除旧的对象。
   • 析构函数：
     • 当

       shared_ptr

       实例被销毁时，它会原子性地递减其控制块中的强引用计数。
     • 如果强引用计数递减后变为0：
       • 它会调用自定义删除器（如果存在）或

         delete

         操作符来销毁被管理对象。
       • 然后，它会检查弱引用计数。如果弱引用计数也为0，说明没有任何

         weak_ptr

         还在观察这个控制块，此时控制块本身也会被销毁。
     • 如果强引用计数不为0，则对象和控制块都保持不变。

4. weak_ptr

   的作用：

   • weak_ptr

     在构造时，会增加控制块中的弱引用计数。

   • weak_ptr

     的析构会减少弱引用计数。

   • weak_ptr

     不会影响对象的生命周期，它只是一个观察者。当强引用计数归零，对象被销毁后，

     weak_ptr

     通过

     lock()

     方法尝试获取

     shared_ptr

     会失败（返回空的

     shared_ptr

     ）。

这种设计确保了在多个

shared_ptr

实例共同拥有一个对象时，对象的生命周期能够被正确地管理，并且在最后一个

shared_ptr

离开作用域时，对象才会被安全地销毁。

shared_ptr

为何需要一个独立的控制块（Control Block）来管理引用计数？

在我看来，

shared_ptr

采用独立控制块的设计，是其灵活性和强大功能的核心所在，并非仅仅是为了存储引用计数那么简单。

首先，它实现了引用计数与被管理对象的解耦。想象一下，如果引用计数直接内嵌在被管理对象内部，那么所有被

shared_ptr

管理的对象都必须是可修改的，并且必须在堆上分配。但实际应用中，我们可能需要管理一个栈上的对象（虽然不常见，但理论上可能），或者一个由C风格API返回的内存块，甚至是一个自定义资源（如文件句柄、数据库连接）。这些对象可能没有地方存放引用计数，或者它们本身就不是通过

new

分配的。通过一个外部的控制块，

shared_ptr

能够以统一的方式管理各种类型的资源，无论它们是如何分配的，或者它们是否包含内部状态。这是一种非常优雅的抽象。

其次，支持自定义删除器和分配器。控制块是存储这些自定义逻辑的理想场所。比如，你可能需要用

free()

而不是

delete

来释放C风格的内存，或者需要关闭一个文件句柄。这些操作与对象的类型紧密相关，但与

shared_ptr

本身的类型无关。将这些信息放在控制块中，允许

shared_ptr

在析构时执行正确的清理操作，极大地增强了其通用性。

再者，

weak_ptr

的实现离不开控制块。

weak_ptr

的目的是在不延长对象生命周期的情况下观察对象。它通过弱引用计数来判断对象是否仍然存活。当所有

shared_ptr

都已销毁，强引用计数归零，对象被删除后，

weak_ptr

依然可以知道对象已经不存在了，因为控制块仍然存在（只要还有

weak_ptr

在观察），并且其中的强引用计数已经为零。如果控制块与对象一同销毁，

weak_ptr

将无法安全地判断对象状态，甚至可能导致悬空指针。这是一种精妙的设计，它允许我们在不引入循环引用风险的情况下，实现复杂的对象依赖关系。

从内存布局和性能角度看，虽然引入控制块会增加一点点内存开销和间接性，但它避免了对被管理对象本身的侵入式修改，这在很多场景下是不可接受的。而且，对于同一个对象，无论有多少个

shared_ptr

指向它，都只对应一个控制块，这在一定程度上也避免了冗余。在我看来，这种设计上的权衡是值得的，它赋予了

shared_ptr

无与伦比的灵活性和健壮性。

shared_ptr

的引用计数在多线程环境下是如何保证安全的？

多线程环境下，引用计数的安全性是

shared_ptr

设计中一个至关重要的考量，也是其内部复杂性所在。简单地使用一个

int

类型的计数器进行增减操作是绝对不够的，因为这些操作并非原子性的，可能导致竞态条件（race condition）。

shared_ptr

通过使用原子操作（Atomic Operations）来确保引用计数的线程安全。C++标准库通常会利用

std::atomic

系列类型（如

std::atomic_long

）或底层平台提供的原子指令（如

fetch_add

,

fetch_sub

等）来实现引用计数的增减。 Post AI

博客文章AI生成器

50 查看详情

具体来说：

1. 原子性增减：当一个

   shared_ptr

   被拷贝或析构时，它对控制块中的强引用计数（

   shared_count

   ）和弱引用计数（

   weak_count

   ）的增减操作，都是通过原子指令完成的。这意味着，即使多个线程同时尝试修改同一个计数器，这些操作也会以一种互不干扰、线性化的方式执行，保证了计数器的值始终是正确的，不会出现丢失更新或错误读取的情况。例如，

   std::atomic_long::fetch_add(1)

   操作会原子性地读取当前值，将其加1，然后写回新值，整个过程不可中断。

2. 内存顺序（Memory Ordering）：除了原子操作本身，现代处理器为了性能优化，可能会重排指令的执行顺序。这可能导致在一个线程中对共享变量的修改，在另一个线程中无法立即看到，或者看到的是旧值。

   std::atomic

   类型通常会伴随默认的内存顺序（如

   memory_order_seq_cst

   或

   memory_order_acquire

   /

   release

   ），确保在引用计数操作前后，相关的内存操作（如对象的构造或析构）能够被正确地同步和可见。这保证了当引用计数达到0并触发对象删除时，所有线程都能看到这个事件，并且被删除对象的状态在删除前是正确的。

3. 性能考量：原子操作通常比非原子操作要慢，因为它们可能涉及CPU缓存同步、内存屏障（memory barrier）等开销。然而，这种开销是保证多线程环境下正确性的必要代价。

   shared_ptr

   的设计者们在性能和正确性之间找到了一个平衡点。在大多数情况下，引用计数的增减频率相对较低，因此原子操作带来的额外开销是可以接受的。当然，如果在一个极其性能敏感的循环中频繁地创建和销毁

   shared_ptr

   ，可能需要重新评估设计，但这通常不是

   shared_ptr

   的典型使用场景。

在我看来，

shared_ptr

的这种线程安全机制是其成为C++11及以后版本中不可或缺的智能指针的关键原因之一。它极大地简化了多线程编程中资源管理的问题，让开发者可以更专注于业务逻辑，而不是疲于应对复杂的锁机制和竞态条件。 如何自己动手实现一个简化的

shared_ptr

？需要注意哪些关键点？

自己动手实现一个简化的

shared_ptr

是理解其内部机制的绝佳实践。这会让你深刻体会到标准库实现的精妙与复杂。下面我将给出一个简化的实现框架，并强调一些关键点。

首先，我们需要一个独立的控制块（

ControlBlock

）类来存储引用计数和可能的删除器。

#include <atomic> // 用于线程安全的引用计数
#include <iostream>
#include <functional> // 用于自定义删除器

// 简化的ControlBlock
class ControlBlockBase {
public:
    std::atomic_long shared_count; // 强引用计数
    std::atomic_long weak_count;   // 弱引用计数

    ControlBlockBase() : shared_count(1), weak_count(0) {}
    virtual ~ControlBlockBase() = default;

    // 纯虚函数，用于销毁被管理对象
    virtual void destroy_object() = 0;
};

template<typename T, typename Deleter = std::default_delete<T>>
class ControlBlock : public ControlBlockBase {
public:
    T* ptr;
    Deleter deleter;

    ControlBlock(T* p, Deleter d = Deleter()) : ptr(p), deleter(d) {}

    void destroy_object() override {
        if (ptr) {
            deleter(ptr); // 使用自定义删除器或默认删除器
            ptr = nullptr; // 避免二次删除
        }
    }
};

接下来是

MySharedPtr

类：

template<typename T>
class MySharedPtr {
private:
    T* data_ptr;
    ControlBlockBase* control_block;

    void release() {
        if (control_block) {
            // 原子递减强引用计数
            if (control_block->shared_count.fetch_sub(1) == 1) {
                // 如果强引用计数归零，销毁对象
                control_block->destroy_object();
                // 如果弱引用计数也归零，销毁控制块
                if (control_block->weak_count.load() == 0) {
                    delete control_block;
                    control_block = nullptr;
                }
            }
        }
    }

public:
    // 默认构造函数
    MySharedPtr() : data_ptr(nullptr), control_block(nullptr) {}

    // 裸指针构造函数
    template<typename U>
    explicit MySharedPtr(U* p) : data_ptr(p) {
        if (p) {
            control_block = new ControlBlock<U>(p);
        } else {
            control_block = nullptr;
        }
    }

    // 带自定义删除器的裸指针构造函数
    template<typename U, typename Deleter>
    MySharedPtr(U* p, Deleter d) : data_ptr(p) {
        if (p) {
            control_block = new ControlBlock<U, Deleter>(p, d);
        } else {
            control_block = nullptr;
        }
    }

    // 拷贝构造函数
    MySharedPtr(const MySharedPtr& other) noexcept
        : data_ptr(other.data_ptr), control_block(other.control_block) {
        if (control_block) {
            control_block->shared_count.fetch_add(1); // 原子递增强引用计数
        }
    }

    // 移动构造函数
    MySharedPtr(MySharedPtr&& other) noexcept
        : data_ptr(other.data_ptr), control_block(other.control_block) {
        other.data_ptr = nullptr;
        other.control_block = nullptr;
    }

    // 拷贝赋值运算符
    MySharedPtr& operator=(const MySharedPtr& other) noexcept {
        if (this != &other) { // 处理自赋值
            release(); // 释放当前资源
            data_ptr = other.data_ptr;
            control_block = other.control_block;
            if (control_block) {
                control_block->shared_count.fetch_add(1); // 原子递增强引用计数
            }
        }
        return *this;
    }

    // 移动赋值运算符
    MySharedPtr& operator=(MySharedPtr&& other) noexcept {
        if (this != &other) { // 处理自赋值
            release(); // 释放当前资源
            data_ptr = other.data_ptr;
            control_block = other.control_block;
            other.data_ptr = nullptr;
            other.control_block = nullptr;
        }
        return *this;
    }

    // 析构函数
    ~MySharedPtr() {
        release();
    }

    // 解引用运算符
    T& operator*() const noexcept {
        return *data_ptr;
    }

    // 箭头运算符
    T* operator->() const noexcept {
        return data_ptr;
    }

    // 获取裸指针
    T* get() const noexcept {
        return data_ptr;
    }

    // 获取引用计数
    long use_count() const noexcept {
        return control_block ? control_block->shared_count.load() : 0;
    }

    // 检查是否拥有对象
    explicit operator bool() const noexcept {
        return data_ptr != nullptr;
    }
};

// 辅助函数：make_shared (简化版，不处理完美转发和内存优化)
template<typename T, typename... Args>
MySharedPtr<T> make_my_shared(Args&&... args) {
    // 实际的make_shared会一次性分配对象和控制块的内存，这里简化处理
    return MySharedPtr<T>(new T(std::forward<Args>(args)...));
}

需要注意的关键点：

1. 原子操作：所有对

   shared_count

   和

   weak_count

   的增减操作都必须使用

   std::atomic

   ，这是保证多线程安全的核心。否则，在并发环境下会出现严重的竞态条件和数据损坏。
2. 控制块的生命周期：控制块的销毁时机是关键。它只有在强引用计数和弱引用计数都归零时才能被销毁。

   ControlBlockBase

   在这里作为基类，确保无论

   T

   和

   Deleter

   是什么，我们都能通过多态调用

   destroy_object()

   。
3. 自赋值检查：在拷贝赋值运算符和移动赋值运算符中，

   if (this != &other)

   是必不可少的，用于防止对象自赋值导致的问题（例如，先释放自己的资源，然后从自己那里复制，结果资源已经没了）。
4. 异常安全：上述简化实现并未完全考虑异常安全。一个健壮的

   shared_ptr

   在构造新对象或控制块失败时，需要确保不会泄露资源。标准库的

   std::make_shared

   就是为了提供更好的异常安全和性能而设计的，它能一次性分配对象和控制块的内存。
5. 自定义删除器：通过模板参数

   Deleter

   和

   std::function

   ，我们可以支持各种自定义的资源释放逻辑，这极大地扩展了

   shared_ptr

   的应用范围。

6. weak_ptr

   的缺失：这个简化版本没有实现

   MyWeakPtr

   。如果实现

   MyWeakPtr

   ，它将持有

   ControlBlockBase*

   指针，并在构造时增加

   weak_count

   ，析构时减少

   weak_count

   。

   MyWeakPtr::lock()

   方法会检查

   shared_count

   是否大于0，如果是，则原子性地增加

   shared_count

   并返回一个

   MySharedPtr

   。
7. 类型擦除：

   ControlBlockBase

   和模板化的

   ControlBlock

   是实现类型擦除的一种方式，使得

   MySharedPtr

   可以管理任意类型的对象，而不需要在

   MySharedPtr

   类中直接知道

   T

   的具体类型来调用删除器。

通过这个练习，你会发现标准库的

std::shared_ptr

远比我们想象的要复杂和精巧，它在性能、线程安全、异常安全和灵活性之间做到了极佳的平衡。

shared_ptr

与

unique_ptr

、

weak_ptr

之间的关系与选择考量是什么？

在C++智能指针家族中，

shared_ptr

、

unique_ptr

和

weak_ptr

各自扮演着独特的角色，它们共同构成了C++资源管理的核心工具。理解它们之间的关系和各自的适用场景，是写出高效、安全且易于维护的C++代码的关键。

1.

unique_ptr

：独占所有权

• 关系：

  unique_ptr

  代表着独占所有权。一个资源在任何时刻只能被一个

  unique_ptr

  管理。当

  unique_ptr

  被销毁时，它所管理的资源也会被销毁。它不支持拷贝，但支持移动语义，这意味着所有权可以从一个

  unique_ptr

  转移到另一个

  unique_ptr

  。
• 选择考量：
  • 明确的单一所有者：当你确定一个资源只有一个所有者，并且这个所有者的生命周期就是资源的生命周期时，

    unique_ptr

    是首选。例如，函数内部创建的对象，或者类成员变量，其生命周期与包含它的函数或类实例绑定。
  • 性能优先：

    unique_ptr

    没有引用计数，因此其开销非常小，几乎与裸指针相当，只在析构时有一次函数调用（删除器）。如果你不需要共享所有权，

    unique_ptr

    是性能最优的选择。
  • 自定义删除器：

    unique_ptr

    也支持自定义删除器，但与

    shared_ptr

    不同，删除器的类型是

    unique_ptr

    类型的一部分，这使得它在编译时就能确定

以上就是C++如何实现shared_ptr引用计数机制的详细内容，更多请关注知识资源分享宝库其它相关文章！

相关标签： 处理器 工具 栈 c++ ios 作用域 标准库 red Object 运算符 赋值运算符 if 多态 成员变量 构造函数 析构函数 int 循环 指针 数据结构 栈 堆 线程 多线程 空指针 delete 并发 function 对象 作用域 事件 this 数据库 性能优化 大家都在看： C++STL容器erase-remove惯用法解析 C++如何理解内存模型中的同步与异步操作 C++责任链模式与多级处理器结合 C++11如何使用范围for循环遍历容器 C++如何使用STL容器实现图形数据结构