Java多线程面试题及答案解析

Java多线程面试绝非考察概念背诵，而是深度检验实战能力——从wait()为何必须在synchronized块中调用、ConcurrentHashMap在JDK8如何通过CAS与单桶锁实现高效并发，到线程池拒绝策略如何选才能防雪崩、ThreadLocal因弱引用key与强引用value引发的隐蔽内存泄漏，每一个知识点都直指真实开发中踩过的坑和调过的bug；真正拉开差距的，是你是否写过多线程代码、是否在高并发场景下定位过伪共享、重排或死锁问题——面试官问得越细，越想确认你手上有“温度”的经验，而非纸上谈兵。

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，看似“及时止损”，但在高可用服务中反而容易引发雪崩：上游重试 + 拒绝堆叠 → 更多拒绝。

• 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。

终于介绍完啦！小伙伴们，这篇关于《Java多线程面试题及答案解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！