std::atomic与自定义类型结合需满足平凡可复制且大小适中，否则会退化为有锁实现；应检查is_lock_free()确认无锁性能，若不满足则推荐使用std::mutex或std::atomic等替代方案。
std::atomic
确实可以与自定义类型结合使用，但它并非万能药，且有严格的先决条件。核心在于，你的自定义类型必须满足“平凡可复制”（Trivially Copyable）的特性，并且通常大小要适中，以便底层硬件能以原子方式操作一整块内存。如果条件不满足，
std::atomic
很可能会退化为基于互斥锁的实现，或者干脆无法编译，此时采用传统的
std::mutex
或更高级的指针原子操作模式会是更稳妥、更清晰的选择。
解决方案
将
std::atomic
与自定义类型结合，本质上是让编译器和底层硬件能够把你的自定义类型视为一个单一的、不可分割的内存单元进行读写、比较交换等操作。这听起来很美好，但现实是，只有当你的自定义类型足够“简单”时，这种结合才真正有效且高效。
简单来说，如果你的自定义类型是一个“平凡可复制”的结构体（或类），且没有用户定义的构造函数、析构函数、拷贝/移动构造函数或赋值运算符，并且它的所有非静态数据成员也都是平凡可复制的，那么你就有机会直接使用
std::atomic
。例如：
#include #include #include // 注意：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 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 is lock-free.n"; } else { std::cout << "std::atomic is NOT lock-free (likely uses a mutex internally).n"; } // 对于UserData，直接使用std::atomic通常是不可行的，或者会退化为有锁 // std::atomic current_user_data; // 可能会编译失败或不是lock-free // 我个人建议，对于UserData这种类型，直接使用互斥锁或者std::atomic<std::shared_ptr>是更好的选择。 return 0;}
代码中
current_point.is_lock_free()
的检查至关重要。如果它返回
false
，意味着
std::atomic
在内部使用了互斥锁来模拟原子操作，这不仅失去了无锁编程的性能优势，还可能引入不必要的复杂性。在这种情况下，我们不如直接使用
std::mutex
，代码意图会更清晰。
立即学习“C++免费学习笔记（深入）”；
std::atomic
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
也可能无法利用硬件支持，从而退化为基于互斥锁的实现。
最后，也是最直接的验证方式，就是始终检查
std::atomic::is_lock_free()
。这是判断你的自定义类型是否真的能通过
std::atomic
实现无锁的关键。如果这个函数返回
false
，那么就意味着
std::atomic
内部会使用一个互斥锁来保护对该类型实例的访问。在这种情况下，你并没有获得无锁编程的性能优势，反而可能承担了额外的开销和复杂性，此时直接使用
std::mutex
会是更明智、更清晰的选择。我个人觉得，如果
is_lock_free()
是
false
，那基本就没必要用
std::atomic
了。
当自定义类型不满足
std::atomic
std::atomic
要求时，有哪些替代方案？
当你的自定义类型不满足
std::atomic
的严格要求（例如，它包含了
std::string
，或者有复杂的生命周期管理），强行使用
std::atomic
要么会编译失败，要么会默默地退化为有锁操作，这都不是我们想要的。幸运的是，C++提供了多种成熟且高效的替代方案来处理并发访问。
使用
std::mutex
和常规类型：这是最直接、最通用、也是最安全的方案。你可以将你的复杂自定义类型封装在一个类中，并使用
std::mutex
来保护对该类型实例的所有并发访问。
std::lock_guard
和
std::unique_lock
是管理互斥锁的推荐方式。这种方法虽然引入了锁的开销，但它的逻辑清晰，易于理解和调试，并且适用于任何复杂度的类型。
#include #include #include 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 lock(mtx_); data_.id = new_id; data_.name = new_name; } ComplexData get() const { std::lock_guard 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），每次修改时，都创建一个新的
T
实例，然后原子地更新指向当前实例的
std::shared_ptr
。
#include #include // For std::shared_ptr#include #include 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> current_immutable_data;void writer_thread() { // 首次初始化 current_immutable_data.store(std::make_shared(1, "Initial")); // 更新数据：创建新实例，然后原子交换指针 auto new_data = std::make_shared(2, "Updated Name"); current_immutable_data.store(new_data); // 原子地更新指针}void reader_thread() { // 原子地加载指针，然后安全地访问数据 std::shared_ptr data_snapshot = current_immutable_data.load(); if (data_snapshot) { std::cout << "Reader: ID=" <id << ", Name=" <name << std::endl; }}// main函数中可以启动这两个线程
这种模式的优点是读取操作几乎是无锁的（只需要原子加载指针），非常高效。缺点是每次写入都需要创建新的对象，可能会有内存分配和垃圾回收的开销，并且需要确保你的自定义类型确实是不可变的。
使用专门的并发数据结构：对于某些特定场景（如队列、哈希表），如果标准库的
std::atomic
无法满足，可以考虑使用像
boost::lockfree
库或者
folly
库中提供的专门的无锁数据结构。这些库通常提供了高度优化的、经过严格测试的无锁算法，但它们通常只适用于特定的数据结构类型。自己实现无锁数据结构非常复杂且容易出错，不建议在没有深厚专业知识的情况下尝试。
选择哪种方案取决于你的具体需求：数据结构的复杂性、读写频率、性能要求以及你对并发编程的熟悉程度。对于大多数情况，
std::mutex
是起点，只有在性能分析证明互斥锁成为瓶颈时，才应考虑更复杂的无锁方案。
使用
std::atomic
std::atomic
自定义类型时常见的陷阱与性能考量？
即便你的自定义类型满足了
std::atomic
的先决条件，并在
is_lock_free()
检查中获得了肯定，使用它依然不是没有风险的。这里面有一些常见的陷阱和性能考量，需要我们深思熟虑。
假共享（False Sharing）：这是一个隐蔽的性能杀手。即使你的
std::atomic
操作本身是无锁的，如果它恰好与另一个线程频繁访问的、不相关的变量（无论是另一个
std::atomic
还是普通变量）位于同一个CPU缓存行（cache line）中，就会发生假共享。当一个CPU核心修改了缓存行中的某个数据，整个缓存行都会被标记为脏（dirty），并需要同步到其他核心。这导致了不必要的缓存失效和总线流量，严重拖慢性能。解决方法： 使用
alignas
关键字或手动填充（padding）来确保
std::atomic
变量独占一个缓存行，使其与其他可能被并发访问的数据隔离。例如：
alignas(64) std::atomic 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
以上就是C++如何使用std::atomic与自定义类型结合的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1475216.html
微信扫一扫 
支付宝扫一扫 
