原子性指CPU级不可分割的操作，Java中仅基本类型单次读写（除32位JVM下long/double）是原子的；a++等复合操作非原子，需AtomicInteger等通过CAS+volatile+自旋实现。
原子性不是“看起来像一次操作”，而是CPU级的不可分割
在Java里，a++、i += 1、list.add(x) 这些都不是原子操作——哪怕它们只写一行代码。真正算原子的，只有极少数：比如对 int、boolean 等基本类型的**单次读或单次写**（int x = 5; 或 flag = true;），且不涉及 long/double 在32位JVM上的拆分风险。
为什么？因为 a++ 实际被编译为三步：读取a → 计算a+1 → 写回a。中间任何一步都可能被线程切换打断，导致多个线程同时执行时“丢失一次自增”。
- long/double 在某些 JVM（如32位）上可能被拆成两次32位写入，因此单纯赋值也不绝对原子；加
volatile可修复这点，但仅限于读/写本身，不保复合操作 -
volatile能保证可见性，但不能让counter++变成原子——这是初学者最常踩的坑 - 真正的原子性必须由硬件指令兜底，比如 x86 的
cmpxchg，或 ARM 的ldaxr/s
tlxr
AtomicInteger.incrementAndGet() 是怎么做到不锁还能原子的？
它靠的是 CAS（Compare-And-Swap） + volatile + 自旋重试。核心逻辑是：“我看到当前值是 V，如果它现在还是 V，就把它改成 V+1；否则重试”。整个过程由 CPU 指令保证不可中断。
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
其中 unsafe.getAndAddInt 底层调用的就是平台相关的 CAS 指令（如 x86 的 lock xadd）。关键点：
- 失败不阻塞，而是循环重试——适合冲突低的场景（如计数器、状态标记）
- 不是所有操作都支持 CAS：比如
ArrayList.add()涉及数组扩容、元素移动，没法靠一条指令完成，所以没有对应的原子类 - 注意 ABA 问题：值从 A→B→A，CAS 会误判成功。必要时用
AtomicStampedReference带版本号
什么时候该用 synchronized，而不是 AtomicXXX？
Atomic 类只适用于**单变量、简单逻辑**的原子更新。一旦操作涉及多个变量、条件判断、IO 或复杂业务规则，CAS 就无能为力了。
例如下面这段伪代码无法用 AtomicXXX 安全实现：
if (balance >= amount) {
balance -= amount;
logTransaction(amount);
}
原因很直接：
-
balance >= amount和balance -= amount是两个独立内存操作，中间存在时间窗口 - AtomicXXX 提供的
compareAndSet只能做“单值比较+单值更新”，无法嵌入日志、校验、分支等任意逻辑 - 这种场景必须用
synchronized或ReentrantLock包裹整段临界区
性能上，高竞争下 CAS 自旋开销可能反超锁——别迷信“无锁一定更快”。实测比对才靠谱。
AtomicReference 和普通对象引用有什么区别？
AtomicReference 不是对 User 对象内部字段做原子操作，而是对“指向这个对象的引用本身”做原子更新。换句话说，它保证的是“把 ref 从指向 A 换成指向 B”这一步不可打断。
典型用途：
- 无锁栈/队列的头节点更新（如
ConcurrentLinkedQueue） - 状态机切换：
state.compareAndSet(RUNNING, STOPPING) - 避免 volatile 引用的“脏读”：即使
User是可变对象，只要引用更新是原子的，其他线程就不会看到“半构造”的引用
注意：AtomicReference 的 get() 和 set() 是轻量级的，但 compareAndSet() 才触发 CAS；不要误以为所有方法都走硬件指令。
incrementAndGet() 很容易，但想清楚“为什么这里不能拆成两步读写”，才是并发编程绕不开的坎。
