Java中天然原子的操作仅限基本类型（boolean、byte、short、char、int、float）的单次读或写；long和double在32位JVM上可能非原子；i++等复合操作即使作用于int也非原子，需用AtomicInteger等类或synchronized保障。
Java 中的原子性问题不能靠 synchronized 或普通变量“凑合解决”，必须明确区分「哪些操作天然原子」「哪些需要显式保障」，否则会在线程交错时出现读写撕裂、计数丢失等隐蔽错误。
哪些操作在 Java 中是天然原子的？
Java 语言规范只保证对基本类型（boolean、byte、short、char、int、float）的**单次读或写**是原子的；long 和 double 在 32 位 JVM 上可能非原子（虽现代 HotSpot 默认开启 -XX:+UseCompressedOops 后通常已修复，但不建议依赖）。
注意：「原子读/写」不等于「原子操作」——比如 i++ 是「读-改-写」三步，哪怕 i 是 int，它也**不是原子的**。
-
i = 5是原子写；i++不是 -
obj.field = new Object()是原子写（引用赋值），但构造对象过程本身不原子 -
volatile只保证可见性和禁止重排序，不保证复合操作原子性
用 java.util.concurrent.atomic 解决典型场景
这是最常用、开销最小的方案。核心是用 CAS（Compare-And-Swap）替代锁，避免阻塞。
常见误用：把 AtomicInteger 当普通 int 用，却仍写 i.get() + 1 再 set，这和 i++ 一样非原子。
AtomicInteger counter = new AtomicInteger(0);
// ✅ 正确：CAS 保证整个自增原子
counter.incrementAndGet();
// ❌ 错误：get + set 分两步，中间可能被其他线程插入
int v = counter.get();
counter.set(v + 1);
// ✅ 替代方案：用 compareAndSet 显式控制
int expect;
do {
expect = counter.get();
} while (!counter.compareAndSet(expect, expect + 1));
-
AtomicBoolean适合状态开关（如启动/停止标记） -
AtomicRefer用于无锁更新对象引用，配合
ence
compareAndSet实现乐观锁 -
AtomicStampedReference解决 ABA 问题，但多数业务场景不需要——先确认是否真有 ABA 风险再引入
什么时候该用 synchronized 或 ReentrantLock？
当操作涉及多个变量、跨对象协作、或需保证一组语句的原子性（即「临界区」）时，原子类无法覆盖。
例如银行转账：扣减 A 账户、增加 B 账户，必须整体成功或失败，且不能被其他转账干扰。
synchronized (lockObj) {
if (accountA.balance >= amount) {
accountA.balance -= amount;
accountB.balance += amount;
// 这里还可能发日志、更新时间戳……
}
}
- 锁对象要固定（推荐用私有 final 对象），避免用
this或字符串字面量，防止外部锁定导致死锁或干扰 -
ReentrantLock提供可中断、超时、公平性等能力，但多数简单场景synchronized更轻量、JVM 优化更好 - 不要为了“看起来更高级”而用
Lock替代synchronized，除非真需要它的特性
容易被忽略的陷阱：内存模型与重排序
即使用了原子类或锁，若没理解 happens-before 规则，仍可能看到过期值。例如：
- 一个线程用
atomicFlag.set(true)标记完成，另一个线程循环while (!atomicFlag.get())等待——这没问题，Atomic*的读写自带 happens-before - 但如果换成普通
boolean done = false，即使加了synchronized块，未正确同步读写路径，就可能永远看不到true -
final字段的初始化安全发布（safe publication）常被忽视：对象构造完成前，其他线程可能看到未初始化的字段值
真正难的不是选工具，而是判断「哪段逻辑必须原子」「哪些变量需要同步可见」——这得从数据流和状态变更边界出发，而不是背 API。
