[codex] Java concurrency interview notes

02-java/concurrency/Java 并发.md

@@ -1596,6 +1596,30 @@ JDK 1.6 引入了偏向锁和轻量级锁，从而让锁拥有了四个状态：
 
 - 使用线程池而不是直接创建线程，这是因为创建线程代价很高，线程池可以有效地利用有限的线程来启动任务。
 
+## 面试补充：JUC 并发问题回答框架
+
+Java 并发题建议按“线程安全目标、同步工具选择、可见性与有序性、排障证据”来回答，避免只背 API 名称。
+
+### synchronized 与 ReentrantLock
+
+`synchronized` 是 JVM 内置监视器锁，语法简单，适合普通互斥场景。`ReentrantLock` 基于 AQS，支持可中断、超时、公平锁和多个 `Condition`，适合需要精细控制等待、唤醒和取消的场景。多数业务优先选择简单方案，只有在确实需要高级能力时再使用显式锁。
+
+### volatile 的边界
+
+`volatile` 解决可见性和有序性，不保证复合操作的原子性。它适合停止标志、状态发布、双重检查单例等“一写多读”场景。像 `i++`、库存扣减、余额变更这类读改写操作，仍然需要锁、原子类或数据库约束兜底。
+
+### AQS 的理解
+
+AQS 可以概括为 `state + CAS + 等待队列 + park/unpark`。自定义同步器只需要定义资源获取和释放规则，线程排队、阻塞、唤醒由 AQS 统一处理。`ReentrantLock`、`Semaphore`、`CountDownLatch`、`ReentrantReadWriteLock` 都可以用这个模型解释。
+
+### 死锁排查
+
+死锁排查先用 `jstack` 或线程 dump 找到线程持有的锁和等待的锁，再还原“线程 A 等 B、线程 B 等 A”的闭环。修复方向通常是统一加锁顺序、缩小锁范围、避免锁内调用外部服务，并给复杂锁竞争加超时或降级策略。
+
+### 并发设计取舍
+
+面试回答最后要落到取舍：低竞争场景重可读性，高竞争场景重锁粒度和数据结构；读多写少可用读写锁或不可变快照；跨 JVM 并发不能只靠本地锁，要结合分布式锁、数据库唯一键、版本号或消息幂等。
+
 ---
 
 <!-- note-nav:start -->