AtomicInteger 的 ++ 或 += 操作不原子，因会分解为读-算-写三步，即使字段 volatile 也无法保证整体原子性；必须使用 incrementAndGet()、compareAndSet() 等原子方法。
AtomicInteger 能保证对 int 类型的读-改-写操作是原子的，但前提是所有线程都通过它提供的方法（如 incrementAndGet()、compareAndSet()）访问，而不是直接读写其内部值。
为什么不能直接用 ++ 或 += 操作 AtomicInteger
AtomicInteger 本身不是“可变的 int”，它的值存放在一个 volatile int 字段里，但 ++ 这类操作会触发三步：读取当前值 → 计算新值 → 写回。即使字段是 volatile，这三步也不具备原子性。
常见错误现象：
- 多线程下执行 counter.get()++ 或 counter.value++（假设你反射访问了私有字段）→ 结果小于预期
- 编译器或 JVM 可能重排序非同步的普通读写，导致逻辑错乱
正确做法必须使用原子方法：
-
counter.incrementAndGet()：先加 1 再返回新值 -
counter.getAndIncrement()：先返回旧值再加 1 -
counter.addAndGet(5)：加指定值并返回结果
compareAndSet() 是唯一能实现条件更新的入口
这是实现无锁算法（如自旋锁、计数器限流、状态机切换）的核心。它等价于「如果当前值等于预期值，则设为新值，并返回 true；否则返回 false」。
立即学习“Java免费学习笔记（深入）”；
使用场景举例：实现一个只初始化一次的懒加载计数器
private static final AtomicInteger initialized = new AtomicInteger(0);
private static volatile SomeResource resource;
<p>public static SomeResource getInstance() {
if (resource == null) {
if (initialized.compareAndSet(0, 1)) {
resource = new SomeResource();
}
}
return resource;
}注意点：
- compareAndSet() 不阻塞，失败后需自行决定是否重试（比如在 while 循环中）
- 第一个参数是「期望的当前值」，不是旧值快照；多线程下可能已被其他线程改过，所以常配合循环使用
- 它底层依赖 CPU 的 CAS（Compare-And-Swap）指令，在 x86 上对应 cmpxchg，JVM 会自动编译为该指令
AtomicInteger 不是万能的：复合操作仍需同步
如果你需要「先判断再更新」且逻辑不可拆分（例如：只有当计数器小于 100 才加 1），compareAndSet() 单次调用无法完成，因为判断和更新之间存在时间窗口。
典型错误写法：
if (counter.get() < 100) {
counter.incrementAndGet(); // ❌ 中间可能已被其他线程突破 100
}可行方案有两种：
- 用循环 +
compareAndSet()实现乐观锁逻辑 - 对临界区加
synchronized或使用ReentrantLock
前者更轻量但可能自旋耗 CPU；后者更稳但引入锁开销。选哪个取决于冲突频率和延迟敏感度。
性能与兼容性：从 Java 5 到 Java 21 都稳定可用
AtomicInteger 自 Java 5 引入，所有现代 JDK（包括 GraalVM、OpenJDK、Zulu）完全支持，无兼容性问题。它的内存语义基于 JMM（Java Memory Model），保证：
- get() 总能看到之前任意线程对同一实例的 set() 或原子更新的结果
- 所有原子方法都有与 volatile 字段相同的 happens-before 保证
性能上，纯 CAS 操作比 synchronized 快 3–10 倍（视竞争程度），但在高争用场景下，频繁失败重试反而不如锁稳定。别盲目替换 synchronized —— 先压测，再决定。
真正容易被忽略的是：AtomicInteger 的 toString()、hashCode()、equals() 都只是基于当前值做快照，不参与原子性保证；序列化时也只保存当前数值，不保留操作历史。
