Go atomic 变量未对齐在老架构上为什么出问题

我第一次遇到这个问题，是把一个统计字段放进已有配置结构体后，64 位构建和 32 位构建表现不一致。代码看起来只是把 uint64 换成了 atomic.LoadUint64，但在老架构上，原子操作除了“是不是并发安全”，还要求被访问的 64 位字必须满足对齐条件。

结论先说：在 ARM、386 和 32 位 MIPS 上，直接使用 sync/atomic 的 64 位函数时，调用方要负责保证 64 位对齐；而 atomic.Int64、atomic.Uint64 会自动处理对齐。最稳妥的结构体写法，是把需要原子访问的 64 位字段放在结构体的第一个字段，或者使用新版封装类型，并且首次使用后不要复制它。

“未对齐”不是数值错了，而是原子指令访问的地址不满足目标架构要求。字段一旦从结构体首部移到一个可能带来 4 字节偏移的位置，32 位目标就可能暴露这个问题。

先确认你调用的是哪一类 atomic

sync/atomic 同时提供低级函数和类型封装。下面这个例子使用低级函数，counter 的地址必须由调用方负责安排：

package counter

import "sync/atomic"

type Stats struct {
	padding uint32 // 这个字段可能让后面的 uint64 偏移到 4 字节边界
	counter uint64 // 低级 64 位原子函数要求调用方保证对齐
}

func (s *Stats) Add(delta uint64) uint64 {
	// 只有地址对齐满足目标架构要求时，原子加法才是可移植的
	return atomic.AddUint64(&s.counter, delta)
}

如果改成封装类型，职责会清楚一些：

package counter

import "sync/atomic"

type Stats struct {
	padding uint32       // 其他业务字段可以保留在前面
	counter atomic.Uint64 // 类型封装会自动保证 64 位值的对齐
}

func (s *Stats) Add(delta uint64) uint64 {
	// Add 返回加法完成后的新值
	return s.counter.Add(delta)
}

为什么 32 位架构更容易暴露问题

Go 官方文档把范围说得很具体：在 ARM、386 和 32 位 MIPS 上，通过原子原语访问的 64 位字需要由调用方安排 64 位对齐。结构体、数组或切片中分配对象的第一个字、全局变量，以及会逃逸到堆上的局部变量，可以依赖 64 位对齐；但结构体中间的字段不能仅凭类型大小推断出这个结论。

这也是“本机没问题、老架构出问题”的常见来源。64 位架构通常对 uint64 的布局更宽松，或者编译器已经安排了合适的地址；32 位架构则可能让前一个 32 位字段占用 4 字节，后面的原子字段落在只满足 4 字节对齐的位置。问题在地址布局，不在 AddUint64 的加法逻辑。

package counter

import "sync/atomic"

type SafeStats struct {
	counter uint64 // 放在第一个字段，使用低级函数时更容易满足首字段对齐规则
	padding uint32 // 其他字段放在需要原子访问的字段之后
}

func (s *SafeStats) Load() uint64 {
	// Load 读取同一个 64 位地址，不能把它改成普通读取
	return atomic.LoadUint64(&s.counter)
}

结构体应该怎样改，才不会把风险藏起来

我在兼容性改造中会先看字段用途，再看字段布局。只读配置不需要原子访问，不要为了“看起来更安全”把所有整数都换成 atomic；真正跨 goroutine 读写的 64 位计数器，才需要选择合适的原子类型。

对于新代码，优先考虑 atomic.Uint64 或 atomic.Int64。官方类型定义包含对齐辅助字段，而且文档明确说明这两种类型会自动对齐。它们也带有“首次使用后不得复制”的约束，所以应当用指针传递或把它们固定在不会被复制的对象里。

package counter

import "sync/atomic"

type Meter struct {
	requests atomic.Uint64 // 计数器首次使用后不要复制整个 Meter
	name     string        // 业务字段和计数器并存没有问题
}

func (m *Meter) Inc() {
	// 通过方法封装写入，避免调用方拿到内部地址后随意处理
	m.requests.Add(1)
}

func (m *Meter) Value() uint64 {
	// Load 与 Add 使用同一个原子对象，读写语义保持一致
	return m.requests.Load()
}

如果必须继续使用低级函数，例如维护旧 API 或对接已有内存布局，就把原子字段放在结构体首部，并在代码注释里写明目标架构和对齐前提。不要用 unsafe.Pointer 通过加法“修正”地址；那只是把布局责任变成更难排查的未定义风险。

发布前我会检查这四件事

1. 目标平台是否包含 GOARCH=386、32 位 ARM 或 32 位 MIPS；如果不包含，记录“当前构建不覆盖老架构”，不要把结论泛化成所有平台。
2. 字段是不是通过 atomic.LoadUint64、StoreUint64、AddUint64 或 CAS 访问；只有这类 64 位原子地址需要重点核对。
3. 低级原子字段是不是结构体首字段；如果不是，优先改为 atomic.Int64、atomic.Uint64 或重新设计结构体。
4. 包含 atomic 类型的对象有没有被值传递、赋值、追加到会复制元素的容器中；原子类型首次使用后不应复制。

这套检查的价值不在于把每个字段都“对齐到最大”，而在于把架构约束放在数据结构设计阶段。对已经存在的低级 API，首字段布局是清晰、成本低的兼容方案；对新代码，封装类型更容易把对齐和调用方式一起固定下来。

相关问题

只有 64 位系统才需要关心 atomic 对齐吗？

不应该这样判断。题目中的风险主要针对 ARM、386 和 32 位 MIPS；如果库需要支持这些目标，就必须按最严格的目标平台设计并交叉构建。

把 uint64 改成 atomic.Uint64 就一定可以复制结构体吗？

不可以。自动对齐解决的是地址布局问题，不能取消“首次使用后不要复制”的类型约束。应保持对象稳定，通过指针使用。