gc友好模型的关键是让对象布局符合内存管理器预期，需遵循平台对齐约束、合理排序字段以减少填充、聚集高频访问字段于同一缓存行，并避免使用packed/unaligned布局。
编写 GC 友好模型，关键不在于“避开 GC”，而在于让对象布局更符合内存管理器（尤其是分代式、基于指针追踪的 GC）的预期——其中基础类型在栈和堆中的对齐特性，直接影响对象大小、填充开销、缓存局部性，甚至 GC 扫描效率。理解对齐不是为了炫技，而是减少隐性浪费，让 GC 更快、更准、更省。
明确目标平台的对齐约束
不同架构和运行时对齐要求不同，GC 行为也受其影响：
- 64 位 JVM 默认栈帧和对象头按 8 字节对齐；数组元素起始地址也满足该对齐，但元素内部仍遵循类型自然对齐（如 int 仍需 4 字节边界）
- Go 运行时强制 int64、float64、struct 成员在 8 字节边界上，否则可能触发额外指令或影响逃逸分析结果
- 使用 Unsafe 或 JNI 直接操作堆内存时，若手动构造对象布局（如对象池），必须确保字段偏移严格满足 GC 标记阶段的指针扫描假设——比如 HotSpot 要求 oop 指针只出现在已知对齐偏移处
结构体/类字段排序：把大对齐需求的放前面
编译器或运行时按声明顺序布局字段，但会插入填充字节以满足对齐。不合理排序会放大填充，导致对象体积膨胀，间接增加 GC 压力：
- 错误示例：
byte flag; int id; double ts;→ 实际占用约 24 字节（flag 占 1，填充 3，id 占 4，ts 占 8，末尾再补 8） - 优化后：
double ts; int id; byte flag;→ 占用 16 字节（ts 占 8，id 占 4，flag 占 1，末尾补 3 对齐到 8 的倍数） - 效果：单个对象节省 8 字节；百万实例即节省 ~8MB 堆空间，且更紧凑 → 缓存命中率更高，GC 复制/标记更快
避免跨缓存行的高频字段拆分
现代 GC（如 ZGC、Shenandoah）依赖并发标记与读屏障，频繁访问的字段若被拆到不同缓存行，会加剧伪共享，拖慢 mutator 线程：
- 例如，将 引用字段（如 parent、children[]）和 状态字段（如 isDirty、version）交错声明，容易导致它们落在不同 64 字节缓存行
- 建议把逻辑强相关的字段聚在一起，尤其是一起读写的引用+标志组合（如
Node next; boolean hasNext;），尽量保证它们位于同一缓存行内 - 必要时可用
@Contended（JVM）或 padding 字段隔离热点字段，防止干扰 GC 线程的内存预取
慎用 packed / unaligned 布局
虽然 __attribute__((packed)) 或 #pragma pack(1) 能减小结构体体积，但对 GC 友好反而是负向的：
- GC 需要安全识别指针字段位置；非标准对齐可能导致扫描器跳过某些偏移，造成漏标（false negative）
- JVM 不允许用户自定义对象使用非对齐布局；Go 的
unsafe.Offsetof在 packed struct 上行为未定义，影响逃逸分析与栈上分配决策 - 仅在纯数据缓冲区（如 ByteBuffer wrap 的原始内存）中可接受 unaligned 访问，但这类区域通常不在 GC 管理范围内
