Java多线程竞态条件怎么解决

本文深入剖析了Java多线程中竞态条件的本质与实战解决方案，明确指出volatile无法替代synchronized的关键场景——当涉及复合操作（如i++）或多变量协同更新（如银行转账）时，只有synchronized或ReentrantLock能保证临界区的原子性；同时澄清了AtomicInteger的适用边界：虽高效安全，却无法解决“检查-执行”类逻辑和跨变量一致性问题；还揭示了ConcurrentHashMap.size()不准的根源在于性能与一致性的权衡，并强调真正决定线程安全的不是是否用了同步机制，而是锁的范围是否严丝合缝地覆盖所有共享状态的读写路径——细微的遗漏，足以让精心设计的并发控制功亏一篑。

Java里什么时候必须用synchronized而不是volatile

volatile只能保证变量的可见性和禁止指令重排序，但不保证原子性。比如i++这种读-改-写操作，即使i是volatile int，依然会丢数据。

• 多个线程同时执行counter++（无论counter是否volatile），最终结果大概率小于预期
• synchronized能锁住临界区，确保同一时刻只有一个线程执行该段代码
• 用synchronized(this)或同步方法时，注意锁对象是否一致——不同实例的this互不干扰，无法解决共享资源竞争
• 如果锁的是静态方法或synchronized(Counter.class)，才真正控制类级别的共享状态

AtomicInteger真能完全替代synchronized吗

多数场景下可以，但不是万能的。它靠CAS实现无锁原子更新，性能好、不易死锁，但仅适用于单变量的简单操作。

• AtomicInteger.incrementAndGet()安全，AtomicInteger.compareAndSet()也安全，但if (ai.get() > 10) ai.set(0)这种“检查后执行”仍是竞态——中间可能被其他线程修改
• 需要多变量协同更新时（比如银行转账：扣A账户+加B账户），AtomicInteger无法保证整体原子性，仍得用synchronized或ReentrantLock
• 高争用场景下，CAS反复失败会带来CPU空转开销，反而不如直接上锁来得稳

ReentrantLock比synchronized多了什么实际价值

核心就三点：可中断、可超时、可公平。但默认非公平模式下，性能和语义几乎等价于synchronized，别为了“高级感”硬换。

• 需要响应中断时用lockInterruptibly()，比如线程正在等锁，外部调用thread.interrupt()能立刻跳出
• 避免无限等待：用tryLock(1, TimeUnit.SECONDS)，超时就放弃，适合有兜底逻辑的场景（如降级查缓存）
• 公平锁（new ReentrantLock(true)）会按请求顺序排队，但吞吐量明显下降，除非业务强依赖执行顺序，否则别开
• 记得在finally块里调用unlock()——synchronized是JVM自动释放的，这里手写漏了就永久锁死

ConcurrentHashMap的size()为什么不准

它为并发性能牺牲了实时一致性。size()不是加锁遍历，而是尝试多次估算，返回的是近似值。

• 高并发写入时，size()可能比真实值小，甚至连续调用两次返回不同结果
• 想精确计数？要么自己用AtomicLong单独维护，要么接受“估算”，别拿它做判断条件（比如if (map.size() == 0)）
• 真正安全的判空是map.isEmpty()，这个方法内部做了必要同步
• 如果需要强一致的大小统计，说明设计可能已偏离ConcurrentHashMap的使用初衷——考虑是否该换用普通HashMap加外部锁

竞态条件从来不在“有没有锁”，而在“锁的范围是否覆盖所有共享状态变化路径”。哪怕只漏掉一行赋值、一次get后再set，都可能让整个同步失效。细节藏在每处读写之间，不是加了synchronized或用了AtomicXxx就万事大吉。

到这里，我们也就讲完了《Java多线程竞态条件怎么解决》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！