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 # node # app # tomcat # ai # java多线程 # 无锁 # 为什么

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】