Atomic类专为单变量“读-改-写”操作设计，基于CAS实现无锁原子性，适用于计数器、标志位等场景，但不适用于多变量一致性保护。
Atomic类是用来替代synchronized做单变量线程安全更新的
它不是万能锁替代品，而是专为“对一个变量做读-改-写”这类操作设计的轻量方案。比如 count++、flag.set(true)、ref.compareAndSet(old, new)——这些原本非原子的操作，在Atomic类里被封装成一条CPU指令（如CAS），天然不阻塞、无锁、不挂起线程。
- 适用场景：计数器、开关标志、状态位切换、无锁栈/队列中的头节点更新
- 不适用场景：需要保护多变量一致性（如“扣库存+写日志”必须一起成功）、涉及IO或长耗时逻辑的临界区
- 性能差异：高并发下
AtomicInteger.incrementAndGet()比synchronized快 3–5 倍，因为没锁竞争开销；但低并发时差别几乎不可测
为什么AtomicInteger.getAndIncrement()不会丢更新
根本原因不是“Java魔法”，而是底层调用 Unsafe.compareAndSwapInt() 实现的循环重试（CAS）：先读当前值 v，再尝试把 v+1 写回去，仅当内存中仍是 v 才成功；否则重读、重算、重试。整个过程由硬件保证“读-比-写”三步不可分割。
- 典型错误：误以为
getAndIncrement()和incrementAndGet()只是返回值顺序不同——其实它们都绝对线程安全，区别仅在返回时机 - 容易踩的坑：用
get()读出值后手动加1再set()，这完全破坏原子性，等价于裸写count++ - 注意
lazySet()：它不保证立即可见，只承诺“最终一致”，适合写入后不马上被其他线程读的场景（如链表尾指针更新）
AtomicReference和AtomicStampedReference怎么选
当你需要原子更新对象引用时，AtomicReference 是默认选择；但一旦涉及“修改前检查旧值”，就得警惕 ABA 问题——即某值从 A→B→A，compareAndSet(A, C) 会误判成功。
-
AtomicReference：适合纯引用替换，如无锁栈的head更新、配置对象热替换 -
AtomicStampedReference：带版本号，每次修改自动递增 stamp，compareAndSet(expectedRef, newRef, expectedStamp, newStamp)同时校验引用+版本，可破 ABA - 别用
AtomicMarkableReference解 ABA：它只带一个布尔标记，无法区分“两次变回A”和“一直就是A”，资料已明确修正该误区
字段更新器（Updater）为什么需要volatile修饰
AtomicIntegerFieldUpdater 这类 updater 不持有字段副本，而是直接操作目标对象的内存地址。为确保其他线程能看到最新值，被更新的字段**必须声明为 volatile**，否则 updater 的写入可能被编译器重排序或 CPU 缓存滞留。
立即学习“Java免费学习笔记（深入）”；
- 编译期检查：updater 的
newUpdater()方法在运行时会反射校验字段是否 volatile，不满足则抛RuntimeException - 典型用法：想给已有类（不能改源码）加原子能力，比如给第三方库的
public volatile int state字段配 updater - 注意：updater 无法跨类访问 private 字段，且对 final 字段无效
