Java面试Day14：并发编程核心冲刺与实战排查指南

如果你正在准备Java面试，看到“Day14”这个编号就该明白，这不是零基础入门课，而是一整条八股复习路线中的关键节点。很多人的计划是Java基础、集合、JVM、并发一路推进，真正拉开差距的地方往往就在并发编程。前面语法和集合题大家都会背，到了并发，面试官随便追问两三轮就能看出你是真懂还是背答案。

Day14我给自己安排的是并发专题：JMM与volatile、synchronized锁升级、CAS与AQS、线程池、死锁排查，这一套几乎是面试官最爱从浅到深层层追问的路径。无论你面的岗位偏业务还是偏中间件，并发都属于必考区域，而且高频追问点相当集中。这篇文章把这一天我踩过的坑、总结出的答题思路、以及实测过的排查命令都整理出来，适合正在冲刺校招或准备跳槽、需要系统过一遍并发核心知识的朋友直接参考。

1. Day14为什么要安排成并发专题

1.1 复习路线中的位置逻辑

前13天如果按常规节奏走，通常已经覆盖了Java基础语法、集合类源码、JVM内存与垃圾回收、Spring、MySQL这些模块。到达Day14时，其实已经具备了理解并发知识的两块关键地基：一是JVM的对象布局知识，因为synchronized锁升级和对象头强相关；二是操作系统层面的线程模型知识，因为锁竞争、上下文切换这些概念都建立在上面。

把并发安排在这个位置是有道理的。没有对象头知识，谈锁升级就是空中楼阁；没有操作系统概念，谈重量级锁为什么慢就缺乏依据。但反过来，并发又是后续看各种框架源码的钥匙，像是Netty的EventLoop、Tomcat的线程池配置，理解起来全都依赖并发基础。所以放在中间偏后的位置，既顺理成章又能承上启下。

1.2 并发在面试中的权重分布

从面试考察频率来看，并发编程基本稳居前二，和JVM并列。具体到高频考点，无非五类：可见性与volatile、synchronized与锁升级、CAS与AQS、线程池、并发容器。而Day14如果只选一个主线，我认为应该把“锁与线程池”打透，因为这两个方向最容易考到场景设计题，比如“你这个服务里线程池怎么配的”“这段并发代码有没有问题”。

面试官常用的一种套路是抛出一个看似简单的问题，比如“volatile能保证原子性吗”，然后顺着可见性一路问到指令重排、内存屏障、单例模式，再切到synchronized的锁升级。也就是说，这五类考点不是孤立的，它们共同构成一条逻辑链。Day14要做的事情，就是把这条链子串起来，而不是零散地背几个知识点。

1.3 今天的时间分配建议

我建议把复习时间切成三块：上午主攻JMM和volatile，连带把synchronized锁升级过一遍，因为这两块内在逻辑是连续的；下午集中精力研究CAS、AQS和线程池，重点理解执行流程和参数意义；晚上拿一台Linux服务器实际跑一遍死锁排查命令，再整理一份自己的易错点清单。这样安排的好处是，原理理解和动手验证能当堂消化，而不是背完就忘。

2. JMM与volatile：从内存模型底层理解可见性

2.1 JMM到底在讲什么

Java内存模型（JMM）是一个抽象出来的规则体系，它规定了共享变量在并发场景下如何在线程间传递。JMM把内存分为主内存和工作内存：主内存是所有线程共享的，存放变量真实值；工作内存是线程私有的，保存了变量的副本。线程对变量的所有读写都先发生在工作内存，再同步回主内存。这里可以用一个生活化类比：主内存像图书馆的正式馆藏，工作内存像每个人手里的读书笔记，你改的是自己的笔记，别人看不见，直到你把笔记内容提交回图书馆才同步。

这种设计带来的直接问题就是可见性。当线程A修改了一个共享变量，还没来得及写回主内存时，线程B正在读自己工作内存里那份旧副本，B读到的就是脏数据。CPU缓存、指令重排还会放大这个问题，但JMM层面的核心矛盾就是工作内存与主内存的不一致。

2.2 happens-before规则是解题钥匙

面试官问可见性时，经常搬出happens-before规则来考察。JMM规定了八条规则，面试最常见的是前几条：程序顺序规则，也就是单线程内代码的先后顺序；锁规则，解锁操作先行发生于加锁操作；volatile规则，对一个volatile变量的写先行发生于后续对该变量的读；传递性，A先行于B、B先行于C，则A先行于C。

