内存对齐与伪共享

100 天认知提升计划 | Day 15

---

核心概念

CPU Cache 层次结构

现代 CPU 有多级缓存，理解它们是优化性能的基础：

缓存级别	大小	延迟	位置
L1 Cache	32-64 KB	~1 ns	核心 内
L2 Cache	256-512 KB	~4 ns	核心内/共享
L3 Cache	8-64 MB	~12 ns	所有核心共享
主内存	GB 级别	~100 ns	独立

关键洞察：CPU 访问主内存比访问 L1 Cache 慢 100 倍！

Cache Line（缓存行）

Cache Line 是 CPU 缓存的最小单位，通常为 64 字节。

这意味着：

• 即使只读取 1 字节，CPU 也会加载整个 64 字节的缓存行
• 相邻的数据会被一起加载到缓存中
• 内存对齐可以最大化利用缓存行

# 查看 CPU 缓存信息（macOS）
sysctl -a | grep cache

# Linux
lscpu | grep cache
cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size

内存对齐（Memory Alignment）

内存对齐是指数据在内存中的起始地址是其大小的整数倍。

// Go 示例：结构体内存布局
type BadStruct struct {
    A bool     // 1 byte
    B int64    // 8 bytes（需要 7 bytes padding）
    C bool     // 1 byte
}
// 内存占用：1 + 7(padding) + 8 + 1 + 7(padding) = 24 bytes

type GoodStruct struct {
    B int64    // 8 bytes
    A bool     // 1 byte
    C bool     // 1 byte + 6 bytes padding
}
// 内存占用：8 + 1 + 1 + 6(padding) = 16 bytes

对齐规则：

• bool / byte：1 字节对齐
• int16 / uint16：2 字节对齐
• int32 / float32：4 字节对齐
• int64 / float64：8 字节对齐
• 结构体：按最大字段对齐

为什么对齐很重要？

1. 性能：对齐的访问是原子的，未对齐的访问可能需要多次内存操作
2. 原子性：某些 CPU 架构不支持未对齐的原子操作
3. 缓存效率：对齐的数据更容易命中缓存行

// 查看结构体大小和对齐
package main

import (
    "fmt"
    "unsafe"
)

type Bad struct {
    a bool
    b int64
    c bool
}

type Good struct {
    b int64
    a bool
    c bool
}

func main() {
    fmt.Printf("Bad: size=%d, align=%d\n", unsafe.Sizeof(Bad{}), unsafe.Alignof(Bad{}))
    fmt.Printf("Good: size=%d, align=%d\n", unsafe.Sizeof(Good{}), unsafe.Alignof(Good{}))
}
// 输出：
// Bad: size=24, align=8
// Good: size=16, align=8

---

False Sharing（伪共享）

什么是 False Sharing？

False Sharing 发生在多个 CPU 核心修改同一缓存行中不同变量时：

1. 核心 A 修改变量 X
2. 核心 B 修改变量 Y
3. X 和 Y 在同一缓存行（64 字节内）
4. 两个核心的修改导致缓存行频繁失效和同步

结果：看似并行的操作，实际上串行化了！

伪共享示例

// ❌ 伪共享问题
type Counter struct {
    value int64
}

func countBad(counters []Counter) {
    var wg sync.WaitGroup
    for i := 0; i < len(counters); i++ {
        wg.Add(1)
        go func(idx int) {
            defer wg.Done()
            for j := 0; j < 10000000; j++ {
                counters[idx].value++
            }
        }(i)
    }
    wg.Wait()
}
// counters[0], counters[1], counters[2]... 可能在同一缓存行
// 导致严重的伪共享问题

解决方案：Padding

// ✅ 使用 Padding 避免伪共享
type Counter struct {
    value int64
    _     [56]byte // padding: 64 - 8 = 56 bytes
}

// 或者使用 Go 1.19+ 的 atomic.Int64（自动对齐到缓存行）
type CounterAtomic struct {
    value atomic.Int64
}

Padding 原理：确保每个 Counter 占据完整的 64 字节缓存行，避免多个 Counter 共享同一行。

性能对比

package main

import (
    "fmt"
    "sync"
    "time"
)

const iterations = 100_000_000
const numThreads = 4

// 无 Padding
type NoPad struct {
    value int64
}

