Java多线程面试题及答案 2025年Java并发高频面试题汇总【面试】_技术教程

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 才是正解