这里有个容易忽略的细节：happens-before只保证时间可见性，不保证实时性。它说的是“如果操作A先行发生于操作B，那么A的结果对B可见”，而不是说A一定在物理时间上先执行完。理解这一点，比死记八条规则更重要，因为很多面试追问都围绕“为什么这个操作不需要加锁也能看到结果”展开。

2.3 volatile的两个核心语义

volatile有两个核心语义：可见性和禁止指令重排。先说可见性，volatile变量的读写直接穿透工作内存，读操作从主内存拿最新值，写操作立即刷回主内存。再说禁重排，编译器、CPU和JIT都可能对指令顺序进行优化，volatile通过内存屏障限制了重排边界。

但volatile不能保证原子性。典型例子就是count++，它其实是一条复合指令：读count、加1、写回count。三个步骤之间完全可以被线程切换打断，volatile只保证了一头一尾的可见性，中间的复合操作依然可能丢更新。我在模拟面试时问过很多人，能答出“volatile不能保证原子性”的不少，但能举出count++这种例子并且说清三个步骤的，明显就靠谱多了。

2.4 双重检查锁单例中的volatile

双重检查锁单例是最经典的volatile应用场景。很多人会背“单例要加volatile”，但被问到“为什么”时容易卡壳。关键点在于new对象不是一个原子操作，它可以分解为三步：分配内存、初始化对象、把引用指向内存地址。如果不加volatile，第三步可能被重排到第二步之前，另一个线程在第二步还没执行时，就已经看到引用非空，直接拿去用，就会拿到一个半初始化对象。

public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } }

这个场景里，volatile起的是禁止指令重排的作用，而不是保证可见性，因为synchronized已经保证了可见性。能分清这一层，面试官基本就会觉得你是真懂，而不是背了标准答案。

3. synchronized锁升级与Monitor：把锁的成长路径讲透

3.1 synchronized的字节码视角

synchronized在字节码层面的表现，是一对monitorenter和monitorexit指令。进入时获取对象监视器锁，退出时释放。编译器会在正常退出和异常路径上都生成monitorexit，保证锁必然释放。但真正让面试有深度的是锁升级这整条链路。

早期JDK的synchronized直接依赖操作系统的互斥量实现，线程一旦竞争锁失败就进入内核态阻塞，线程切换成本极高。所以JDK后续版本不断优化，才演进出无锁、偏向锁、轻量级锁、重量级锁这条升级路径。面试里常见的问法就是“synchronized从无锁到重量级锁，分别对应什么场景”。

3.2 四态演进与对象头

锁的状态存储在对象头里的Mark Word中。无锁状态时，对象头记录的是对象哈希码等内容；一旦开始有竞争，Mark Word里的字段会根据状态切换。整个过程我在复习时画过一遍，文字描述大概是这样的：

第一态是无锁，不管竞争，普通对象进入时就是这个状态。第二态是偏向锁，JDK认为大部分锁不存在多线程竞争，可能同一个线程反复进出同步块，所以让第一个获取锁的线程把线程ID记录到Mark Word里，下次再进入时直接校验线程ID相同，就不再做同步操作，这是“偏向”的含义。第三态是轻量级锁，当第二个线程来竞争时，偏向锁会撤销，而新线程会尝试用CAS把对象头中的锁记录替换成自己线程栈中的锁记录，如果成功就拿到锁；多个线程交替执行、没有真正同时竞争时，轻量级锁够用。第四态是重量级锁，一旦多个线程真正同时竞争、CAS自旋失败，锁就膨胀为重量级锁，后续竞争的线程会被挂起，进入内核态等待唤醒。

这里容易忽略一个细节：偏向锁也不是永远偏向。如果对象计算过identity hashcode，就无法进入偏向状态；如果多个线程交替竞争但始终没有同时抢，轻量级锁可能反复获取释放，系统会有一个阈值决定是否升级。另外，从JDK 15开始偏向锁默认被废弃，JDK 17也默认关闭。复习时如果只按JDK 8的标准答案回答，遇到面试官追问“最新版本有什么变化”就容易露馅。

3.3 锁消除与锁粗化

