C++如何使用std::atomic与自定义类型结合-C++-PHP中文网

std::atomic与自定义类型结合需满足平凡可复制且大小适中，否则会退化为有锁实现；应检查is_lock_free()确认无锁性能，若不满足则推荐使用std::mutex或std::atomic<std::shared_ptr<T>>等替代方案。

c++如何使用std::atomic与自定义类型结合

std::atomic

登录后复制

确实可以与自定义类型结合使用，但它并非万能药，且有严格的先决条件。核心在于，你的自定义类型必须满足“平凡可复制”（Trivially Copyable）的特性，并且通常大小要适中，以便底层硬件能以原子方式操作一整块内存。如果条件不满足，

std::atomic

登录后复制

很可能会退化为基于互斥锁的实现，或者干脆无法编译，此时采用传统的

std::mutex

登录后复制

或更高级的指针原子操作模式会是更稳妥、更清晰的选择。

解决方案

将

std::atomic

登录后复制

与自定义类型结合，本质上是让编译器和底层硬件能够把你的自定义类型视为一个单一的、不可分割的内存单元进行读写、比较交换等操作。这听起来很美好，但现实是，只有当你的自定义类型足够“简单”时，这种结合才真正有效且高效。

简单来说，如果你的自定义类型是一个“平凡可复制”的结构体（或类），且没有用户定义的构造函数、析构函数、拷贝/移动构造函数或赋值运算符，并且它的所有非静态数据成员也都是平凡可复制的，那么你就有机会直接使用

std::atomic<YourCustomType>

登录后复制

。例如：

#include <atomic>
#include <iostream>
#include <string> // 注意：std::string不是平凡可复制的

// 示例1：一个平凡可复制的自定义类型
struct Point {
    int x;
    int y;

    // 默认构造函数、拷贝构造函数、赋值运算符、析构函数都由编译器生成，且是平凡的
    bool operator==(const Point& other) const {
        return x == other.x && y == other.y;
    }
};

// 示例2：一个非平凡可复制的自定义类型 (因为它有std::string成员)
struct UserData {
    int id;
    std::string name; // std::string不是平凡可复制的

    // 如果这里手动定义了任何构造函数、析构函数、拷贝/移动操作，也会使其非平凡
    // UserData() = default;
    // ~UserData() = default;
};

int main() {
    // 对于Point，可以直接使用std::atomic
    std::atomic<Point> current_point;
    Point initial_point = {10, 20};
    current_point.store(initial_point);

    Point new_point = {30, 40};
    Point expected_point = initial_point;

    // 原子地比较并交换整个Point对象
    if (current_point.compare_exchange_strong(expected_point, new_point)) {
        std::cout << "Successfully updated point to {" << current_point.load().x << ", " << current_point.load().y << "}\n";
    } else {
        std::cout << "Failed to update point, current value is {" << current_point.load().x << ", " << current_point.load().y << "}\n";
    }

    // 检查是否是无锁的，这很重要
    if (current_point.is_lock_free()) {
        std::cout << "std::atomic<Point> is lock-free.\n";
    } else {
        std::cout << "std::atomic<Point> is NOT lock-free (likely uses a mutex internally).\n";
    }

    // 对于UserData，直接使用std::atomic<UserData>通常是不可行的，或者会退化为有锁
    // std::atomic<UserData> current_user_data; // 可能会编译失败或不是lock-free
    // 我个人建议，对于UserData这种类型，直接使用互斥锁或者std::atomic<std::shared_ptr<UserData>>是更好的选择。

    return 0;
}

登录后复制

代码中

current_point.is_lock_free()

登录后复制

的检查至关重要。如果它返回

false

登录后复制

，意味着

std::atomic

登录后复制

在内部使用了互斥锁来模拟原子操作，这不仅失去了无锁编程的性能优势，还可能引入不必要的复杂性。在这种情况下，我们不如直接使用

std::mutex

登录后复制

，代码意图会更清晰。

立即学习“C++免费学习笔记（深入）”；

std::atomic

登录后复制

与自定义类型结合的先决条件是什么？

要让

std::atomic

登录后复制

与自定义类型高效且正确地工作，你的类型必须满足一系列严格的条件，否则其性能优势会大打折扣，甚至可能导致程序行为异常。

首先，也是最关键的，你的自定义类型必须是平凡可复制（Trivially Copyable）的。这意味着：

它没有用户定义的拷贝构造函数。
它没有用户定义的移动构造函数。
它没有用户定义的拷贝赋值运算符。
它没有用户定义的移动赋值运算符。
它没有用户定义的析构函数。
它的所有非静态数据成员（以及它们的基类）都必须是平凡可复制的。

