Unsafe不能直接做缓存行填充，它仅提供底层内存操作能力；真正可行的方式只有手动字段填充或使用@Contended注解，二者均与Unsafe无关。
Unsafe 不能直接做缓存行填充，它只是底层内存操作的“扳手”
Java 中没有标准 API 能直接控制对象字段在内存中的对齐或填充位置，Unsafe 本身也不提供“插入 padding 字段”这种语义。它只暴露了 allocateMemory、putLong、getLong 等原始地址操作能力，而 JVM 对普通 Java 对象（包括字段布局）的内存排布有严格规则——Unsafe 无法绕过这些规则去“修改类结构”。所以指望用 Unsafe 在运行时给一个已存在的 class 动态加 padding 字段，是做不到的。
实际能用 Unsafe 的地方，仅限于：手动分配一块裸内存，然后按自己设计的 layout（比如前 56 字节全 pad，第 57–64 字节放 volatile long value）写入数据。但这意味着你必须完全放弃对象模型，自己管理生命周期、GC 友好性、线程安全语义——得不偿失，生产环境几乎没人这么干。
真正可行的 padding 方式只有两种：手动字段填充 or @Contended
目前 JVM 生态中稳定、可维护、被广泛验证的填充方式只有以下两种，且都与 Unsafe 无关：
- 在类中显式声明多个无用的
long字段（每个 8 字节），把关键 volatile 字段“夹在中间”，确保它独占一个 64 字节缓存行；例如：pad1到pad7（56 字节） +volatile long value（8 字节）刚好 64 字节，再加pad8到pad14是为了防止该对象后续扩展字段挤占相邻缓存行 - 使用 JDK 8+ 的
@sun.misc.Contended注解（需启动参数-XX:-RestrictContended），JVM 会在该字段前后自动插入 128 字节填充（默认值），适用于高竞争场景；注意：该注解默认被禁用，且仅对字段有效，不能标注整个类
这两种方式都是编译期/加载期决定的内存布局，Unsafe 不参与其中。强行用 Unsafe 去“模拟”字段填充，只会让代码更难调试、更难迁移、更难被 JIT 优化。
为什么有人误以为 Unsafe 能做 padding？
混淆通常来自两类场景：
- 某些早期高性能库（如 Disruptor）用
Unsafe计算对象字段偏移量（objectFieldOffset），用于快速读写；但 padding 逻辑仍是靠手动字段写的，Unsafe只负责“找到那个字段在哪”，不是“把它挪到哪” - 用
Unsafe配合字节码增强（如 ASM）在类加载时重写 class 文件，注入 padding 字段——这本质是字节码操作，Unsafe仅作为辅助工具，真正起作用的是字节码改写逻辑
如果你看到某段代码里同时出现 Unsafe 和 “padding”，大概率是前者在读写后者定义出来的字段，而非 Unsafe 在生成 padding。
@Contended 的兼容性与隐蔽成本必须提前确认
@Contended 看似最省事，但它有几个容易被忽略的硬约束：
- JDK 8 引入，但 JDK 9–14 默认禁用，必须加
-XX:+UnlockExperimentalVMOptions -XX:-RestrictContended；JDK 15+ 默认启用，但字段仍需明确指定@Contended("group")才生效 - 它会让对象大小膨胀至少 128 字节（含 group 隔离开销），如果对象创建频繁，会显著增加 GC 压力
- 某些容器（如
ArrayList、ConcurrentHashMap）内部节点未加该注解，即使你自己写了@Contended，也无法解决它们的伪共享问题——得看具体类是否真的用了它
最终是否真规避了伪共享，不能只看代码写了 padding，得用 perf stat -e cache-misses 或 JMH 对比吞吐量变化。很多看似“填满了”的类，在不同 CPU 架构（比如 Apple M 系列 128 字节缓存行）下依然可能踩坑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