除了锁升级，JVM还做了两个编译期优化。锁消除指的是，JIT分析发现某个锁对象只被当前线程访问，根本不存在竞争，就直接把锁去掉。锁粗化是指把相邻的多次加锁解锁合并成一次，减少锁操作开销。典型反面例子，是把StringBuffer的append调用放在一个很紧的循环里，每次都新建局部StringBuffer，JVM如果分析出锁不会跨线程共享，会做锁消除，但如果不消除，锁粗化也会减少重复进入同步块的次数。

// 错误示范：循环内频繁创建局部锁对象 for (int i = 0; i < list.size(); i++) { StringBuffer sb = new StringBuffer(); sb.append(list.get(i)); } // 正确思路：把临界区操作合理合并，避免频繁同步

面试里遇到锁优化的问题，能答出锁消除和锁粗化，说明你对“锁的代价”有概念，而不是只会背四态升级。

3.4 synchronized回答要点总结

面试官问synchronized时，我会建议按三条线组织答案：第一，说清它的作用，保证原子性、可见性和有序性；第二，讲清楚锁升级的完整路径以及每态适用场景；第三，补一句锁优化手段。这样一套组合拳下来，覆盖了从原理到JVM优化的多个层次，基本能应对后续追问。别一上来只说“synchronized是重量级锁”，那已经是过时认知，而且会让面试官觉得你停留在背题阶段。

4. CAS、AQS与ReentrantLock：并发工具的地基

4.1 CAS原理与ABA问题

CAS（Compare And Swap）是一条原子指令，语义是：如果内存中的当前值等于预期值，就把它更新为新值，否则什么都不做。整个过程不可被打断，比单纯用synchronized做复合操作更轻量。像AtomicInteger的incrementAndGet，底层就是循环CAS：不断读取当前值，计算加一后的值，再尝试CAS，失败就重试。

CAS有一个广为人知的隐患叫ABA问题：线程A读到值是1，线程B把1改成2又改回1，线程A再执行CAS时发现值还是1，就认为没有动过，实际中间经历了变化。解决思路是引入版本号，AtomicStampedReference就是这么做的，比较时不仅比较值，还比较戳记。

还有一点值得注意，CAS自旋在竞争激烈时会导致CPU空转。所以Java里又出现LongAdder，它把热点value拆成多个cell，每个线程散列到不同cell上操作，求和时把所有cell相加。这个思路在面试里经常作为“CAS自旋开销怎么缓解”的延伸答案。

4.2 AQS的设计思想

AQS（AbstractQueuedSynchronizer）是Java并发包的灵魂。它的核心是两个东西：一个volatile int state，表示同步状态；一个双向等待队列，存放竞争失败的线程。ReentrantLock、Semaphore、CountDownLatch都建立在它之上。面试里如果被问到“AQS怎么实现”，基本就说这三件事：state的语义由子类定义，加锁就是通过CAS把state从0改成1，获取失败就生成节点入队，然后调用LockSupport.park挂起线程；释放锁时唤醒队首节点。

为什么state设计成int而不是boolean？因为要支持可重入。ReentrantLock同一个线程可以多次加锁，每加一次state就自增，释放时自减，减到0才算真正释放。这个设计非常巧妙，用一个int同时完成了“是否占用”和“重入次数”两个功能。我复习时用了一个类比：state像餐厅领的等位号，0代表没人占座，大于0代表坐了人，数值大小代表同一拨人占了几张相邻的凳子。

4.3 公平锁与非公平锁的差别

ReentrantLock有两种模式，差别在AQS的lock入口处。非公平锁在新线程来竞争时，会先尝试直接CAS修改state，成功就直接插队拿锁；公平锁则不允许插队，先检查队列里有没有前驱节点，有就老老实实入队。非公平锁的性能通常更好，因为减少了线程唤醒的上下文切换，但它可能导致队首线程饥饿等待。

我在实际学习时写过一个对比代码来加深记忆：同样五千次循环，两个线程各拿一把锁做累加，公平锁的耗时明显更高。原因就是公平锁频繁唤醒队首线程，而非公平锁允许后来的线程在锁刚好释放时立即抢到。面试官问“为什么非公平锁性能更好”，能说出“减少上下文切换和线程唤醒”这一点，就算答到点子上了。

4.4 ReentrantLock使用中的典型坑

