1. 多线程面试到底在考什么这两年带过不少校招同学也做过几次社招面试官。聊到Java并发这块我发现很多人有个误区觉得JUC就是背几个类名、记几个参数比如CountDownLatch怎么用、线程池的拒绝策略有哪几种。结果一到面试官追问“为什么这样设计”“底层是怎么做的”就卡住了。实际上Java多线程面试真正想考察的不是你会不会用API而是你有没有建立一套完整的并发思维模型。说得直白一点就是三个问题多线程会带来什么问题、Java提供了哪些手段解决、这些手段各自的适用场景和底层原理是什么。把这三点吃透了面试题怎么变你都能接住。这篇内容没有按照教科书顺序罗列知识点而是以我实际面试和被面试过程中总结的主线来展开先从并发问题的根源讲起再逐个拆解Java里解决这些问题的手段最后落到线程池和面试高频题上。整篇内容围绕Java八股里JUC并发编程类的核心考点适合正在准备Java面试的同学也适合工作中需要用多线程但对细节还不那么笃定的开发者。2. 并发问题的根源为什么多线程这么难2.1 从进程到线程为什么需要多线程在聊并发问题之前先理清楚一个基础概念进程和线程的关系。进程是操作系统分配资源的基本单位每个进程有独立的内存空间线程是CPU调度的基本单位同一个进程里的线程共享进程的内存空间。很多人会问既然进程已经能并发执行为什么还要搞线程答案很直接线程的创建和切换成本远比进程低。进程切换需要切换页表、刷新TLB开销很大线程切换只需要保存和恢复寄存器、程序计数器这些上下文信息。另外线程之间共享内存通信成本低。这也是为什么像Tomcat这样的Web容器每个请求都会丢给一个线程去处理——如果每个请求都开一个进程机器早就扛不住了。不过共享内存是一把双刃剑。它带来了高效的通信方式也带来了并发编程最让人头疼的问题多个线程同时访问共享数据时可能会出现数据不一致。2.2 三大问题原子性、可见性、有序性并发编程的三大问题要背熟这不是简单的八股而是后续理解JUC所有工具的钥匙。原子性问题指的是一个操作或者多个操作在CPU执行过程中不能被中断。经典例子就是i它看起来是一行代码但编译成字节码后是三步读取i的值、计算i1、写回i。两个线程同时执行i最终结果可能比预期少1。一个线程在读和写之间另一个线程插了进来数据就乱了。可见性问题是CPU缓存导致的。现代CPU有多级缓存每个核心有自己的L1、L2缓存。线程A修改了一个变量的值这个值可能还在L1缓存里没刷回主内存线程B从主内存读到的还是旧值。这就相当于两个人在同一个记事本上写东西但各看各的小抄谁也不刷新。有序性问题源于编译器或者CPU为了优化性能会对指令进行重排序。在单线程下重排序不会影响执行结果但多线程下线程A的指令重排序可能会导致线程B观察到不符合预期的事件顺序。经典的例子就是双重检查锁里的new Singleton()如果对象引用赋值和对象初始化被重排序了另一个线程可能拿到一个半初始化的对象。2.3 用生活场景理解并发问题并发问题听着抽象我习惯用银行柜台来类比。想象一个银行只有一个账户余额记录本多个柜员同时办理业务。原子性问题就是两个柜员同时读到余额1000一个要存500一个要取300如果两者都按自己读到的旧值计算最终余额就错了。可见性问题就是一个柜员修改了余额但没有及时更新公共记录本另一个柜员还在用旧余额。有序性问题就是柜员办理业务的步骤被重新安排了比如先盖章再核对金额中间如果被打断就会出现空档。这个类比能帮你在面试时快速给面试官讲清楚并发问题的本质也让后续理解为什么会引入锁、volatile、CAS这些机制变得顺理成章。3. 线程的生命周期与创建方式3.1 Java线程的六种状态Java线程的生命周期是面试必问基础题。Thread.State枚举定义了六种状态NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。NEW是线程创建后还没调用start()的状态。调用start()之后进入RUNNABLE注意这里RUNNABLE包含了操作系统层面的就绪和运行两种状态Java没做区分。线程在等待获取监视器锁synchronized时进入BLOCKED状态。调用wait()、join()或者LockSupport.park()会进入WAITING这种状态下线程会一直等直到被唤醒。TIMED_WAITING和WAITING的区别是前者有时间参数比如sleep(1000)、wait(5000)。线程执行完run()方法后进入TERMINATED。这里有个高频考点sleep和wait的区别。sleep是Thread的静态方法不释放锁wait是Object的方法调用后会释放锁并进入WAITING状态。很多新手搞混面试时我会建议用一个口诀记sleep抱锁睡wait放锁等。3.2 创建线程的几种方式Java创建线程主要有四种方式继承Thread类、实现Runnable接口、实现Callable接口配合FutureTask、使用线程池。继承Thread类最简单直接但因为Java单继承的限制扩展性差不建议在实际代码里用。实现Runnable接口是更常见的写法把任务和线程分离run()方法没有返回值。需要返回结果时用Callable它的call()方法可以抛异常、可以返回结果配合FutureTask可以获取执行结果。还有个容易忽略的点调用start()和直接调用run()完全是两回事。start()会启动一个新的线程并让JVM去调用run()直接调用run()只是在当前线程里同步执行方法没有新线程。面试官问“为什么不能两次调用start()”本质就是追问线程状态机——第二次调用start()会抛出IllegalThreadStateException因为线程已经不在NEW状态了。3.3 生产中创建线程的默认选择实际开发中不要直接new Thread去做异步任务这是铁律。原因很简单频繁创建和销毁线程开销大而且无法控制并发数量极端情况下可能撑爆内存。生产中一律使用线程池来管理线程池化思想既减少创建销毁的开销又能做资源隔离和限流。不过你如果回答“线程池是唯一选择”面试官可能会追问那为什么JDK还保留new Thread的方式其实线程池本身也依赖Thread来承载任务new Thread是基础能力只是工程上不建议直接使用。回答到这个层次面试官对你的理解深度会有一个不错的印象。4. 锁机制解决原子性的核心手段4.1 synchronized的演进与底层原理synchronized是Java内置的锁用法简单但底层原理值得深挖。在JDK 1.6之前synchronized是重量级锁每次竞争都会涉及操作系统级别的互斥性能很差。1.6之后引入了偏向锁、轻量级锁、自旋锁等优化机制锁的升级路径是无锁 → 偏向锁 → 轻量级锁 → 重量级锁。偏向锁的思想是同一个线程反复进入同步块时不再每次做CAS抢锁而是直接记录线程ID。如果只有一个线程访问偏向锁几乎没有额外开销。当有第二个线程竞争时偏向锁撤销并升级为轻量级锁。轻量级锁通过CAS尝试在对象头中替换锁记录如果竞争加剧、CAS失败达到一定次数就升级为重量级锁进入阻塞状态。synchronized锁的是对象不是代码。普通同步方法锁的是this对象静态同步方法锁的是Class对象同步代码块锁的是括号里指定的对象。理解了这一点才能定位死锁和锁竞争的问题。有个经典陷阱两个线程分别调用同一个对象的不同synchronized方法是互相阻塞的因为它们竞争同一把this锁。4.2 Lock接口与AQSsynchronized虽然好用但功能不够灵活不能响应中断、不能超时获取锁、非公平锁不可控。JDK 1.5开始提供Lock接口最常用的实现是ReentrantLock。ReentrantLock支持公平锁和非公平锁默认是非公平锁。公平锁按照线程到达顺序获取锁代价是线程切换开销更大非公平锁允许插队吞吐量更高。实际工作中除非对公平性有硬性要求否则都用非公平锁。ReentrantLock的底层是AbstractQueuedSynchronizer简称AQS。AQS是整个JUC的基石CountDownLatch、Semaphore、ReentrantReadWriteLock全是基于它实现的。AQS核心是一个volatile修饰的state状态值加一个CLH变体队列。以ReentrantLock为例state为0表示锁未被持有线程通过CAS把state从0改成1表示获取锁成功已持锁线程重入时state加1释放锁时state减1减到0才真正释放。面试时AQS这个问题我建议从三个维度回答state状态位、双向等待队列、模板方法模式。模板方法模式是指AQS定义了acquire、release等模板流程把tryAcquire、tryRelease这些具体实现留给子类。这个设计非常经典值得单独夸一下。4.3 CAS无锁并发的基石CASCompare And Swap是乐观锁思想的核心实现。它的操作包含三个值内存位置V、预期原值A、新值B。执行CAS时只有当前内存值和预期值A相等才把内存值更新为B否则什么都不做。整个操作是原子的由CPU指令保证。JUC里的原子类AtomicInteger、AtomicLong都是基于CAS实现的。相比synchronizedCAS避免了线程阻塞和唤醒的开销在竞争不激烈时性能很好。但CAS有三个问题需要掌握ABA问题、自旋消耗CPU、只能保证单个共享变量的原子性。ABA问题是指一个值从A变成B再变回ACAS检查时发现还是A就认为没变过实际上中间经历变化。解决方式是使用AtomicStampedReference通过版本号判断。自旋问题是指竞争激烈时CAS反复失败CPU空转可以在失败后让线程让步。单变量限制意味着不能对多个变量同时做CAS只能配合synchronized或把它们封装成对象。4.4 死锁的产生与排查死锁在并发编程里是必考实操题。经典场景是线程A持有锁1等待锁2线程B持有锁2等待锁1两个线程互相等待谁也释放不了。排查死锁我常用的工具是jstack。先用jps找到Java进程ID然后执行jstack 进程ID输出里会明确显示Found one Java-level deadlock并列出两个线程的堆栈信息、当前持有的锁、正在等待的锁。在实际运行环境中定位死锁这一套操作是基本功。避免死锁有几个思路加锁顺序要一致使用tryLock超时释放尽量减少锁的持有时间能用无锁方案就优先用无锁。面试时如果能结合一次实际排查经历来回答会比单纯背八股好很多。5. volatile与JMM解决可见性和有序性5.1 volatile的两个语义volatile是Java中最轻量的同步机制它有两个核心语义保证共享变量的可见性、禁止指令重排序。可见性方面volatile变量在写操作时会强制把当前线程工作内存中的值刷回主内存读操作时会强制从主内存读取而不是从缓存读。这相当于给变量加了一个“实时同步”的约束。有序性方面volatile通过内存屏障阻止指令重排序JMM在volatile读和写前后插入内存屏障确保不会出现越序执行。但volatile不保证原子性这是面试最容易考的点。经典的volatile int count配合多个线程执行count最终结果依然可能出错因为count不是原子操作。volatile解决的是单次读写的可见性问题解决不了复合操作的原子性问题。5.2 JMM内存模型与happens-before规则JMMJava内存模型规定了所有变量的读写都在主内存进行每个线程有自己的工作内存线程之间的变量传递必须经过主内存。这个模型和计算机组成原理里的CPU缓存模型是呼应的理解起来不难。JMM定义了一套happens-before规则用来判断两个操作是否会对彼此可见。核心规则包括程序顺序规则一个线程内的前序操作happens-before后续操作、监视器锁规则解锁happens-before后续加锁、volatile变量规则写volatile happens-before后续读同一个volatile、传递性规则等。happens-before规则的意义在于它不是要求两个操作必须在时间上有先后而是要求前一个操作的结果对后一个操作可见。这个语义一定要在面试时表达清楚很多人把happens-before误解成时间先后关系一开口就露馅。5.3 synchronized和volatile怎么选有人问既然synchronized什么都能干为什么还要用volatile答案在开销。synchronized会涉及锁的获取、竞争、释放重量级操作volatile不会阻塞线程开销很小。选择依据很简单只要求可见性、不要求原子性的场景优先用volatile。典型例子是状态标志位比如线程的停止标志。要求原子性的场景用synchronized、Lock或者Atomic类。另外需要注意如果多个线程同时读写变量volatile是不够的必须加锁。6. 线程池生产环境多线程的正确打开方式6.1 线程池核心参数详解线程池是面试中的重头戏其中ThreadPoolExecutor的七大参数是必背项corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime空闲线程存活时间、unit时间单位、workQueue任务队列、threadFactory线程工厂、handler拒绝策略。核心线程数设置多少合适网上说法很多。我的建议是结合任务类型区分CPU密集型任务核心线程数设为CPU核心数1因为这类任务主要是计算线程太多反而频繁切换降低效率IO密集型任务核心线程数可以设为CPU核心数乘以2左右因为线程大部分时间在等待IO可以多开一些线程让CPU充分利用。当然这只是经验值线程数没有绝对最优解需要压测调优。队列的选择也很有讲究。LinkedBlockingQueue默认无界队列可能导致任务无限堆积、内存暴涨ArrayBlockingQueue有界队列更安全配合拒绝策略使用。SynchronousQueue不存储任务直接把任务交给线程执行适合任务量小但要求低延迟的场景。6.2 线程池执行流程线程池的执行流程是一个高频面试题必须能把完整链路讲清楚。当提交一个任务时流程如下线程池中的线程数小于corePoolSize创建新线程执行任务。线程数已大于等于corePoolSize任务放入阻塞队列等待。队列已满且线程数小于maximumPoolSize创建新线程执行任务。队列已满且线程数已达到maximumPoolSize执行拒绝策略。这里有个反直觉的点线程池是先填队列再扩线程到maximumPoolSize而不是一开始就创建到最大线程数。很多人理解成“先扩线程再填队列”面试时容易说反。6.3 四种拒绝策略怎么选JDK提供了四种拒绝策略AbortPolicy直接抛出RejectedExecutionException默认策略CallerRunsPolicy由调用者线程执行任务DiscardPolicy直接丢弃任务不抛异常DiscardOldestPolicy丢弃队列中最旧的任务。选择策略需要考虑业务容忍度。不允许丢弃任务的场景用CallerRunsPolicy让提交任务的线程自己执行起到一种背压效果同时也保证任务不丢。AbortPolicy会在任务提交失败时报错适合让开发者尽快感知问题的场景。Discard系列要谨慎使用容易造成任务静默丢失。6.4 Executors框架的坑阿里巴巴开发规范明确禁止使用Executors创建线程池这个点面试必聊。Executors提供了几个便捷方法但都有隐患。newFixedThreadPool和newSingleThreadExecutor用的是无界LinkedBlockingQueue任务堆积会耗尽内存newCachedThreadPool最大线程数是Integer.MAX_VALUE极端情况下会创建大量线程导致OOM。正确做法是通过ThreadPoolExecutor显式构造设置合理的队列大小和拒绝策略。7. JUC并发工具类实战7.1 CountDownLatch与CyclicBarrierCountDownLatch和CyclicBarrier是一对容易混淆的工具。CountDownLatch是一个计数器一个或多个线程等待其他线程完成操作。典型场景是主线程等待所有子线程执行完再继续。它的计数器只能递减不能重置是一次性的。CyclicBarrier是让一组线程互相等待直到所有线程到达屏障点后再继续执行。和CountDownLatch的区别在于CyclicBarrier是线程彼此等待计数器可以循环使用。举个例子多线程并发查询多个接口数据全部查完后汇总这个场景用CountDownLatch合适。多个线程按阶段执行任务比如分阶段并行计算每一阶段所有线程都完成后再进入下一阶段用CyclicBarrier。7.2 Semaphore与限流Semaphore是信号量用来控制同时访问某个资源的线程数量。构造时可以传入许可数线程通过acquire()获取许可release()释放许可。没有许可时acquire会被阻塞。实际开发中Semaphore常用在接口限流场景。比如一个服务同时只能处理10个请求超过的请求等待就可以用Semaphore(10)来控制。和RateLimiter的区别是RateLimiter是匀速限流Semaphore是控制并发数量两者的保护维度不同。7.3 ConcurrentHashMap为什么高效ConcurrentHashMap是JUC容器里最典型的代表。JDK 1.8之后它放弃了分段锁改用CAS synchronized方案。数组元素上使用volatile保证可见性插入数据时如果目标位置为空直接用CAS插入不用加锁如果目标位置非空对数组元素加synchronized锁锁粒度非常细。面试时对比HashMap和ConcurrentHashMap要能说出来HashMap线程不安全HashTable用全局锁并发度低ConcurrentHashMap高并发高效是因为锁粒度细、CAS无锁操作、扩容时支持并发迁移。再深一点可以聊扩容时的高并发设计、计数用的LongAdder思想这些细节能体现你对源码的熟悉程度。8. 面试高频题实录与避坑指南8.1 线程间通信的几种方式这个问题考察的是你对线程协作工具的了解程度。我通常会分几层来回答最基本的synchronized配合wait、notify实现等待通知机制ReentrantLock配合Condition实现更灵活的等待与唤醒volatile变量作为信号CountDownLatch、CyclicBarrier、Semaphore等工具实现更高级的协作模式线程池配合Future或CompletableFuture实现异步编排。8.2 为什么wait必须在synchronized块里调用这个细节很多人忽略但面试官喜欢追问。wait()方法的语义是释放锁并等待前提是当前线程持有了该对象的监视器锁。如果没有在synchronized里调用wait()会抛出IllegalMonitorStateException。更深一层的原因是wait和notify需要基于共享的监视器状态来协作如果允许在没有任何锁保护的情况下调用wait就无法保证条件检查的原子性会出现信号丢失问题。这种底层设计问题回答的时候如果能主动提到“防止lost wakeup”面试官会眼前一亮。8.3 CompletableFuture的异步编排实战现在的Java开发已经离不开CompletableFuture了它是JUC里最实用的异步编程工具。核心方法包括supplyAsync提交有返回值的异步任务、thenApply串行转换结果、thenCompose合并CompletableFuture、thenCombine组合两个独立任务的结果、allOf等待所有任务完成、anyOf任意一个任务完成。实际项目中我有一个很深的体会CompletableFuture的异步编排非常强大但要注意线程池的选择。如果不指定线程池它会使用ForkJoinPool.commonPool而这个池是全局共享的一旦任务阻塞会影响整个JVM里其他使用commonPool的地方。规范做法是自定义线程池传进去。8.4 多线程调试与性能排查建议多线程问题排查比单线程难很多我分享一下自己的经验。排查多线程性能问题先看CPU使用率使用top命令定位高CPU进程再用jstack获取线程堆栈通过线程状态分布判断是锁竞争、死锁还是线程数设置不合理。有一种典型情况线程池里的线程大量处于BLOCKED状态这时候重点看是锁竞争还是IO阻塞。锁竞争的话考虑缩小同步块范围、改用读写锁或无锁方案IO阻塞的话调整线程池大小或者改用异步IO。调试多线程还有一个建议尽量用日志记录线程名和时间戳通过时间线还原执行过程。别指望用断点调试多线程断点会改变线程执行时序反而把问题掩盖了。9. 复习路线与临场发挥建议9.1 八股太多怎么背JUC并发编程这部分知识点密集死记硬背效率很低。我的建议是先建立一个骨架图把并发问题原子性、可见性、有序性作为根节点每个问题对应的解决方案挂上去。原子性对应synchronized、Lock、CAS、原子类可见性对应volatile、final、锁有序性对应volatile、happens-before规则。骨架立住了后面再往里填充细节不容易乱。9.2 面试时怎么回答更出彩这里分享一个面试技巧回答技术问题时不要只给结论要给结论背后的设计取舍。比如面试官问“为什么ConcurrentHashMap比HashTable高效”别急着说“分段锁”或者“CAS”先指出HashTable是全局锁所有操作竞争同一把锁然后说ConcurrentHashMap通过细粒度锁和CAS减少竞争。整个过程体现出你考虑过方案的演进和取舍。还有一个容易被忽略的点敢于承认不知道。JUC里源码非常深面试官有时候会问得很偏比如AQS的条件队列实现细节。这时候老实说“这块我还没深入看但我了解它的设计思路”同时把你懂的部分讲清楚比硬编一个错误答案好得多。我在实际带团队的过程中有一个体会并发编程的八股不能完全靠背一定要在工作中动手写。哪怕是写一个简单的多线程下载工具、一个线程池包装类都能帮你把抽象的概念具象化。面试复习到后期我通常建议把多线程相关的每个工具类都亲手写一个小demo跑一遍感受一下线程交互的过程。很多东西看着懂了和真正跑通了中间差着十万八千里。