2025年Java多线程面试聚焦五类核心：线程状态与生命周期、同步机制选型、线程安全集合辨析、通信协作工具、并发原子类边界条件；需精准理解状态转换逻辑、锁机制差异、集合适用场景及底层原理细节。
2025年Java多线程面试题已高度收敛，核心就考五类问题：线程状态与生命周期、同步机制选型（synchronized vs ReentrantLock）、线程安全集合辨析、通信协作工具（wait/notify、CountDownLatch、BlockingQueue）、以及并发原子类的边界条件。刷题不靠堆量，关键要踩准命题人埋坑的位置——比如“volatile能保证i++线程安全吗？”这种题，答“能”就直接出局。
Thread状态转换不是背名词，是看JVM怎么调度
NEW → RUNNABLE → BLOCKED/WAITING/TIMED_WAITING → TERMINATED 这条主线必须能画出来，但更关键的是知道哪些操作会触发状态跳变：
-
start()后状态变为 RUNNABLE（不是 RUNNING），是否立刻执行取决于OS调度器 -
sleep(100)、wait()、join()都会让出CPU，但sleep()不释放锁，wait()必须在synchronized块里且会释放锁 - BLOCKED 是抢不到 monitor 锁（如进入
synchronized方法），WAITING 是主动让出（如调用Object.wait()），别混淆成“等锁”和“等通知” - JDK 9+ 新增
Thread.State.TERMINATED状态，但isAlive() == false才是实际判断依据，别只查状态枚举
ConcurrentHashMap不是“线程安全版HashMap”，它有明确的适用边界
面试官问“为什么不用 Hashtable 或 Collections.synchronizedMap()？”，答案不能只说“性能好”。得点出分段锁（JDK 7）→ CAS + synchronized（JDK 8）的演进，以及它不支持 contains()（已废弃）、size() 是弱一致性（可能不准）这些实操陷阱：
-
computeIfAbsent()是线程安全的，适合缓存场景；但get() + put()组合一定非线程安全，必须用原子方法替代 - 遍历时若其他线程修改，不会抛
ConcurrentModificationException，但可能漏读新 entry —— 这是设计取舍，不是 bug - 高并发写场景下，
LongAdder比AtomicLong更优，因后者在争抢激烈时自旋开销大
ReentrantLock 和 synchronized 的选择，看的是“可中断”“可超时”“可公平”这三把尺子
光说“ReentrantLock 功能更全”没用。面试官想听你权衡：
- 需要响应中断？用
lockInterruptibly()，synchronized无法做到 - 怕死锁卡死？用
tryLock(long, TimeUnit)设超时，失败可回退，synchronized只能干等 - 业务要求严格按请求顺序获取锁？开启公平模式（
new ReentrantLock(true)），但吞吐量明显下降 - 普通临界区保护、无特殊需求，优先用
synchronized：JVM 优化成熟、代码简洁、不易漏unlock()
CountDownLatch 和 CyclicBarrier 别记反了，关键看“谁等谁”
两者都用于线程协作，但语义相反：
-
CountDownLatch是“一等多”：主线程await()等待多个子任务完成（countDown()），计数归零后不可重用 -
CyclicBarrier是“多等多”：所有线程都到达屏障点才一起放行，可重复使用，适合分阶段并行计算 - 误用
CountDownLatch实现“所有线程启动后再一起干活”，会导致主线程提前 await 结束，子线程还没 start —— 正确做法是加一层CyclicBarrier或用Phaser -
CountDownLatch(1)常被当信号量用，但注意它不控制并发数，Semaphore才是正解
真正拉开差距的，不是背出“线程有六种状态”，而是能讲清 park()/unpark() 怎么绕过 wait() 的锁依赖，或者为什么 ThreadLocal 不清理会导致内存泄漏——这些细节，才是面试官翻你简历前最后扫一眼的地方。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