ReentrantLock要求手动加锁和释放，最容易踩的坑就是忘记在finally里unlock。一旦某个分支抛异常提前返回，锁就永远不释放，最终导致其他线程全部阻塞。另外，lockInterruptibly可以在等待锁时响应中断，而lock()不响应中断，这个区别在面试里有时会被问，面试者容易搞混。我的经验是，凡是手动锁场景，第一件事就是把unlock放进finally，形成肌肉记忆，然后再考虑业务逻辑。

ReentrantLock lock = new ReentrantLock(); lock.lock(); try { // 业务逻辑 } finally { lock.unlock(); }

5. 线程池：面试必考，也是线上事故高发地

5.1 线程池解决的本质问题

线程池解决的三个核心问题：减少线程创建和销毁的频繁开销、控制并发数量避免资源耗尽、提供统一的任务调度和生命周期管理。池化思想在很多地方都有体现，连接池、对象池都是同一个道理——复用昂贵资源。

面试从“为什么用线程池”切入，基本都会延伸到三大块：参数含义、执行流程、拒绝策略。这三块必须能对着源码说出来，至少要能画出一条完整的execute流程。

5.2 七大参数与执行流程图

ThreadPoolExecutor构造器里有七个参数：corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime非核心线程存活时间、unit时间单位、workQueue任务队列、threadFactory线程工厂、handler拒绝策略。

执行流程是八股中的八股：提交任务时，先判断当前线程数是否小于核心线程数，小于就新建核心线程执行；否则把任务放入工作队列，等待核心线程处理；如果队列满了，再判断线程数是否小于最大线程数，小于就新建非核心线程执行；如果最大线程数也满了，就走拒绝策略。这个顺序面试里经常会拆开追问，尤其爱问“任务什么时候进入队列、什么时候才创建非核心线程”。

这里有个容易答错的一等细节：核心线程在默认情况下不会被回收，除非设置了allowCoreThreadTimeOut(true)；非核心线程在执行完任务后，超过keepAliveTime才会被回收。

5.3 四种拒绝策略怎么选

JDK内置了四种拒绝策略，对比如下：

我最推荐面试里答CallerRunsPolicy，因为它的思想是“让提交者自食其力”，既不会粗暴丢任务，又通过反压自然降低了提交速度，听起来比直接丢任务更有工程味道。

5.4 线程数怎么估算

线程数配置是典型的场景题。CPU密集型任务，一般设置为核心线程数CPU核数+1，因为CPU密集基本不会等待，多一个线程是为了弥补偶尔等待导致的中断停顿。IO密集型任务，因为有大量阻塞等待，可以设置更多线程，常见公式是CPU核数乘以2，或者更精细一点，用“CPU核数 / (1 - 阻塞系数)”，阻塞系数在0.8到0.9之间。

int core = Runtime.getRuntime().availableProcessors(); int max = core * 2; ThreadPoolExecutor pool = new ThreadPoolExecutor( core, max, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000), new ThreadFactoryBuilder().setNameFormat("biz-pool-%d").build(), new CallerRunsPolicy() );

注意队列容量不能无脑设很大。无界队列是很多线上OOM的元凶，因为任务不断堆积，内存不断增长，而线程数永远到不了最大线程数，监控还看不出线程压力。这也是为什么面试里问到Executors，正确答案往往是“不建议使用”，因为newFixedThreadPool和newSingleThreadExecutor用的是无界队列，而newCachedThreadPool最大线程数是Integer.MAX_VALUE，都可能出问题。要回答得漂亮，最好是说“我一般用ThreadPoolExecutor手动构造，根据业务场景定制队列和拒绝策略”。

5.5 线程池关闭和异常处理

优雅关闭线程池用shutdown，它只拒绝新任务，等待已提交任务跑完；shutdownNow会中断正在执行的任务，并且返回还没执行的任务列表。线上经验是尽量用shutdown，给任务留一个软着陆的过程。另外，如果execute提交的任务内部抛了RuntimeException，该线程会被销毁，然后创建一个新线程顶替。这个机制容易被忽视，但它解释了为什么线程池里跑的任务要自己做异常捕获，否则线程会被频繁替换，池子也就失去了稳定性意义。

6. 实战排查：用jstack揪出死锁和CPU飙高

6.1 一个典型死锁演示

我在实验室模拟过一个典型死锁：线程A持有锁1等待锁2，线程B持有锁2等待锁1，两个线程互相等待，谁都不让。写这段代码很简单，关键是观察线程状态和堆栈。