说白了，就是你的类型必须足够“原始”，编译器可以像处理

int

登录后复制

或

char

登录后复制

数组一样，简单粗暴地通过

memcpy

登录后复制

等底层内存操作来复制或移动它。如果你的类型包含了像

std::string

登录后复制

、

std::vector

登录后复制

、

std::unique_ptr

登录后复制

、

std::shared_ptr

登录后复制

这类管理资源的成员，或者你自己定义了任何一个特殊的成员函数，那么它就不是平凡可复制的，

std::atomic

登录后复制

将无法对其进行有效的无锁操作。

其次，类型的大小也是一个重要考量。底层硬件通常只能原子地操作特定大小的数据块，比如一个机器字（通常是4字节或8字节）。如果你的自定义类型大小恰好是这些硬件支持的原子操作尺寸（例如8字节、16字节），那么它更有可能实现无锁。如果类型过大，即使是平凡可复制的，

std::atomic

登录后复制

也可能无法利用硬件支持，从而退化为基于互斥锁的实现。

自由画布

百度文库和百度网盘联合开发的AI创作工具类智能体

查看详情

最后，也是最直接的验证方式，就是始终检查

std::atomic<T>::is_lock_free()

登录后复制

。这是判断你的自定义类型是否真的能通过

std::atomic

登录后复制

实现无锁的关键。如果这个函数返回

false

登录后复制

，那么就意味着

std::atomic

登录后复制

内部会使用一个互斥锁来保护对该类型实例的访问。在这种情况下，你并没有获得无锁编程的性能优势，反而可能承担了额外的开销和复杂性，此时直接使用

std::mutex

登录后复制

会是更明智、更清晰的选择。我个人觉得，如果

is_lock_free()

登录后复制

是

false

登录后复制

，那基本就没必要用

std::atomic

登录后复制

了。

当自定义类型不满足

std::atomic

登录后复制

要求时，有哪些替代方案？

当你的自定义类型不满足

std::atomic

登录后复制

的严格要求（例如，它包含了

std::string

登录后复制

，或者有复杂的生命周期管理），强行使用

std::atomic

登录后复制

要么会编译失败，要么会默默地退化为有锁操作，这都不是我们想要的。幸运的是，C++提供了多种成熟且高效的替代方案来处理并发访问。

使用

std::mutex

登录后复制

和常规类型： 这是最直接、最通用、也是最安全的方案。你可以将你的复杂自定义类型封装在一个类中，并使用

std::mutex

登录后复制

来保护对该类型实例的所有并发访问。

std::lock_guard

登录后复制

和

std::unique_lock

登录后复制

是管理互斥锁的推荐方式。这种方法虽然引入了锁的开销，但它的逻辑清晰，易于理解和调试，并且适用于任何复杂度的类型。

#include <mutex>
#include <string>
#include <iostream>

struct ComplexData {
    int id;
    std::string name;
    // 构造函数、析构函数、拷贝/移动操作等...
    ComplexData(int i, const std::string& n) : id(i), name(n) {}
};

class ThreadSafeComplexData {
public:
    // 默认构造函数
    ThreadSafeComplexData() : data_(0, "Default") {}

    // 带参数构造函数
    ThreadSafeComplexData(int id, const std::string& name) : data_(id, name) {}

    void update(int new_id, const std::string& new_name) {
        std::lock_guard<std::mutex> lock(mtx_);
        data_.id = new_id;
        data_.name = new_name;
    }

    ComplexData get() const {
        std::lock_guard<std::mutex> lock(mtx_);
        return data_; // 返回一份拷贝
    }

private:
    mutable std::mutex mtx_; // mutable 允许在 const 成员函数中锁定
    ComplexData data_;
};

// 使用示例
// ThreadSafeComplexData my_data(1, "Initial");
// my_data.update(2, "Updated Name");
// ComplexData current = my_data.get();
// std::cout << current.id << " " << current.name << std::endl;

登录后复制

对于大多数应用场景，这种“粗粒度”的锁足以满足需求，并且比尝试使用复杂的无锁技巧更不容易出错。

使用

std::atomic<std::shared_ptr<T>>

登录后复制

：这种模式对于频繁读取、不频繁写入的复杂数据结构非常有效。其核心思想是，你的自定义类型

登录后复制

是不可变的（immutable），每次修改时，都创建一个新的

登录后复制

实例，然后原子地更新指向当前实例的

std::shared_ptr

