Java多线程面试题解析与解答

一分耕耘，一分收获！既然打开了这篇文章《Java多线程面试题大全及解析》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

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

• 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学习网公众号，带你了解更多关于的知识点！