AtomicInteger 通过 CAS 指令和 volatile 语义实现无锁原子更新，仅保证单变量读-改-写操作（如 incrementAndGet）的原子性，多字段协同更新仍需同步机制。
AtomicInteger 为什么能保证线程安全
因为 AtomicInteger 底层依赖 CPU 提供的 CAS（Compare-And-Swap）指令，配合 volatile 语义实现无锁原子更新。它不依赖 synchronized 或 Lock，避免了阻塞和上下文切换开销。
常见误解是“用了 AtomicInteger 就万事大吉”——其实仅对单个变量的读-改-写操作（如 incrementAndGet()、compareAndSet()）是原子的；多个字段协同更新仍需额外同步机制。
- 所有修改方法（如
addAndGet()、decrementAndGet()）都返回新值，且整个操作不可中断 -
get()和set()等价于 volatile 读/写，不保证复合操作原子性 - 在高竞争场景下，CAS 失败会自旋重试，可能带来 CPU 浪费，极端情况下不如锁稳定
常用方法对比与使用场景
不同方法适用于不同原子需求，选错会导致逻辑错误或性能下降：
-
incrementAndGet()：适合计数器累加，返回递增后的值；若只需自增不关心结果，用getAndIncrement()（返回旧值） -
compareAndSet(expected, updated)：实现乐观锁核心，例如“仅当当前值为 0 时设为 1”，失败不阻塞，需手动重试 -
accumulateAndGet(x, accumulatorFunction)：Java 8+ 支持自定义二元运算（如取最大值：Math::max），比循环调用addAndGet()更简洁 - 避免用
get() + 某些计算 + set()模拟原子操作——这三步之间可能被其他线程插入，造成竞态
容易踩的坑：volatile 不能替代 AtomicInteger
声明 volatile int counter 只能保证可见性和禁止重排序，但 counter++ 是“读-改-写”三步操作，依然非原子。JVM 不会对 volatile 字段的复合操作做原子保障。
立即学习“Java免费学习笔记（深入）”；
典型错误现象：volatile int count = 0; 在多线程下执行 1000 次 count++，最终结果常小于 1000。
- 正确做法：直接用
AtomicInteger count = new AtomicInteger(0);，然后调用count.incrementAndGet() - 注意构造函数：默认初始值为 0，也可传入
new AtomicInteger(100) - 序列化时
AtomicInteger会序列化其内部value字段，反序列化后仍是独立实例，不共享状态
与 synchronized 对比：何时该换用锁
AtomicInteger 适合简单状态变更，一旦涉及多个变量联动或复杂条件判断，强行用 CAS 会让代码难读且易出错。
例如：要同时更新 balance 和 lastModifiedTime，且要求二者严格一致；或者需要“如果余额 > 100 则扣款并记录日志”，这类场景用 synchronized 或 ReentrantLock 更清晰可靠。
- CAS 自旋在低竞争下快，在高竞争下可能反复失败，吞吐反而下降
- 调试困难：没有线程堆栈信息，CAS 失败不会抛异常，只能靠日志或断点排查
- 内存占用略高：每个
AtomicInteger实例包含一个 volatile int 和一些辅助字段，比普通 int 多几个字节
