Justify the mandatory 8-byte alignment requirement for 64-bit atomic operations on 32-bit architectures in **Go**, and identify the specific runtime panic triggered by misalignment.

Answer to the question.

History.
The sync/atomic package provides lock-free primitives that compile to hardware instructions. When Go was ported to 32-bit systems (x86-32, ARM32), the runtime encountered processors that lack native support for unaligned 64-bit atomic access. Early versions allowed arbitrary alignment, causing bus errors or silent data corruption. To ensure portability, the Go team mandated that the address of any 64-bit value operated on by atomic functions must be 8-byte aligned on 32-bit architectures.

Problem.
If a programmer passes a pointer to an int64 that is not aligned to an 8-byte boundary—for example, a field at offset 4 inside a struct—the atomic operation detects this at runtime. On 32-bit builds, the runtime immediately terminates the program with the error: unaligned 64-bit atomic operation. This hard failure prevents torn reads or writes that would violate atomicity guarantees.

Solution.
The Go compiler automatically aligns struct fields to their natural size, but developers must still order fields correctly: place int64 fields at the start of the struct or ensure they follow other 8-byte types. Alternatively, use atomic.Int64 (available since Go 1.19), which encapsulates the value and guarantees alignment via the type system. For global variables, the linker ensures proper alignment.

type Metrics struct {
    // sum is placed first to guarantee 8-byte alignment on 32-bit.
    sum   int64
    count int32
}

func (m *Metrics) Add(v int64) {
    // Safe on both 32-bit and 64-bit architectures.
    atomic.AddInt64(&m.sum, v)
}

Situation from life

Scenario.
An IoT gateway service running on a 32-bit ARM Cortex-A7 collected telemetry. The initial struct placed a 32-bit DeviceID before a 64-bit EnergyCounter. High-throughput goroutines called atomic.AddInt64(&device.EnergyCounter, delta). Immediately upon deployment, the service crashed with runtime error: unaligned 64-bit atomic operation because EnergyCounter resided at offset 4.

Solutions considered.

1. Reorder struct fields.
   Moving the int64 fields to the top of the struct ensures offset 0 alignment. This approach consumes zero extra memory and follows the idiomatic "largest fields first" layout. The drawback is a minor loss of logical grouping, as DeviceID would no longer appear first in the source code.

2. Insert explicit padding.
   Adding a 4-byte pad int32 field before EnergyCounter forces the correct alignment. This method is explicit and self-documenting but wastes 4 bytes per struct. At millions of records per device, this overhead became non-trivial for the embedded flash storage.

3. Adopt atomic.Int64.
   Refactoring the field to the atomic.Int64 wrapper type eliminates alignment concerns because the type itself carries an 8-byte alignment requirement. However, this required refactoring every call site from atomic.AddInt64(&d.EnergyCounter, v) to d.EnergyCounter.Add(v), introducing risk of regressions in untested code paths.

Chosen solution.
The team selected reordering fields (Solution 1). By placing all 64-bit counters at the start of the struct, they achieved alignment without memory overhead or API changes. This adheres to the Go proverb: "Place larger fields before smaller ones." They added the fieldalignment linter to CI to prevent future regressions.

Result.
The panic disappeared across the entire ARM32 fleet. The service has run for two years without atomic-related crashes, and the struct layout optimization reduced memory footprint by 8% due to better packing of remaining fields.

What candidates often miss

Why does atomic.LoadInt64 succeed on unaligned addresses on 64-bit architectures but panic on 32-bit?

On 64-bit architectures (amd64, arm64), the hardware memory management unit supports unaligned access to 64-bit values, though it may incur a performance penalty. The atomic instructions (e.g., MOVQ on x86-64) do not fault on unaligned data. Conversely, 32-bit architectures use paired 32-bit registers or specific 64-bit atomic instructions (like LDREXD/STREXD on ARM32) that require 8-byte alignment; otherwise, they raise a hardware alignment fault, which the Go runtime translates into the fatal "unaligned 64-bit atomic operation" error.

How does embedding atomic.Int64 inside a user-defined struct guarantee alignment on 32-bit systems without manual padding?

The atomic.Int64 type is defined as a struct containing an int64. The Go compiler assigns an alignment requirement to a struct equal to the maximum alignment of its fields. Since int64 requires 8-byte alignment, atomic.Int64 inherits this requirement. When embedded as a field, the compiler inserts preceding padding bytes if necessary to ensure the field's offset is a multiple of 8. Additionally, heap allocations round the size up to the type's alignment, so a pointer to the embedded field is always 8-byte aligned.

Why can converting a []byte to []int64 via unsafe casting lead to alignment panics on 32-bit architectures, even if the slice length is sufficient?

A []byte is backed by an array of bytes. The base address of this array is guaranteed to be aligned for byte access (1-byte alignment), but not necessarily for 8-byte access. When using unsafe to cast the pointer to *int64 or reslicing as []int64, the first element may reside at an address like 0x1001, which is not divisible by 8. Passing &int64Slice[0] to atomic.LoadInt64 then triggers the alignment check. Safe conversion requires ensuring the original byte slice is allocated from an aligned source (e.g., via make([]int64, ...) and casting to []byte for writing), or using copy to an aligned buffer.