从图中可以看出，T1 获取到的“1”是一个已经过期的快照。由于 T2 的介入，实际状态发生了改变，T1 基于旧快照做出的操作会破坏数据的一致性。

3. 分析错误代码示例

下面展示一段常见的错误代码，演示为何直接依赖 use_count() 会导致崩溃或数据损坏。

编译并运行以下代码模拟并发冲突（注：此代码仅用于演示错误，实际行为取决于调度器）：

#include <iostream>
#include <memory>
#include <thread>
#include <vector>

void risky_write(std::shared_ptr<int> ptr) {
    // 错误做法：假设 use_count() == 1 时可以安全地直接操作底层对象
    if (ptr.use_count() == 1) {
        // 极其危险的假设：这里认为只有自己在操作
        *ptr = 42; 
        std::cout << "Thread ID: " << std::this_thread::get_id() 
                  << " wrote value directly (count was 1).\n";
    } else {
        // 实际上，即使这里做拷贝，上面的判断也已经不可靠了
        auto local_copy = ptr;
        *local_copy = 100;
        std::cout << "Thread ID: " << std::this_thread::get_id() 
                  << " wrote via copy.\n";
    }
}

int main() {
    auto data = std::make_shared<int>(0);

    std::thread t1(risky_write, data);
    std::thread t2(risky_write, data);

    t1.join();
    t2.join();

    return 0;
}

在这段代码中，虽然看起来逻辑严密，但在 use_count() 返回和 if 条件判断之间，以及判断和实际写入之间， CPU 可能随时切换到另一个线程。另一个线程可能正在构造新的 shared_ptr，导致引用计数瞬间变为 2，甚至正在销毁对象。此时，线程 A 仍然认为自己是唯一的持有者，直接解引用指针 *ptr，这会导致未定义行为。

4. 掌握正确的处理方式

既然 use_count() 不可靠，在并发环境下处理共享数据时应遵循以下原则。

4.1 使用 std::atomic_shared_ptr (C++20)

如果你的编译器支持 C++20，最直接的方法是使用 std::atomic_shared_ptr。它提供了原子性的加载和存储操作，保证了引用计数修改的可见性。

使用 std::atomic_shared_ptr 替代裸指针：

#include <memory>
#include <atomic>

std::atomic_shared_ptr<MyClass> atomic_ptr;

void thread_safe_update() {
    // 原子地获取当前指针
    auto local_ptr = std::atomic_load(&atomic_ptr);

    // 执行业务逻辑...

    // 原子地更新指针
    std::atomic_store(&atomic_ptr, local_ptr);
}

这种方式确保了 shared_ptr 本身的控制块是原子操作的，避免了中间状态被其他线程观测到。

4.2 使用互斥锁保护访问

对于不支持 C++20 的环境，或者需要更复杂的逻辑控制，引入 std::mutex 是通用的解决方案。

遵循以下步骤修改代码：

1. 定义一个全局或成员变量的 std::mutex。
2. 使用 std::lock_guard 或 std::unique_lock 在访问 shared_ptr 前加锁。
3. 执行检查和操作。
4. 离开作用域时自动解锁。

代码示例如下：

#include <mutex>
#include <shared_mutex>

std::shared_ptr<int> global_data;
std::mutex data_mutex;

void safe_write() {
    // 1. 加锁
    std::lock_guard<std::mutex> lock(data_mutex);

    // 2. 在锁保护下，use_count() 是相对稳定的（因为其他线程被阻塞）
    // 但注意：即使 use_count() > 1，只要持有锁，也是安全的
    if (global_data) {
        *global_data = 100;
    }
}

4.3 放弃“唯一性”检查

在某些高性能场景下，如果无法接受锁的开销，也不具备 C++20 特性，应该重构逻辑设计，放弃“是否唯一持有者”的判断。

直接执行“写时复制”策略，而不依赖 use_count()：

void unconditionally_copy(std::shared_ptr<int> ptr) {
    // 不做任何检查，始终创建副本进行操作
    // 这保证了线程安全，因为每个线程操作独立的副本
    auto local_copy = std::make_shared<int>(*ptr);
    *local_copy = 200;

    // 将新副本原子地替换回去（如果需要）
    // ... (这里仍需原子操作或锁来替换全局指针)
}

5. 总结 use_count 的有效使用场景

为了确保程序的稳定性，请严格遵守下表列出的使用规范。

6. 验证并发下的计数器行为

为了加深理解，我们可以通过简单的代码观察 use_count() 的跳动。

运行以下代码观察输出：

#include <iostream>
#include <memory>
#include <thread>
#include <chrono>

void observer(std::shared_ptr<int> ptr) {
    for (int i = 0; i < 5; ++i) {
        std::cout << "Observer sees count: " << ptr.use_count() << "\n";
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

int main() {
    auto p = std::make_shared<int>(10);

    std::thread t(observer, p);

    // 主线程不断地制造临时副本
    for (int i = 0; i < 5; ++i) {
        auto copy = p; // 计数增加
        std::cout << "Main copied, count: " << p.use_count() << "\n";
        // copy 析构，计数减少
    } 

    t.join();
    return 0;
}

观察输出结果，你会发现 Observer 线程看到的数值会在 2 和 3 之间跳动（主线程 + Observer 线程 + 临时副本）。这证明了 use_count() 是动态变化的，任何时刻获取的值仅在那一纳秒内有效。

结论：在并发编程中，std::shared_ptr::use_count() 的返回值只能作为一个参考快照。停止依赖它进行业务逻辑分支判断，转而使用 std::atomic_shared_ptr (C++20) 或 std::mutex 来确保数据的一致性和线程安全。

评论 (0)

点击加载验证码后提交 提交评论

暂无评论，快来抢沙发吧！

找工具啦 © 2024-2026. All Rights Reserved.

关于 | 赞赏 | 开源软件声明 | 免责声明 | 隐私政策

苏ICP备2024074268号-1   苏公网安备32060202001131号