// 有 Padding
type WithPad struct {
    value int64
    _     [56]byte
}

func testNoPad() time.Duration {
    counters := make([]NoPad, numThreads)
    var wg sync.WaitGroup
    start := time.Now()
    
    for i := 0; i < numThreads; i++ {
        wg.Add(1)
        go func(idx int) {
            defer wg.Done()
            for j := 0; j < iterations/numThreads; j++ {
                counters[idx].value++
            }
        }(i)
    }
    wg.Wait()
    return time.Since(start)
}

func testWithPad() time.Duration {
    counters := make([]WithPad, numThreads)
    var wg sync.WaitGroup
    start := time.Now()
    
    for i := 0; i < numThreads; i++ {
        wg.Add(1)
        go func(idx int) {
            defer wg.Done()
            for j := 0; j < iterations/numThreads; j++ {
                counters[idx].value++
            }
        }(i)
    }
    wg.Wait()
    return time.Since(start)
}

func main() {
    fmt.Printf("NoPad:  %v\n", testNoPad())
    fmt.Printf("WithPad: %v\n", testWithPad())
}
// 典型输出：
// NoPad:   150ms
// WithPad: 40ms
// 性能提升 ~3-4 倍！

---

实践技巧

1. 使用 unsafe 检查结构体布局

package main

import (
    "fmt"
    "unsafe"
)

func inspectStruct(s interface{}) {
    typ := unsafe.TypeOf(s).Elem()
    fmt.Printf("Struct: %s\n", typ.Name())
    fmt.Printf("Size: %d bytes\n", typ.Size())
    fmt.Printf("Alignment: %d bytes\n", typ.Align())
    
    for i := 0; i < typ.NumField(); i++ {
        f := typ.Field(i)
        fmt.Printf("  %s: offset=%d, size=%d\n", 
            f.Name, f.Offset, f.Type.Size())
    }
}

2. 使用 Go 的 fieldalignment 工具

# 安装
go install golang.org/x/tools/go/analysis/passes/fieldalignment/cmd/fieldalignment@latest

# 检查
fieldalignment ./...

# 自动修复
fieldalignment -fix ./...

3. 高性能场景的通用规则

1. 大字段在前，小字段在后：减少 padding 浪费
2. 相关字段放在一起：提高缓存局部性
3. 热路径数据单独缓存行：避免伪共享
4. 使用 atomic 类型：自动处理对齐

4. Go sync.Pool 的缓存行对齐

// Go 标准库的做法
type poolLocal struct {
    poolLocalInternal
    // 防止伪共享
    pad [128 - unsafe.Sizeof(poolLocalInternal{})%128]byte
}

---

检测工具

1. CPU 性能计数器

# Linux perf
perf stat -e cache-references,cache-misses,L1-dcache-loads,L1-dcache-load-misses ./program

# 查看缓存未命中率
perf stat -e cycles,instructions,cache-misses ./program

2. Go Benchmark

func BenchmarkCounter(b *testing.B) {
    counters := make([]WithPad, 4)
    b.RunParallel(func(pb *testing.PB) {
        i := 0
        for pb.Next() {
            counters[i%4].value++
            i++
        }
    })
}

go test -bench=. -benchmem -cpu=4

3. pprof CPU 分析

go test -cpuprofile=cpu.prof -bench=.
go tool pprof -http=:8080 cpu.prof

---

关键收获

1. Cache Line 是关键：CPU 缓存操作的最小单位是 64 字节
2. 对齐影响性能：不合理的结构体布局可能导致 50% 内存浪费
3. 伪共享是隐形杀手：多核并发时可能导致 3-10 倍性能下降
4. Padding 是解决方案：添加 padding 确保数据独占缓存行
5. 工具辅助优化：使用 fieldalignment 和 perf 检测问题

---

实践任务

• [ ] 使用 unsafe.Sizeof 检查你常用结构体的内存布局
• [ ] 使用 fieldalignment 工具优化项目中的结构体
• [ ] 编写 benchmark 对比优化前后的性能
• [ ] 阅读 Go sync.Pool 源码中的缓存行对齐实践

---

参考资料

• What Every Programmer Should Know About Memory - Ulrich Drepper
• False Sharing - Wikipedia
• Go Memory Model - Go 官方文档
• sync.Pool 源码 - Go 标准库

---

学习日期：2026-03-10