Java多线程面试重在实战经验而非背诵；wait()必须在synchronized块中调用，否则抛IllegalMonitorStateException；ConcurrentHashMap JDK8用CAS+单桶锁替代分段锁；线程池拒绝策略中CallerRunsPolicy更防雪崩；ThreadLocal内存泄漏因key弱引用而value强引用未及时清理。
Java多线程面试题不是考背诵，而是考你有没有真正写过多线程代码、踩过坑、调过问题。光知道 synchronized 和 volatile 的定义，答不对真问题。
为什么 wait() 必须在 synchronized 块里调用？
这不是语法限制，而是语义强制：只有持有对象锁的线程才能进入等待队列。否则会抛 IllegalMonitorStateException。JVM 需要确保线程在释放锁前已“登记”进该对象的等待集，否则唤醒逻辑会错乱。
- 常见错误：在
if判断后直接wait()，没加synchronized—— 编译不报错，运行必崩 - 正确写法必须是：
synchronized(obj) { if (!condition) obj.wait(); } -
wait()会原子性地释放锁 + 挂起；而sleep()不释放锁，也不能被notify()唤醒
ConcurrentHashMap 在 JDK 8 中如何避免分段锁？
JDK 8 彻底移除了 Segment，改用 Node 数组 + synchronized 锁单个桶（bin）+ CAS 控制扩容。这意味着读操作完全无锁，写操作只锁冲突的哈希桶，不是整个表。
- 注意
size()不再是 O(1)：它要遍历所有 bin 的计数器求和，可能有轻微延迟 -
computeIfAbsent()是线程安全的，但传入的 mappingFunction 不应在其中修改 map 自身，否则可能死锁 - 如果 key 或 value 为 null，会直接抛
NullPointerException—— 这和HashMap的容忍不同
线程池拒绝策略选哪个？AbortPolicy 真的是最安全的吗？
默认的 AbortPolicy 直接抛 RejectedExecutionException，看似“及时止损”，但在高可用服务中反而容易引发雪崩：上游重试 + 拒绝堆叠 → 更多拒绝。
立即学习“Java免费学习笔记（深入）”；
-
CallerRunsPolicy更适合突发流量：让提交线程自己执行任务，自然降速，避免队列爆炸 - 自定义策略时，别只打日志——要考虑是否要落盘、告警、或降级返回默认值
- 注意
ThreadPoolExecutor构造参数顺序：corePoolSize、maxPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler —— 错一位就可能创建出不符合预期的池
为什么 ThreadLocal 可能导致内存泄漏？
根本原因是 ThreadLocalMap 中的 key 是弱引用（WeakReference），value 是强引用。当 ThreadLocal 实例被回收后，key 变为 null，但 value 仍被 map 持有，且该 entry 无法被自动清理，除非线程执行下一次 get()/set() 触发探测式清理。
- Web 应用中最典型场景：用
ThreadLocal存用户上下文，但 Filter 中没调remove()，线程被 Tomcat 复用后，旧请求的 value 一直残留 - 最佳实践：每次使用完务必显式调用
threadLocal.remove()，尤其在线程池环境 - 不要把大对象塞进
ThreadLocal，比如StringBuilder或缓存 Map —— 它们生命周期由线程决定，不受 GC 正常控制
多线程的复杂性不在概念，而在状态交织与时机依赖。哪怕一行 count++，背后可能是 CPU 缓存行伪共享、指令重排、JIT 优化干扰 —— 面试问得越细，越说明他们想知道你是不是真 debug 过并发 bug。
