歴史。
sync/atomicパッケージは、ハードウェア命令にコンパイルされるロックフリーのプリミティブを提供します。Goが32ビットシステム（x86-32、ARM32）に移植された際、ランタイムは非アライメントの64ビット原子アクセスをネイティブでサポートしないプロセッサに直面しました。初期のバージョンでは任意のアライメントを許可していましたが、バスエラーや静かなデータ破損を引き起こすことがありました。ポータビリティを確保するために、Goチームは、atomic関数で操作される任意の64ビット値のアドレスは32ビットアーキテクチャ上で8バイトアライメントでなければならないと義務付けました。
問題。
プログラマーが8バイトの境界に整合していないint64へのポインタを渡すと、たとえば、構造体のオフセット4にあるフィールドの場合、原子操作はこの問題をランタイムで検出します。32ビットビルドでは、ランタイムはすぐにプログラムを終了し、次のエラーを返します：unaligned 64-bit atomic operation。このハードな失敗は、原子性の保証を侵害する破損した読み取りや書き込みを防ぎます。
解決策。
Goコンパイラは自動的に構造体フィールドをその自然なサイズに合わせてアライメントしますが、開発者は依然としてフィールドを適切に配置する必要があります：int64フィールドを構造体の先頭に配置するか、他の8バイト型の後に続くようにします。あるいは、atomic.Int64（Go 1.19以降利用可能）を使用して、値をカプセル化し、型システムを介してアライメントを保証できます。グローバル変数の場合、リンカが適切なアライメントを確保します。
type Metrics struct { // sumは32ビットで8バイトのアライメントを保証するために最初に配置されます。 sum int64 count int32 } func (m *Metrics) Add(v int64) { // 32ビットおよび64ビットアーキテクチャの両方で安全です。 atomic.AddInt64(&m.sum, v) }
シナリオ。
32ビットARM Cortex-A7上で動作するIoTゲートウェイサービスがテレメトリを収集しました。初期の構造体は32ビットのDeviceIDを64ビットのEnergyCounterの前に配置しました。高スループットのゴルーチンがatomic.AddInt64(&device.EnergyCounter, delta)を呼び出しました。デプロイ直後に、サービスはruntime error: unaligned 64-bit atomic operationでクラッシュしました。なぜならEnergyCounterがオフセット4に存在していたからです。
検討された解決策。
構造体フィールドの再配置。
int64フィールドを構造体の先頭に移動することで、オフセット0のアライメントが保証されます。このアプローチは追加のメモリを消費せず、慣習的な「大きなフィールドを最初に配置する」レイアウトに従っています。欠点は、DeviceIDがソースコードの最初に出現しなくなるため、論理的なグルーピングがわずかに失われることです。
明示的なパディングを挿入。
EnergyCounterの前に4バイトのpad int32フィールドを追加することで、正しいアライメントを強制します。この方法は明示的で自己文書化されていますが、構造体ごとに4バイトが無駄になります。デバイスごとに数百万のレコードがあるため、このオーバーヘッドは組み込みフラッシュストレージにとって無視できないものになりました。
atomic.Int64を採用。
フィールドをatomic.Int64ラッパー型にリファクタリングすることで、アライメントの懸念が排除されます。なぜなら、その型自体が8バイトのアライメント要件を持つからです。しかし、これにより、すべての呼び出し地点をatomic.AddInt64(&d.EnergyCounter, v)からd.EnergyCounter.Add(v)に変更する必要があり、テストされていないコードパスにおける回帰のリスクが生じます。
選択された解決策。
チームはフィールドの再配置（解決策1）を選択しました。すべての64ビットカウンタを構造体の先頭に配置することで、メモリオーバーヘッドやAPIの変更なしにアライメントを達成しました。これはGoのことわざ「大きなフィールドを小さなフィールドの前に配置する」に従っています。彼らはCIにfieldalignmentリンターを追加し、将来の回帰を防ぎました。
結果。
パニックは全ARM32フリートで消えました。このサービスは、原子関連のクラッシュがない状態で2年間稼働し続け、構造体のレイアウトの最適化により残りのフィールドのパッキングが改善され、メモリフットプリントが8%削減されました。
なぜatomic.LoadInt64は64ビットアーキテクチャではアライメントの取れていないアドレスで成功し、32ビットではパニックを引き起こすのか？
64ビットアーキテクチャ（amd64、arm64）では、ハードウェアメモリ管理ユニットは64ビット値への非アライメントアクセスをサポートしていますが、パフォーマンスのペナルティが課されることがあります。原子命令（たとえば、x86-64上のMOVQ）は、非アライメントデータで障害を引き起こしません。対照的に、32ビットアーキテクチャでは、ペア化された32ビットレジスタや特定の64ビット原子命令（ARM32上のLDREXD/STREXDなど）を使用し、8バイトのアライメントが必要です。そうでなければ、ハードウェアのアライメントエラーが発生し、それがGoランタイムによって致命的な「unaligned 64-bit atomic operation」エラーに変換されます。
ユーザー定義の構造体内にatomic.Int64を埋め込むことで、手動でのパディングなしで32ビットシステムでのアライメントがどのように保証されるのか？
atomic.Int64型はint64を含む構造体として定義されています。Goコンパイラは、構造体に最大のフィールドのアライメント要件と同じアライメント要件を割り当てます。int64は8バイトのアライメントを必要とするため、atomic.Int64はこの要件を継承します。フィールドとして埋め込まれると、コンパイラは必要に応じて前のパディングバイトを挿入して、フィールドのオフセットが8の倍数になるようにします。さらに、ヒープ割り当てはサイズをタイプのアライメントに丸めるため、埋め込まれたフィールドへのポインタは常に8バイトアライメントされます。
なぜ[]byteを[]int64にunsafeキャスティングすることで32ビットアーキテクチャでアライメントパニックが発生するのか、スライスの長さが十分であっても？
[]byteはバイトの配列によってバックアップされています。この配列のベースアドレスは、バイトアクセスのためにアライメントされることが保証されています（1バイトのアライメント）が、8バイトアクセスのために必ずしもアライメントされるとは限りません。ポインタを*int64にキャストするためにunsafeを使用したり、[]int64として再スライスする際、最初の要素は0x1001のようなアドレスに存在しており、これは8で割り切れません。&int64Slice[0]をatomic.LoadInt64に渡すと、アライメントチェックがトリガーされます。安全な変換には、元のバイトスライスが整合のあるソースから割り当てられていることを確認する必要があります（例：make([]int64, ...)を介して作成し、書き込むために**[]byte**にキャストする）、またはアライメントされたバッファにcopyを使用します。