AtomicInteger的核心作用是在不加锁前提下安全实现int型共享变量的原子读-改-写操作；适用于单变量高频更新场景，如计数器、低并发ID生成、一次性状态标志位管理。
AtomicInteger 的核心作用是：**在不加锁的前提下，安全地对一个 int 类型共享变量做原子读-改-写操作**。它不是万能锁替代品，而是专为“单变量高频更新”场景设计的轻量级并发工具。
什么时候该用 AtomicInteger？看这 3 个典型场景
它真正发挥价值的地方，是有明确“单点整数变更需求”，且能接受乐观重试机制的场景：
-
计数器类服务：比如接口调用量统计、歌曲“喜欢”按钮点击数（每首歌一个
AtomicInteger），incrementAndGet()一次到位，无锁无阻塞 -
序列号/ID 生成器（低并发）：如订单号前缀自增（
getAndIncrement()），只要不跨 JVM 或不要求全局唯一递增，比synchronized更快 -
状态标志位管理：比如用 0/1 表示“初始化完成”，用
compareAndSet(0, 1)做一次性状态跃迁，比volatile+ 手动判断更可靠
compareAndSe
t() 是灵魂，但别误以为它能当 if-else 用
很多开发者写出这种代码：
if (counter.get() < 100) {
counter.incrementAndGet(); // ❌ 竞态漏洞：get 和 increment 是两次独立原子操作
}
问题在于：两个线程可能同时通过 get() 判断，然后都执行 incrementAndGet()，最终突破 100。这不是 AtomicInteger 的缺陷，而是它只保证“单个方法原子”，不保证“逻辑块原子”。
正确做法只有两种：
- 如果必须带条件限制，改用
synchronized或ReentrantLock包裹整个判断+更新逻辑 - 或者用循环 CAS 模拟原子条件更新（需谨慎，易写错）：
int current;
do {
current = counter.get();
if (current >= 100) break;
} while (!counter.compareAndSet(current, current + 1));
别踩这 3 个常见坑
-
数值溢出不报错：
int范围是 -2³¹ ~ 2³¹−1，超限后会回绕（比如2147483647 + 1变成-2147483648）。业务上需要上限控制时，必须自己检查，AtomicInteger不会抛异常 -
多字段无法协同原子：“扣余额 + 改订单状态”这种涉及两个变量的操作，
AtomicInteger完全无能为力，必须用锁或事务 -
高争用下 CPU 白耗：当上百线程疯狂竞争同一个
AtomicInteger，CAS 失败后自旋重试，可能导致某核 CPU 占用飙升，而实际吞吐没提升——这时该考虑分段计数（如LongAdder）或降级为锁
AtomicInteger 的边界其实很清晰：它只解决“一个 int 变量怎么安全改”的问题。一旦需求里出现“多个值”“带条件”“要阻塞等待”“要超时”“要大数精度”，就该立刻意识到——它已经不在职责范围内了。
