volatile 不能替代 synchronized 的场景

当你只用 volatile 修饰一个计数器变量，却在多线程里反复执行 count++，结果大概率出错——这不是 volatile 不生效，而是它不保证复合操作的原子性。

• count++ 实际包含“读取-修改-写入”三步，volatile 只确保每次读写都直通主内存，但两线程仍可能同时读到旧值、各自加 1、再写回，最终只加了一次
• 适用于纯状态标记（如 isRunning）、单次写入后只读的配置项，或配合 CAS 操作（如 AtomicInteger 内部）
• 若字段涉及多个变量协同更新（比如缓存 + 版本号），仅靠 volatile 无法建立同步边界，必须用锁或 synchronized 块包裹整个逻辑段

synchronized 块的临界区范围要刚刚好

把整个方法用 synchronized 修饰看似省事，但容易拖慢吞吐量；而临界区太小，又漏掉关键共享点，照样引发内存可见性问题。

• 检查是否所有访问共享状态的路径都被同一把锁保护：比如对象内部有 cacheMap 和 lastAccessTime，二者需同时更新，则不能只锁 map 操作，而忽略时间戳赋值
• 避免在同步块内调用外部可重入或阻塞的方法（如 I/O、远程调用），否则会把锁持有时间不可控地拉长
• 锁对象别用 this 或 getClass()，优先用私有 final 对象（如 private final Object lock = new Object();），防止外部误锁干扰同步边界

wait/notify 必须与 synchronized 配对使用

单独调用 wait() 或 notify() 会抛 IllegalMonitorStateException，这不是语法错误，而是 JVM 强制要求：必须先获得对象监视器（即进入 synchronized 块），才能触发等待/唤醒协议。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 经典坑：在 synchronized(obj) 块里调用了 obj.wait()，但没处理 InterruptedException，导致线程中断后锁未释放或状态错乱
• 永远用 while 循环判断条件，不用 if——因为虚假唤醒（spurious wakeup）真实存在，条件可能在 wait 返回时已不成立
• notify() 只唤醒一个线程，若多个消费者等待同一条件，应改用 notifyAll()，否则可能永久挂起其余线程

ConcurrentHashMap 的弱一致性迭代器

你遍历 ConcurrentHashMap 的 keySet 时发现某些刚 put 的键没出现，或者 size() 返回值和实际条目数对不上——这不是 bug，是它为性能做的明确取舍。

立即学习“Java免费学习笔记（深入）”；

• 迭代器不阻塞写操作，因此可能跳过并发插入的元素，也可能重复看到某个元素（取决于具体实现版本），但绝不会抛 ConcurrentModificationException
• size() 在高并发下返回估算值，因为它需要累加每个 segment 的大小，而中间可能有增删，所以不适合做精确条件判断（比如 “size() == 0” 判空）
• 若需强一致性视图，应改用 Collection.toArray() 获取快照，或换用 Collections.synchronizedMap()（但要自己管理外部同步）

内存一致性的本质不是“让变量立刻可见”，而是“让线程间对共享状态的观察顺序符合同步顺序”。很多问题不是忘了加锁，而是锁的粒度、范围或配对方式没对齐实际的数据依赖关系。