AtomicInteger 是最常用、最稳妥的高并发计数方案，基于 CPU 的 CAS 指令实现无锁原子更新，配合 volatile 保证可见性；适用于绝大多数计数场景，但写操作极密集时可换 LongAdder，多变量或多步逻辑需用锁，复合操作须避免 get-then-set 陷阱。
直接用 AtomicInteger 是最常用、最稳妥的做法。它底层靠 CPU 的 CAS 指令实现无锁原子更新，不阻塞线程，性能好，写法简洁，适合绝大多数高并发计数场景。
为什么 AtomicInteger 能扛住高并发
它不是靠加锁，而是利用硬件级的 Compare-And-Swap（比较并交换）指令：每次自增前先读当前值，尝试把“旧值+1”写回去，如果期间被别的线程改过，就自动重试。整个过程由 CPU 保证原子性，没有上下文切换开销。
内部还用 volatile 保证变量修改对所有线程立即可见，避免缓存不一致问题。
常用操作写法
这些方法全是线程安全的，无需额外同步：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
counter.incrementAndGet()：原子加 1，返回新值（相当于++i） -
counter.getAndIncrement()：原子加 1，返回旧值（相当于i++） -
counter.compareAndSet(expected, newValue)：仅当当前值等于预期值时才更新，适合带条件的计数逻辑（比如“库存大于 0 才扣减”） -
counter.addAndGet(delta)：加指定数值，比循环调用 increment 更高效
什么时候该换别的方案
AtomicInteger 不是万能的，以下情况建议考虑替代方案：
- 写操作极密集（比如每秒百万次以上递增），且读操作远少于写操作 → 改用 LongAdder，它通过分段累加减少 CAS 冲突，最终用
sum()获取总数 - 需要保护不止一个变量，或一段含多步逻辑的代码（比如“查余额→扣款→记日志”）→ 用 synchronized 或 ReentrantLock，虽然有锁开销，但语义清晰可控
- 计数只是更大业务流程中的一环，且涉及数据库、远程调用等耗时操作 → 单纯靠原子类不够，得结合事务、幂等设计和限流来保障整体一致性
容易踩的坑
别以为用了 AtomicInteger 就万事大吉：
- 它只保单个变量的原子性，不能保证复合操作（比如“先 get 再 set”）的线程安全，这种必须加锁或改用
compareAndSet - 不要把它当作全局状态的“万能解”，比如用它存用户登录态或复杂对象引用，语义错位反而增加维护难度
- 在 ThreadLocal 或异步线程中使用时，注意生命周期管理，避免误共享或内存泄漏
