Go 32 位平台 atomic.Uint64 为什么要求特殊对齐

在 32 位 ARM、386 和 32 位 MIPS 上，64 位原子访问的关键不是“uint64 一定不能用”，而是访问地址必须满足 64 位对齐。使用旧式 atomic.LoadUint64、atomic.StoreUint64 等函数时，对齐责任在调用者；使用 Go 1.19 引入的 atomic.Uint64 时，官方类型会自动处理对齐。需要兼容 32 位目标时，新代码优先选择 atomic.Uint64，旧代码则要检查字段布局和分配位置。

一句话判断：普通 uint64 加原子函数要先证明地址对齐，atomic.Uint64 把这项类型级责任收进了 API；两者都不能在第一次使用后复制。

为什么 32 位平台会关心 64 位对齐

32 位平台的机器字宽较小，处理一个 64 位值往往需要更严格的地址条件。若把普通 uint64 放在结构体中间，再把它的地址交给旧式原子函数，代码能否安全工作就取决于最终布局，而不是只取决于变量的 Go 类型。

官方文档把责任分成两层：在 ARM、386 和 32 位 MIPS 上，使用原始 64 位原子函数时，调用者负责安排 64 位对齐；而 atomic.Int64、atomic.Uint64 会自动对齐。文档还指出，已分配结构体、数组或切片的第一个字、全局变量和局部变量，在 32 位架构上可以依赖其 64 位对齐条件。

新类型和旧式原子函数怎么选

三种写法的边界很清楚：新代码用类型化的 atomic.Uint64；维护旧接口时可以继续用 uint64 与原始函数，但必须把布局当作 API 前置条件；如果计数更新还伴随多个字段的一致性约束，单个原子值并不能代替 sync.Mutex。

类型化写法也更容易让代码审查者发现“这是一个不可复制的同步对象”。例如下面的计数器把并发更新入口集中在 Add 上；注释说明了零值和复制约束，但没有把示例当作本机运行结果。

package counter

import "sync/atomic"

type Requests struct {
	// Uint64 的零值可直接使用，且类型自身负责 32 位平台的对齐。
	total atomic.Uint64
}

func (r *Requests) Inc() uint64 {
	// Add 返回递增后的值，避免先 Load 再 Store 的竞态窗口。
	return r.total.Add(1)
}

func (r *Requests) Current() uint64 {
	// 只读取原子计数；Requests 第一次使用后不能再复制。
	return r.total.Load()
}

结构体里怎样避免把对齐问题带进旧代码

如果必须维护 uint64 加原始函数的写法，先看它存在哪里。放在已分配结构体、数组或切片的第一个字、全局变量或局部变量时，官方文档给出了可依赖的对齐条件；把它放到结构体中间、与小字段交错，或者让外部代码自行拼接地址时，就不能只凭经验判断。

更稳妥的迁移顺序是：先把独立计数器改成 atomic.Uint64，再检查该对象是否会被值复制；如果多个字段必须同时变更，则把它们放入互斥锁保护的临界区，而不是为了“全都原子化”继续增加散落的对齐假设。

package counter

import "sync/atomic"

// LegacyCounter 仅展示旧式 API 的布局风险，不建议新增代码照搬。
type LegacyCounter struct {
	// 这个字段若不是可靠的对齐起点，旧式原子函数的前置条件就需要单独证明。
	padding byte
	value   uint64
}

func (c *LegacyCounter) Load() uint64 {
	// 旧式函数接收地址；调用者必须负责确认 value 的 64 位对齐。
	return atomic.LoadUint64(&c.value)
}

这个示例的重点是责任归属，不是声称某个具体编译器布局必然失败。实际迁移应以目标架构构建、结构体设计和现有 API 约束共同决定；不应把一次在本机通过的测试当成所有 32 位平台都满足对齐。

兼容 32 位目标的速查清单

1. 新建单值原子计数器时，优先使用 atomic.Uint64，并保持指针接收者调用。
2. 使用旧式 LoadUint64 或 StoreUint64 时，明确记录地址来源和 64 位对齐依据。
3. 不要在第一次原子操作后复制包含 atomic.Uint64 的结构体，也不要把它放进会被值传递的对象模型。
4. 为 32 位目标单独执行构建或测试，把架构兼容性当作发布矩阵的一部分。

最后可以这样做方案选择：只有一个独立计数值时用 atomic.Uint64；必须沿用旧式地址 API 时保留布局说明；多个字段要保持一致时选择 sync.Mutex。这三条比记住“32 位一定要手工填充”更准确，因为类型化原子对象已经把一部分对齐工作封装起来了。

相关问题

atomic.Uint64 为什么不能复制？

它代表同步状态，第一次使用后复制会产生两个对象对同一逻辑状态的错误分叉，因此应使用指针传递并避免值接收者复制。

64 位平台还需要关心这个规则吗？

标题中的特殊对齐约束主要针对 32 位 ARM、386 和 32 位 MIPS 的原始 64 位原子访问。跨架构代码仍应遵守“不复制同步对象”和“按正确 API 使用”的规则。

atomic.Uint64 能替代互斥锁吗？

只能替代一个独立数值的原子读写；当多个字段需要一起检查和更新时，仍应使用互斥锁或更高层的同步设计。

资料来源：Go 官方 sync/atomic 文档。