原子指针初始化是否具备原子性？初始化/内存分配抛异常怎么办？

云上老周

2026-5-27

你提的这些问题刚好戳中了原子指针初始化时容易踩的坑，咱们一步步拆解来看：

一、一次性声明定义原子指针的原子性问题

你的理解完全正确：std::atomic<int*> iptr = new int(1); 这类写法确实不具备全局原子性。整个过程拆成了两步：

第一步：执行new T()，包含内存分配 + T对象的构造（如果是非平凡类型的话）
第二步：把分配得到的指针原子地赋值给iptr

这两步是独立操作，中间没有任何原子性保证。

如果T的构造或者内存分配过程中抛出异常，iptr的初始化根本不会完成——它会处于默认初始化状态。根据C++标准，原子指针的默认初始化是未定义行为（不同平台可能表现为nullptr，也可能是随机的野指针）。这时候其他线程如果访问iptr，读到的就是这个不确定的值，大概率会触发不可预测的问题：比如访问野指针导致崩溃，或者误判指针为nullptr引发逻辑错误。

二、拆分声明和定义的方式是否有效？

你给出的拆分写法：

T* temp = new T(); 
std::atomic<T*> iptr = temp;

确实比一次性写法更安全，但要明确它的作用：

它能保证只有当new T()完全成功（内存分配+对象构造都完成），才会把指针赋值给iptr。其他线程在iptr被赋值前，要么看不到它（如果是局部变量），要么看到的是默认初始化的未定义状态——但至少不会读到一个指向“半构造”T对象的指针。
不过如果new T()抛出异常，temp不会被赋值，iptr也不会完成初始化，同样要警惕其他线程的非法访问。

三、其他原子化实现方式

如果想要实现从内存分配、对象构造到原子指针赋值的全流程安全，可以试试这些方法：

显式指定内存序的store操作：
和拆分写法逻辑一致，但可以通过显式内存序优化性能（默认是强顺序的std::memory_order_seq_cst，如果不需要强同步可以用更宽松的顺序）：
```
std::atomic<T*> iptr;
// ...
T* temp = new T();
iptr.store(temp, std::memory_order_release);
```
其他线程读取时用iptr.load(std::memory_order_acquire)，能保证读到的是完全构造好的T对象。
配合std::make_unique提升异常安全性：
std::make_unique比直接new更安全——如果T的构造抛出异常，它会自动释放已分配的内存，避免泄漏：
```
std::atomic<T*> iptr;
auto temp = std::make_unique<T>();
iptr.store(temp.release(), std::memory_order_release);
```
全局/静态原子指针用std::call_once保证初始化唯一性：
如果是全局或静态的原子指针，用std::call_once能确保初始化只执行一次，且只有初始化完成后其他线程才能访问：
```
std::atomic<T*> g_iptr;
std::once_flag g_init_flag;

void init_iptr() {
    g_iptr.store(new T(), std::memory_order_release);
}

// 其他线程中访问时
std::call_once(g_init_flag, init_iptr);
T* ptr = g_iptr.load(std::memory_order_acquire);
```
这种方式能彻底避免初始化阶段的竞态问题。
C++20+可用std::atomic_ref适配已有指针：
如果已经有一个普通指针，想把它变成支持原子操作的对象，可以用std::atomic_ref：
```
T* temp = new T();
std::atomic_ref<T*> iptr_ref(temp);
// 后续对iptr_ref的读写都是原子操作
```
这个更适合改造已有代码的场景。

四、你的理解有没有偏差？

整体来看你的理解非常准确，核心点都抓对了：

一次性初始化原子指针确实不是原子操作，new T()和原子赋值是两个独立步骤；
自定义类型构造抛异常会导致原子指针未正确初始化，其他线程访问风险很高；
拆分写法能提升安全性，确保只有构造完成后才会赋值原子指针。

唯一需要补充的细节是：原子指针的默认初始化是未定义行为（C++标准没有要求默认置零），所以一定要保证原子指针在被访问前已经完成初始化，避免其他线程读到不确定的值。

内容的提问来源于stack exchange，提问作者user888270