Object lockA = new Object(); Object lockB = new Object(); new Thread(() -> { synchronized (lockA) { try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockB) { System.out.println("thread1 got lockB"); } } }).start(); new Thread(() -> { synchronized (lockB) { try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockA) { System.out.println("thread2 got lockA"); } } }).start();

启动后用jstack查看线程情况，抓重点看最后一段。如果出现类似“Found one Java-level deadlock”的字样，并且把两个线程持有的锁一五一十列出来，那基本就实锤了。我当初第一次看到这个输出时觉得特别有成就感，因为这比单纯背“死锁四个必要条件”来得扎实。

6.2 死锁修复思路

死锁四个必要条件，面试常问；但工程上的修复思路要能落地：要么保证所有线程按固定的全局顺序拿锁，要么用tryLock带超时替代无限等锁。固定顺序是消灭循环等待，tryLock是打破不可剥夺。我在模拟场景里用tryLock(2, TimeUnit.SECONDS)修复后，线程等待超时会主动放弃，然后走降级逻辑，链路就通了。

6.3 CPU飙高定位流程

线上CPU飙高，排查流程基本是固定的三步：先用top找到CPU占用最高的进程PID，再用top -Hp PID找到进程内最耗CPU的线程ID，把线程ID转成十六进制，用jstack PID查这个十六进制的栈，定位到具体业务代码。

top -Hp 12345 printf '%x' 12347 jstack 12345 | grep -A 20 '0x304b'

这个流程我实测过多次，唯一容易卡住的地方是grep过滤的栈信息拼接不完整。正确的做法是多抓几次jstack，对比线程状态是不是一直卡在同一个方法，如果每次都指向同一个私有方法，多半是这里自旋或者有死循环；如果是GC线程占满CPU，就要接着排查堆内存和GC配置。我在某次模拟演练里碰到过正则表达式回溯导致CPU飙高，jstack一抓全是那个正则匹配方法，顺着栈找到代码后改成非贪婪模式就解决了。

6.4 线上并发排查的个人经验

排查并发问题，最忌讳的是凭空猜。我总结的靠谱顺序是：先用命令把现场信息保存完整，再做代码分析。像是jstack、jstat、jmap这些命令，最好提前在测试环境练熟，别等线上出了问题才翻命令手册。另外，线上并发问题往往不是某个类用错了，而是锁粒度太大或线程池配置不合理。我认识一个做电商服务的团队，某次接口变慢，最后定位到是新同事给一个只读缓存操作加了synchronized，直接让所有请求串行化。这种问题，工具只能定位现象，根因还得靠代码审查经验。

7. Day14复盘：易错点速查与冲刺建议

7.1 高频易错点对照表

我把今天复习中容易踩的坑整理成了一张表，方便睡前快速过一遍：

这六条是我在模拟面试里反复听到的错误答案，也是面试官最爱挖的坑。尤其第一条，很多人在volatile上栽跟头，因为背了“可见性、有序性”就默认以为原子性也顺带了。

7.2 自测清单

复习完当天内容，我习惯用几个问题做自测，如果答不上来就说明还要再看一遍：能否不查资料画出锁升级路径并说明每态触发条件；能否解释AQS的state为什么是int而不是boolean；能否说出ThreadPoolExecutor的完整任务流转；能否用jstack定位一个死锁；能否解释volatile在双重检查单例中的作用。这五个问题覆盖了今天的全部核心内容，能流畅答出，基本可以放心进入下一阶段。

7.3 下一步学习衔接

Day14之后，并发部分其实还没到终点，至少还有并发容器、ThreadLocal、锁工具类这些尾巴。但最核心的底层机制今天已经打通。接下来可以根据你的薄弱方向分配：如果项目里大量用到缓存，建议优先深挖ThreadLocal和内存泄漏场景；如果面试公司偏基础架构，建议把AQS再往深看一层，尝试看ReentrantLock源码，把acquire流程里每个条件分支都读明白。我个人不推荐把并发战线拉得太长，两到三天内把今天这张网巩固住，再接数据库和Redis，性价比更高。

我在复习并发这块时，最强烈的感受是：光背结论没有用，一定要把场景挂上去。比如复习锁升级，顺手把对象头的Mark Word画一遍；复习线程池，就想着自己的项目里队列和拒绝策略是怎么配的。八股是敲门砖，但面试官最后认可的，永远是那个能把原理落到场景里的你。