17370845950

原子性指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/stlxr

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() 很容易，但想清楚“为什么这里不能拆成两步读写”，才是并发编程绕不开的坎。