必须用synchronized而非volatile的场景是需保证复合操作原子性时，如i++、多变量协同更新（如银行转账），因volatile不保证原子性，而synchronized可锁住整个临界区确保串行执行。
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免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
