在C++并发编程场景中，std::atomic是实现原子操作的标准工具，很多开发者会尝试将自定义结构体作为std::atomic的模板参数，期望实现结构体整体操作的原子性。但std::atomic对自定义结构体存在明确的限制条件，这些限制都围绕原子性要求展开，不满足条件的自定义结构体无法保证原子操作的正确性。
std::atomic对自定义结构体的核心限制条件
1. 自定义结构体必须满足可平凡复制（TriviallyCopyable）要求
可平凡复制是std::atomic支持自定义类型的首要前提，可平凡复制类型的复制操作不会调用自定义构造函数、析构函数或赋值运算符，仅进行内存层面的字节拷贝。判断一个类型是否为可平凡复制类型，可以通过std::is_trivially_copyable类型特征校验。
以下代码演示了可平凡复制结构体的判断：
#include <atomic>
#include <type_traits>
#include <iostream>
// 满足可平凡复制的结构体
struct TrivialStruct {
int a;
double b;
};
// 不满足可平凡复制的结构体，存在自定义析构函数
struct NonTrivialStruct {
int a;
~NonTrivialStruct() {} // 自定义析构函数破坏可平凡复制特性
};
int main() {
std::cout << "TrivialStruct is trivially copyable: "
<< std::is_trivially_copyable<TrivialStruct>::value << std::endl;
std::cout << "NonTrivialStruct is trivially copyable: "
<< std::is_trivially_copyable<NonTrivialStruct>::value << std::endl;
return 0;
}
如果自定义结构体不满足可平凡复制要求，直接声明std::atomic<NonTrivialStruct>会导致编译错误，因为std::atomic的模板参数要求类型必须满足可平凡复制。
2. 自定义结构体的大小必须被硬件原子操作支持
即使自定义结构体满足可平凡复制要求，还需要其大小在硬件支持的原子操作范围内。不同CPU架构支持的原子操作最大字节数不同，比如常见的x86_64架构通常支持1、2、4、8、16字节的原子操作，如果自定义结构体的大小超过硬件支持的最大原子操作字节数，std::atomic可能无法提供真正的原子性保证。
这种情况下，std::atomic会退化为使用锁来实现原子操作，虽然功能上仍然正确，但性能会大幅下降，且部分场景下可能无法满足无锁的要求。可以通过以下代码查看自定义结构体的大小：
#include <atomic>
#include <iostream>
struct SmallStruct {
int a; // 4字节
int b; // 4字节，总共8字节，多数硬件支持8字节原子操作
};
struct LargeStruct {
int a;
double b;
char c[32]; // 总大小远大于16字节，多数硬件不支持对应大小的原子操作
};
int main() {
std::cout << "SmallStruct size: " << sizeof(SmallStruct) << std::endl;
std::cout << "LargeStruct size: " << sizeof(LargeStruct) << std::endl;
return 0;
}
3. 自定义结构体不能包含虚函数或虚基类
包含虚函数或虚基类的结构体，其内存布局中会包含虚函数表指针（vptr），这类结构体的复制操作不是纯粹的内存字节拷贝，会破坏可平凡复制特性，因此无法作为std::atomic的模板参数。以下代码的结构体包含虚函数，不满足条件：
#include <atomic>
struct VirtualStruct {
int a;
virtual void func() {} // 包含虚函数，存在vptr，不可平凡复制
};
// 以下声明会编译失败
// std::atomic<VirtualStruct> atomic_vs;
4. 自定义结构体的成员不能包含引用或不可平凡复制类型
如果自定义结构体的成员包含引用类型，或者包含其他不可平凡复制的类型，那么整个结构体也会变成不可平凡复制，无法被std::atomic支持。引用本身不是对象，无法被拷贝，因此包含引用的结构体不满足可平凡复制要求。
#include <atomic>
#include <string>
struct StructWithRef {
int a;
int& ref; // 包含引用成员，不可平凡复制
};
struct StructWithNonTrivialMember {
std::string s; // std::string不是可平凡复制类型
int a;
};
// 以下两个声明都会编译失败
// std::atomic<StructWithRef> atomic_sr;
// std::atomic<StructWithNonTrivialMember> atomic_sn;
如何判断自定义结构体是否支持std::atomic
可以通过std::atomic的静态成员常量is_always_lock_free来判断，该常量在编译期就能确定对应类型的原子操作是否是无锁的，如果为true，说明自定义结构体满足std::atomic的要求，且操作是无锁的。
#include <atomic>
#include <iostream>
struct ValidStruct {
int a;
int b;
};
int main() {
std::cout << "std::atomic<ValidStruct> is always lock free: "
<< std::atomic<ValidStruct>::is_always_lock_free << std::endl;
return 0;
}
如果is_always_lock_free为false，说明要么自定义结构体不满足要求，要么硬件不支持对应大小的无锁原子操作，此时使用std::atomic会退化为锁实现。
不满足限制时的替代方案
如果自定义结构体不满足std::atomic的限制条件，又需要实现并发访问的安全性，可以采用以下方案：
- 使用互斥锁（std::mutex）保护自定义结构体的访问，这是最通用的方案，适用于所有类型。
- 如果结构体只是简单的数据集合，可以拆分结构体成员，对每个可原子化的成员分别使用std::atomic，避免整体包装结构体。
- 如果结构体大小略超过硬件原子支持范围，可以调整结构体内存布局，减小结构体大小，或者将结构体拆分为多个小的可原子化部分。
需要注意的是，即使自定义结构体满足std::atomic的所有限制条件，也仅能保证单个std::atomic操作的原子性，多个操作的组合仍然需要额外的同步机制，无法保证整体事务的原子性。
std::atomic自定义结构体原子性C++修改时间：2026-07-04 05:48:27