putOrderedInt比volatile写更轻量，因为它仅插入StoreStore屏障，不保证立即可见性，避免了volatile所需的StoreLoad全屏障开销，适用于单写多读且容忍短暂陈旧值的场景。
putOrderedInt 为什么比 volatile 写更轻量
putOrderedInt 是 Unsafe 提供的延迟可见性写操作，它只插入一个 StoreStore 屏障（而非 volatile 写所需的 StoreLoad），避免了对后续读/写的重排序，但不保证当前写立即对其他线程可见。这意味着：它适合“写后不立刻读、也不依赖即时全局可见性”的场景，比如链表尾指针推进、计数器累加（配合最终 flush）、RingBuffer 的 producer cursor 更新。
常见错误是把它当 volatile 替代品用——比如在写完 putOrderedInt 后立刻 getVolatile 读同一字段，结果读到旧值还误以为是 bug；其实这是预期行为，不是失效。
- 仅适用于单写多读、且读端能容忍短暂陈旧值的场景
- 不能用于实现同步逻辑（如自旋等待某个字段变为特定值）
- JVM 对它的优化较激进，某些 CPU 架构（如 x86）可能实际不生成屏障，但代码语义仍需按 StoreStore 理解
如何正确调用 putOrderedInt 避免 ClassCastException 或 segfault
直接调用 putOrderedInt 前必须确保：目标字段是 int 类型、未被 JVM 优化掉（即不能是 final 或逃逸分析判定为栈封闭）、且偏移量通过 staticFieldOffset 或 objectFieldOffset 正确获取。最常踩的坑是传入 null 对象实例或用错 class loader 加载的类来获取偏移量。
示例中易错点：
Unsafe unsafe = getUnsafe();
long offset = unsafe.objectFieldOffset(Foo.class.getDeclaredField("counter")); // 必须是 public/accessible，否则抛 IllegalAccessException
Foo obj = new Foo();
unsafe.putOrderedInt(obj, offset, 42); // ✅ 正确：obj 非 null，offset 匹配 obj 实际布局
- 字段必须是非 static 的实例字段；对 static 字段要用
staticFieldOffset+staticFieldBase - 使用
getDeclaredField前需setAccessible(true)（若字段非 public） - 禁止复用不同类对象的 offset；JVM 可能在类重定义后改变字段布局
putOrderedInt 和 lazySet 的关系与 JDK 版本差异
AtomicInteger.lazySet(int) 底层就是调用 putOrderedInt，两者语义完全一致。区别在于封装层级：JDK 9+ 中 lazySet 是标准 API，而 Unsafe.putOrderedInt 是底层原语。JDK 8 及以前没有 lazySet，只能手撸 Unsafe。
注意兼容性陷阱：
- JDK 9+ 强烈建议用
lazySet，避免直接依赖Unsafe（该类在 JDK 17+ 被强封装，默认不可反射访问） - 某些 GraalVM 或 Android ART 环境下，
putOrderedInt可能被降级为普通 store（无屏障），但lazySet会尽力保持语义 - Netty、Disruptor 等高性能库在构建时会检测运行时 JDK 版本，自动选择
lazySet或 fallback 到Unsafe
什么情况下 putOrderedInt 反而拖慢性能
看似无锁无屏障就一定快？不一定。如果更新非常频繁（如每纳秒一次），且字段位于高争用缓存行（false sharing），putOrderedInt 仍会触发 write-invalidate 协议，导致大量 cache line bouncing。此时瓶颈不在屏障，而在缓存一致性协议本身。
更隐蔽的问题是：它无法防止编译器将多次写合并（虽然 JVM 规范禁止，但某些 JIT 优化路径下仍可能出问题），尤其在循环内连续写同一字段时，可能被重排或省略。
- 务必用
@Contended或手动 padding 隔离热点字段，避免 false sharing - 不要在 tight loop 中反复
putOrderedInt同一字段而不做批处理或退避 - 若后续有依赖该字段状态的逻辑（哪怕只是日志打点），应改用
set或显式Unsafe.fullFence()
真正发挥价值的地方，是那些写密集、读稀疏、且读端自带校验或容忍延迟的基础设施代码——比如消息队列的序列号推进、GC 中的 card table 标记。一旦脱离这些上下文，盲目替换 volatile 往往得不偿失。