登录后复制

。

#include <atomic>
#include <memory> // For std::shared_ptr
#include <string>
#include <iostream>

struct ImmutableComplexData {
    int id;
    std::string name;
    // 构造函数，一旦创建，数据就不再修改
    ImmutableComplexData(int i, const std::string& n) : id(i), name(n) {}

    // 禁止修改操作
    // void update_id(int new_id) { id = new_id; } // 不允许
};

std::atomic<std::shared_ptr<ImmutableComplexData>> current_immutable_data;

void writer_thread() {
    // 首次初始化
    current_immutable_data.store(std::make_shared<ImmutableComplexData>(1, "Initial"));

    // 更新数据：创建新实例，然后原子交换指针
    auto new_data = std::make_shared<ImmutableComplexData>(2, "Updated Name");
    current_immutable_data.store(new_data); // 原子地更新指针
}

void reader_thread() {
    // 原子地加载指针，然后安全地访问数据
    std::shared_ptr<ImmutableComplexData> data_snapshot = current_immutable_data.load();
    if (data_snapshot) {
        std::cout << "Reader: ID=" << data_snapshot->id << ", Name=" << data_snapshot->name << std::endl;
    }
}

// main函数中可以启动这两个线程

登录后复制

这种模式的优点是读取操作几乎是无锁的（只需要原子加载指针），非常高效。缺点是每次写入都需要创建新的对象，可能会有内存分配和垃圾回收的开销，并且需要确保你的自定义类型确实是不可变的。

使用专门的并发数据结构： 对于某些特定场景（如队列、哈希表），如果标准库的
```
std::atomic
```
登录后复制
无法满足，可以考虑使用像
```
boost::lockfree
```
登录后复制
库或者
```
folly
```
登录后复制
库中提供的专门的无锁数据结构。这些库通常提供了高度优化的、经过严格测试的无锁算法，但它们通常只适用于特定的数据结构类型。自己实现无锁数据结构非常复杂且容易出错，不建议在没有深厚专业知识的情况下尝试。

选择哪种方案取决于你的具体需求：数据结构的复杂性、读写频率、性能要求以及你对并发编程的熟悉程度。对于大多数情况，

std::mutex

登录后复制

是起点，只有在性能分析证明互斥锁成为瓶颈时，才应考虑更复杂的无锁方案。

使用

std::atomic

登录后复制

自定义类型时常见的陷阱与性能考量？

即便你的自定义类型满足了

std::atomic

登录后复制

的先决条件，并在

is_lock_free()

登录后复制

检查中获得了肯定，使用它依然不是没有风险的。这里面有一些常见的陷阱和性能考量，需要我们深思熟虑。

假共享（False Sharing）： 这是一个隐蔽的性能杀手。即使你的
```
std::atomic<T>
```
登录后复制
操作本身是无锁的，如果它恰好与另一个线程频繁访问的、不相关的变量（无论是另一个
```
std::atomic
```
登录后复制
还是普通变量）位于同一个CPU缓存行（cache line）中，就会发生假共享。当一个CPU核心修改了缓存行中的某个数据，整个缓存行都会被标记为脏（dirty），并需要同步到其他核心。这导致了不必要的缓存失效和总线流量，严重拖慢性能。 解决方法： 使用
```
alignas
```
登录后复制
关键字或手动填充（padding）来确保
```
std::atomic
```
登录后复制
变量独占一个缓存行，使其与其他可能被并发访问的数据隔离。例如：
```
alignas(64) std::atomic<Point> current_point;
```
登录后复制
```
is_lock_free()
```
登录后复制
的误解与性能反噬： 我前面提过，
```
is_lock_free()
```
登录后复制
是关键。但有些人可能误以为只要能编译通过，
```
std::atomic
```
登录后复制
就一定能提供无锁性能。如果
```
is_lock_free()
```
登录后复制
返回
```
false
```
登录后复制
，意味着
```
std::atomic
```
登录后复制
内部会使用一个互斥锁（通常是
```
std::mutex
```
登录后复制
或类似的操作系统原语）来模拟原子操作。在这种情况下，你不仅没有获得无锁的性能优势，反而可能因为
```
std::atomic
```
登录后复制
的封装而导致额外的开销，甚至比直接使用
```
std::mutex
```
登录后复制
更慢。更糟糕的是，你还在尝试用无锁的思维去设计代码，增加了复杂性，却没得到任何好处。
复杂操作的非原子性：
```
std::atomic<T>
```
登录后复制
保证的是对整个
```
T
```
登录后复制