Two fields can hold independent values yet interfere with each other—or occupy more memory than their data requires. Padding is extra space between or after fields. In Go structs, it can be added deliberately to separate fields, or inserted by the compiler to satisfy alignment requirements. section 12.2 section 12.4
Separate concurrent writes
Suppose two goroutines repeatedly update different int64 fields of one Result struct. The fields may occupy the same cache line, causing false sharing even though the goroutines do not update the same field. Placing a 56-byte padding field between them keeps the two 8-byte fields out of the same 64-byte cache line in this example. A benchmark found the padded version about 40% faster on one machine; sending local results through channels achieved roughly the same result without sharing the struct. section 12.2
type Result struct {
sumA int64
_ [56]byte #1
sumB int64
}
The unnamed byte array supplies the deliberate space between the two result fields. section 12.2
Account for padding you did not add
On a 64-bit architecture, a struct ordered byte, int64, byte occupies 24 bytes although its fields contain only 10 bytes of data. The compiler inserts padding to align the int64 and complete the struct; it does not reorder fields. Ordering them int64, byte, byte reduces this example to 16 bytes. This matters when many such structs are stored in a slice: smaller elements can require fewer cache lines to scan. section 12.4
Use deliberate padding when concurrent writes suffer from false sharing. When memory footprint or traversal matters instead, inspect field order and reduce avoidable alignment padding. The two changes solve different problems: adding space can improve concurrent performance, while removing unnecessary space can make repeated values smaller. section 12.2 section 12.4
