volatile不保证原子性，仅提供可见性与有序性；CAS保证原子性但不解决可见性；Disruptor依赖Ring Buffer与无锁设计实现高性能，但需严守MPSC等前提。
volatile 不等于线程安全，CAS 不等于无条件高性能，Disruptor 也不是万能解药——高并发系统真正抗压的根基，在于对内存屏障语义的精准控制、对无锁路径竞争热点的主动拆解，以及对结构化并发边界的清醒划定。
内存屏障不是“加个 volatile 就完事”
很多开发者把 volatile 当作“轻量级 synchronized”，但它的底层作用只是插入**获取屏障（Acquire）或释放屏障（Release）**，不保证复合操作原子性。比如 counter++ 即使字段是 volatile int counter，依然会出错，因为读-改-写三步无法被 volatile 覆盖。
真正需要屏障语义的场景，比如生产者更新尾指针后必须让消费者立即看到新节点数据，JCTools 用的是 UNSAFE.putOrderedLong，它比 volatile 写更轻量（不带全屏障），但比普通写多了释放屏障保障；而消费者读头节点时用 UNSAFE.getLongVolatile，等价于带获取屏障的读。
- 不要在循环里反复读
volatile字段判断状态，可能触发频繁缓存同步，改用LockSupport.parkNanos+ 自旋计数控制 -
final字段的初始化安全由 JMM 的“初始化安全性”保障，和屏障无关，别混用 - JDK9+ 的
VarHandle已逐步替代Unsafe，但语义映射需注意：setRelease≈putOrdered，getAcquire≈getVolatile
无锁 ≠ 没有竞争，MPSC 队列的“单消费者”约束必须守死
MpscLinkedQueue 的高性能前提是：只有一个线程调用 poll()。一旦多个消费者同时调用，就会出现 ABA 或指针错乱——它没做 MPMC 的保护，强行多消费只会静默丢数据或无限循环。
真实业务中常见错误是把一个队列注入多个 @EventListener 或多个 ScheduledTask，表面看是“读操作”，实则破坏了 MPSC 前提。正确做法是：用 MpscArrayQueue（MPMC）或在外层加一层单线程 Dispatcher。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
- MPSC 队列适合日志异步刷盘、指标批量上报等“一写多读分发后处理”的场景，不适合任务分发给多个工作线程
-
MpmcArrayQueue的环形缓冲区依赖P_INDEX_OFFSET和C_INDEX_OFFSET分离读写索引，但数组长度必须是 2 的幂，否则位运算取模失效 - 无锁结构扩容成本极高，JCTools 所有队列都不支持动态扩容，上线前必须根据峰值 QPS × 平均消息大小预估容量
结构化并发不是语法糖，是取消传播与生命周期绑定的硬约束
Java 19+ 的 StructuredTaskScope 不是“让代码看起来更整齐”，它的核心价值是：子任务异常时自动 cancel 其他并行分支，且父作用域退出时强制中断所有子任务。这直接解决了传统 ExecutorService.invokeAll 中“某个慢任务卡住整个批处理”的问题。
但要注意：它要求所有子任务必须在同一个作用域内启动并 join，不能跨方法边界泄漏 TaskScope 实例，否则取消信号无法传递。
- 不要在
try-with-resources外持有StructuredTaskScope引用，scope 关闭后所有子任务会被中断 - IO 密集型任务建议用
ShutdownOnFailure，计算密集型建议用ShutdownOnSuccess，避免失败任务拖垮整体响应 - Spring 环境下若用
@Async，默认走线程池，不参与结构化生命周期，需显式集成StructuredTaskScope才能获得取消传播
