AtomicInteger适用于高频无锁整数更新场景，如计数器、状态标志、序号生成；不适用于多变量协同、需阻塞等待或超int范围的场景，其底层基于CAS实现无锁但存在自旋开销。
AtomicInteger 适合需要简单、高频、无锁更新整数的场景，比如计数器、序列号生成、状态标志位等。它不适用于复杂业务逻辑的原子操作，也不能替代 synchronized 或 Lock 处理多变量协同变更。
适合用 AtomicInteger 的典型场景
• 高并发计数器：如网站 PV/UV 统计、接口调用次数、线程池任务完成数。多个线程反复执行 incrementAndGet() 或 addAndGet()，无需加锁也能保证结果正确。
• 轻量级状态控制：用 0/1 表示“未初始化/已初始化”或“关闭/开启”，配合 compareAndSet() 实现乐观锁式状态切换。
• 分配唯一序号：如日志 ID、请求 traceId 的自增生成（要求不严格连续，但需唯一且无竞争），比数据库主键或 UUID 更轻量。
不适合用 AtomicInteger 的情况
• 涉及多个变量的原子操作：比如“余额减扣 + 订单状态更新”，AtomicInteger 只能保一个 int，无法让两个字段一起成功或一起失败。
• 需要阻塞等待或超时控制：它只提供立即返回的 CAS 操作，不支持类似 lock.tryLock(3, TimeUnit.SECONDS) 这样的语义。
• 数值范围超出 int（±2³¹−1）：此时应考虑 AtomicLong 或 AtomicLongFieldUpdater；若需更高精度，AtomicInteger 会溢出回绕，可能引发隐蔽问题。
底层原理简明说明：为什么叫“无锁”
• 它依赖 CPU 提供的 CAS（Compare-And-Swap）指令，在硬件层面保证“读取-比较-写入”三步不可分割。
• 不使用操作系统互斥量（mutex）或 JVM 的 monitor 锁，因此没有线程挂起/唤醒开销，避免了传统锁的上下文切换和竞争瓶颈。
• 但要注意：CAS 可能因其他线程修改过值而失败，所以内部是循环重试（自旋），在高争用下可能浪费 CPU——这不是锁，但也不是零成本。
使用建议与常见误区
• 优先用方法而非直接读 field：比如用 get() 而非直接访问 value（它是 private volatile），确保可见性。
• 慎用 getAndIncrement() 等“先读后写”方法：它们返回旧值，在某些逻辑中容易误用；确认是否真需要旧值，否则用 incrementAndGet() 更直观。
• 不要把它当普通 int 传参或做复杂表达式运算：比如 ai.get() + 1 不是原子的，必须用 ai.incrementAndGet() 或 ai.addAndGet(1)。
