AtomicInteger原子操作原理与使用解析

本文深入剖析了AtomicInteger的底层原子机制——它摒弃传统synchronized锁，依托CPU级CAS指令（通过Unsafe.compareAndSwapInt实现），实现无阻塞、高效率的线程安全计数；清晰对比了incrementAndGet与getAndIncrement在语义和返回值上的本质区别，揭示了普通++操作在多线程下丢失更新的根本原因，并强调了compareAndSet必须配合循环重试才能真正发挥无锁优势；同时不回避CAS的局限性，如ABA问题及其适用边界，帮助开发者从“会用API”跃升到“懂原理、知取舍、避陷阱”的实战水准。

AtomicInteger底层靠的是CAS还是synchronized

AtomicInteger不依赖 synchronized，核心是CPU级别的CAS（Compare-And-Swap）指令，由 Unsafe.compareAndSwapInt 实现。JVM会将它编译为对应平台的原子汇编指令（如x86的 cmpxchg），无需加锁，也没有线程阻塞开销。

注意：CAS不是万能的——存在ABA问题，但 AtomicInteger 不处理这个（因为它只关心数值是否变化，不关心“变过几次”；若需ABA防护，得用 AtomicStampedReference）。

incrementAndGet() 和 getAndIncrement() 的行为差异

两者都原子地加1，但返回值不同：

• incrementAndGet() 返回**更新后的新值**（先加再取）
• getAndIncrement() 返回**更新前的旧值**（先取再加）

例如初始值为5：

AtomicInteger ai = new AtomicInteger(5);
int a = ai.incrementAndGet(); // a == 6，ai.get() == 6
int b = ai.getAndIncrement(); // b == 6，ai.get() == 7

选哪个取决于业务逻辑对“序号”或“计数器”的语义要求——比如生成唯一ID通常用 incrementAndGet()，而日志计数器可能更倾向 getAndIncrement()。

为什么不能直接用 ++ 操作符替代 AtomicInteger

++ 是三步操作：读内存 → 计算+1 → 写回内存。在多线程下，两个线程可能同时读到相同旧值，各自+1后再写回，导致只加了一次（丢失一次更新）。

而 AtomicInteger.addAndGet(1) 或 incrementAndGet() 把这三步打包成一个不可分割的硬件操作，失败时自动重试（自旋），保证结果正确。

常见误用场景：

• 把 AtomicInteger 当普通 int 传参后做 ++：参数传递的是副本，原对象不受影响
• 在循环里反复调用 get() 再手动 set()：这已脱离原子性保障

compareAndSet() 的典型使用模式和陷阱

compareAndSet(expectedValue, newValue) 是最灵活的原子操作，常用于实现无锁算法或条件更新。

典型用法示例（实现一个简单的“首次初始化”）：

AtomicInteger flag = new AtomicInteger(0);
// 只有第一次调用会成功，返回 true
if (flag.compareAndSet(0, 1)) {
    initialize();
}

容易踩的坑：

• 预期值写错：比如用 flag.get() 的瞬时快照作为 expectedValue，但该值可能已被其他线程改过，导致CAS失败——这不是bug，是设计使然，需要配合循环重试（即自旋）
• 把 compareAndSet 当作“乐观锁”却忽略重试逻辑，结果失败后静默跳过，造成逻辑遗漏
• 在高竞争场景下，频繁CAS失败会带来明显CPU自旋开销，此时需评估是否改用 ReentrantLock 等显式锁

真正难的不是调用API，而是判断什么时候该用CAS、什么时候该让出CPU、以及如何避免ABA在业务语义中引发歧义。

今天关于《AtomicInteger原子操作原理与使用解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！