前两天有个群里的朋友问我Java高级面试到底在考什么他说自己背了很多八股像什么HashMap扩容、Synchronized锁升级都能说出来但一到现场面试还是被问得发懵尤其是那些结合了线上场景的题目总是答不到点上。这个问题其实很有代表性。高级面试和初级面试最大的区别不在于问题更偏、更冷门而在于它考的不再是“你知道什么”而是“你在真实项目里踩过什么坑、怎么排查、怎么设计”。你要是没实际处理过线上问题光是靠背结论一问到细节就很容易露馅。这期“Java高级面试与工程实践问题集(九)”我打算换个讲法不按知识点列表死板罗列而是挑几个我在面试和日常工作中都高频遇到的场景把题目背后真正想考察的东西拆开讲清楚线程池参数设计背后的逻辑、JVM调优不是玄学、CPU飙高和线程卡死的排查套路、并发工具到底怎么选以及一次分布式事务事故给我留下的教训。每一条都尽量结合真实工程经验来讲希望能给正在准备面试或者想提升实战能力的朋友一些参考。1. 线程池参数设计别只会背七大参数线程池几乎是Java面试必问的考点但大多数人停留在“核心线程数、最大线程数、队列容量、拒绝策略”这个概念层面。面试官随便往深一问比如为什么核心线程数默认不会被回收、队列容量和最大线程数谁先触发、拒绝策略选哪个更合理很多人就开始含糊。1.1 核心线程数为什么默认不会被回收这是我在面试中特别常问的一个细节。很多人知道一个线程池有核心线程和非核心线程但不太清楚为什么核心线程默认“不死”。其实答案很简单这是线程池设计时对“生命周期”的一种权衡。线程的创建和销毁是有成本的涉及到系统调用、内核线程的创建销毁频繁开关线线程会白白增加开销。核心线程作为常驻劳动力就是为了避免这种无谓开销。但要注意核心线程不是绝对不回收。ThreadPoolExecutor里有一个开关叫allowCoreThreadTimeOut默认是false把它设为true之后核心线程也会被空闲回收这样在线程池长时间闲置的场景下可以释放资源。很多人在面试回答时说“核心线程永远不会被回收”其实不够严谨加上这个开关的说明能显得你更懂源码细节。我记得有一次面试候选人还提到了一个更细的点线程池在预启动线程的时候不是一次性把所有核心线程都创建好而是等任务来了才慢慢创建直到达到核心线程数。这个细节就说明他是真的读过源码的。如果你还没注意到这一点可以看看ThreadPoolExecutor的addWorker方法里面会判断当前工作线程数是否小于核心线程数再决定是否新建线程。1.2 队列满了之后才扩线程这个顺序为什么是对的线程池处理任务有一个非常经典的流程核心线程数不够了先去排队队列也满了才去创建非核心线程连最大线程数都顶不住才走拒绝策略。这个顺序不是随便定的它体现了线程池对“资源使用”的优先级考量线程的代价远高于在队列里排队的内存代价所以宁可让任务排队也不轻易创建额外的线程。这个设计在极端场景下会带来一个很有意思的问题如果最大线程数设置得很大队列也很长那么当流量暴增时真正开始创建非核心线程的时机已经非常靠后了队列里会积压大量任务导致响应延迟急剧上升。所以在实际项目中线程池参数的设置必须结合业务对延迟的容忍度来权衡而不只是套公式。我在一个订单推送场景里就被这个问题坑过当时把核心线程数设成4队列容量设了5000最大线程数设了200。平时流量不大没什么问题结果有一次大促流量突增任务大量排队推送延迟从几百毫秒直接飙到几十秒等非核心线程陆续创建出来积压的任务还在排队业务方疯狂告警。后来我们把队列容量调小最大线程数调大同时配合直接丢弃策略和重试补偿才把问题解决。这个经验告诉我线程池参数必须结合业务特性来设计不能照搬别人的配置。1.3 线程池参数真的能算出来吗面试里经常有人问我“你们线程池核心线程数是怎么定的”如果你回答“网上说CPU密集型就N1IO密集型就2N”面试官大概率会追问一句“你们项目里实际验证过吗”。这个问题背后考察的是你有没有真正为业务场景做过评估还是只是抄了一个公式。先说说公式的来源。CPU密集型任务核心线程数最好不超过CPU核数因为线程多了反而会因为上下文切换拖慢速度IO密集型任务线程等待IO的时间占比高理论上是希望在等待的时候让别的线程去占CPU所以可以设置更多线程经典的估算公式是“线程数 CPU核数 * (1 平均等待时间 / 平均计算时间)”。但问题在于线上系统的IO等待时间很难精准测量而且任务类型往往是混合的所以这个公式只能用来估算量级不能照抄。更可靠的做法是先给一个初始值观察运行时的线程池监控指标活跃线程数、队列积压量、拒绝任务数、任务执行耗时再根据实际表现调整。比如我用过动态线程池组件它的核心思路就是把线程池配置外置支持运行期调整参数这样一旦发现线程不够用或者资源浪费改配置不用重启服务。如果你在面试里能讲出这套监控-调整-再监控的闭环思路会比单纯背公式加分很多。另外还有一个非常容易被忽略的点强烈建议自定义线程池而不是用Executors的快捷方法。newFixedThreadPool用的是无界队列只要生产者够快队列会无限积压直接OOMnewCachedThreadPool最大线程数是Integer.MAX_VALUE遇到流量高峰等于无限创建线程。这些坑在面试里已经被反复讲烂了但在实际代码里还是能看到有人图方便直接就用Executors。我去任何团队做代码评审第一轮就会扫这个点。2. JVM调优不是玄学从GC日志里读出问题JVM调优可能是高级面试里最容易被“玄学化”的一块。太多人一说调优就说“改堆大小、换垃圾收集器”但你问他为什么改有什么判断依据他答不上来。这一节我想结合实际排查经验讲一讲怎么从GC日志里读懂系统状态再决定要不要调、怎么调。2.1 线上Full GC频发我从日志里发现的真相很早之前我接手过一个交易相关的服务高峰期接口响应偶尔会突然变慢持续时间不长过一会儿又自己恢复了。单看接口日志看不出明显异常CPU也不高但慢请求的时间点没规律。后来我加上了GC日志参数抓到一个现象老年代使用率到达阈值后开始频繁触发Full GC一次Full GC停顿接近1秒。当时的服务对延迟很敏感1秒的停顿已经严重影响了可用性。GC日志这行关键参数通常长这样2024-11-23T14:12:06.7820800: 42.118: [Full GC (Ergonomics) 6728K-528K(6143K), 0.1541010 secs]从这行里能看到几个关键信息触发原因Ergonomics说明是自适应调节导致的、回收前后堆大小、耗时。当时问题服务里的Full GC频率是每分钟好几次明显不正常。进一步排查才发现某个内部方法在每次请求里都创建了大量临时对象这些对象快速晋升到了老年代导致老年代很快被打满。这个案例的教训是不要一遇到GC问题就去调堆参数而是先要弄清楚“垃圾是谁产生的”。GC只是结果不是原因。优先去分析代码里是否存在大对象、短生命周期大对象、不合理的缓存、过大的线程池导致频繁上下文切换等这些才是根源。参数调优只能缓解症状代码层面的修复才是根治。2.2 怎么从GC日志算出一个合理的堆大小还是在多年的一线实践里我养成了一个习惯拿到GC日志以后先算几个关键指标再决定要不要调堆。第一是看吞吐量也就是你的应用花在业务处理上的时间占比。如果Young GC和Full GC的总停顿时间加在一起占整个运行时间的比例过高比如超过了5%就需要警惕。第二是看单次GC的停顿时间是否符合业务的延迟要求。对实时性要求高的系统单次Full GC超过500毫秒都是不能接受的。第三是看存活对象的大小和密度这决定了堆大小的下限。举个例子假设一个服务运行了60分钟累计发生180次Young GC和2次Full GC。每次Young GC平均耗时30毫秒Full GC平均耗时800毫秒。那总的GC停顿时间就是180 * 0.03秒 2 * 0.8秒约等于7秒占比约0.19%这个比例是健康的。如果你发现这个比例已经到2%-3%就得考虑是不是堆太小导致GC过于频繁或者代码里有大量对象产生。在估算堆大小的时候一个比较粗暴但实用的做法是把每次GC前后对象大小变化记录下来特别关注GC后老年代存活对象的大小。老年代的大小至少要能容纳这些存活对象并留出足够的增长缓冲。我曾经调整过一个服务的堆参数老年代从2GB扩到3GBFull GC频率从每分钟一次降到几十分钟一次原因就是这个服务里长期存活的对象本来就比默认配置下预留给老年代的空间大。调完之后单次GC停顿时间也变长了但总停顿时间反而下降系统整体更稳定。2.3 G1、CMS、ZGC到底怎么选面试里“你用的什么垃圾收集器为什么”几乎是必问题。直接答“我们用的默认的”基本会让人觉得你只是被框架推着走。这里我分享下自己的选择思路。先理解收集器的发展路线。CMS是并发标记清除的经典老将优势是低停顿但它的碎片化问题和浮动垃圾问题很麻烦尤其是JDK 9以后官方就宣布弃用了现在新项目基本不会再用CMS。G1相比CMS最大的改进是把堆分成多个Region可以做到可预测的停顿时间这也是为什么JDK 11以后G1成为默认收集器。ZGC追求极低停顿停顿时间跟堆大小基本无关适合超大堆场景但代价是内存占用偏高需要额外的染色指针和读屏障。我现在的选择标准很简单没特殊要求的Java 11服务直接用G1但要注意显式设置一下期望的停顿时间目标比如-XX:MaxGCPauseMillis200如果堆内存超过几十GB且对延迟要求极其苛刻就认真评估一下ZGC如果系统还在用JDK 8那也只能在CMS和Parallel之间做取舍一般还是优先G1因为它有更好的可预测停顿。这里说一个很多人忽略的坑G1的分区回收顺序和自适应调整比较复杂如果你只是把停顿时间目标设得很小比如20毫秒G1反而会因为不断调整回收策略、频繁做并发标记而消耗更多CPUGC总时间反而变长。所以参数设置必须结合真实监控数据而不是越小越好。3. 线上CPU飙高与线程卡死一次完整的排查实录这一节我想以一个非常经典的线上场景来展开服务突然CPU飙高或者接口大面积超时卡死。这类问题在面试里经常被演变成“线上OOM了你怎么排查”“线上CPU飙升你怎么定位”很多时候考察的是你的排查路径是否清晰是否知道用哪几个命令从外到内一层层缩小范围。3.1 先会用三板斧top、top -H、jstack排查CPU问题的三板斧再说三遍都不嫌多。第一步用top命令看哪个进程在吃CPU确认是不是我们自己的Java进程top进去后按P键可以按CPU使用率排序找到异常进程的PID。第二步用top -H -p PID按线程维度查看找出具体是哪个线程在烧CPUtop -H -p 12345到了这一步你可以看到某个TID特别高。因为Java线程和操作系统线程是一一对应的接下来就是最经典的一步jstack导出线程栈然后把你刚才记下的线程ID转成十六进制去线程栈里找到对应线程。jstack 12345 jstack.txt printf %x\n 23456在jstack输出里搜那个十六进制ID比如它输出为0x5ba0你搜“nid0x5ba0”就能定位到具体线程的名字再往下就是线程的当前执行栈。看到栈信息后就能分析它是阻塞在什么代码上了。这套流程操作起来不复杂但能熟练连贯地做完并且能根据栈信息做进一步判断这在面试官眼里是实打实的实战能力。3.2 一个真实的CPU飙高定位过程有一回某个服务告警CPU使用率到了300%我按上面三板斧走了一遍很快发现是某个业务线程持续占着CPU。jstack里对应的栈信息显示该线程正在循环调用某个字符串解析方法。我点开源码一看发现是一个正则表达式匹配的代码输入里出现了一段特殊字符导致正则引擎进入了一场非常耗时的回溯。正则回溯的问题相信很多老哥都遇到过。像这种类似(a)c的表达式遇到目标字符串“aaaaaaaaaaaaaaaaaaaaaaaaaaaaab”这样的输入时匹配逻辑会陷入指数级回溯CPU直接被打爆。解决办法也比较直接一是尽量用非贪婪匹配改写正则二是通过预校验提前拒绝明显不合法的输入三是设置一个超时机制兜底四是实在不行就换成字符串手动解析。有意思的是这个故障被定位之后我顺手看了下同一服务的日志发现这个接口正常情况下处理很快只有在这个特殊输入出现时才异常。从那以后我再写正则表达式都会特别留意匹配失败的代价也会在代码评审里专门去盯那些有嵌套量词的正则。这个经验不是光靠背就能得到的是需要一次次被线上问题教育出来的。3.3 线程卡死除了CPU高接口还会超时还有一种常见现象是CPU不高但接口大面积超时jstack一看一大片业务线程都卡在同一个地方。这种通常不是计算密集问题而是线程在等待某个锁、某个网络IO或者某个数据库连接。按我的排查习惯我会先对jstack的输出做一个统计看看线程都集中在哪些状态。比如大量线程处于BLOCKED状态那多半是锁竞争大量线程处于WAITING状态且都停在lock.wait()这种地方那就要看它们在等谁唤醒大量线程处于RUNNABLE但实际上是碰到了网络IO底层block那就要检查下游依赖是否超时。我遇到过一个印象很深的问题一个消费MQ消息的服务某次消息积压之后处理线程全部卡在向另一个服务发HTTP请求的地方因为那个下游服务的连接池被打满了。我们服务的HTTP客户端没有设置建连超时和读超时默认情况下连接迟迟得不到响应线程只能一直挂着。这个案例的排查思路就是一步步看线程栈里卡在什么调用上然后沿着调用链去看是本地代码问题还是依赖问题。如果一开始就怀疑是“程序Bug”很容易走偏。从那以后我做了一个约定所有涉及外部调用的连接池、线程池都必须在配置里明确超时时间宁可被异常中断也不允许线程无限期等下去。这个改动看着小但直接把一类线上故障的概率降到了接近零。4. 锁、并发工具的选择背后是业务场景的博弈高级面试里还会有一类高频题并发工具和锁。这类题如果只是问“synchronized和ReentrantLock有什么区别”很多人能答得不错但一旦结合场景问“这个场景你选哪个为什么”很多人就开始乱选。这节我重点讲讲锁升级和工具选型背后的逻辑。4.1 synchronized的锁升级流程你真捋清楚了吗面试说到synchronized几乎都会聊到锁升级。在Java 6之后锁一共有四种状态无锁、偏向锁、轻量级锁、重量级锁。随着竞争加剧锁会从偏向锁升级为轻量级锁再升级为重量级锁。能说出升级顺序只是第一步真正的加分项是能讲清楚为什么要这么设计。偏向锁的设计思路是假设大多数情况下锁不会有竞争同一个线程反复拿到同一把锁那就没必要每次都做同步操作。它的实现是在线程第一次获取锁时在对象头里记录该线程ID之后这个线程再来抢锁只需要简单比一下ID是否一致就行。轻量级锁是当两个线程交替抢锁时通过CAS自旋来尝试获取锁好处是避免线程挂起和上下文切换。但自旋是消耗CPU的如果竞争太激烈自旋等待的成本反而超过线程挂起那就干脆升级成重量级锁走操作系统的互斥量。理解这些之后就不难明白为什么现在很多高并发场景下我们不推荐用synchronized了。锁升级到重量级后线程挂起和唤醒涉及内核态切换这个代价非常高。如果你的业务里锁竞争很激烈就会看到大量线程在等待同一个重量级锁。不过话说回来synchronized也有它的优势写法简单JVM对它的优化一直在持续而且它是JDK层面的关键字随便谁接手代码都能看懂。如果你对锁竞争的判断是“竞争不激烈”或“操作耗时极短”用synchronized完全没有问题没必要刻意换成ReentrantLock。4.2 ReentrantLock和读写锁的取舍边界ReentrantLock相比synchronized的优势除了可中断、可超时之外最核心的一点是支持公平锁和非公平锁的选择以及底层基于AQS可以做出更灵活的扩展。但在业务代码里这些优势真正能用上的场景其实有限。如果你写一个读多写少的缓存最该考虑的往往不是ReentrantLock而是读写锁ReadWriteLock或者更进阶的StampedLock。ReadWriteLock的思路很直白读读之间可以并行读写之间互斥写写之间互斥。它非常契合“读多写少”的业务模型。不过它有一个问题如果读线程特别多而且一直持有读锁写线程会面临“写饥饿”一直抢不到锁。这在缓存这类场景里尤其危险极端情况下缓存数据可能很久得不到更新。StampedLock是Java 8带来的改进它引入了一个乐观读的模式。乐观读不会真正加锁它只是记录一个stamp然后在读之后判断这个stamp是否仍然有效如果期间有写入就再升级成悲观读锁。这种模式在读多写少的场景下性能非常理想但它的代价是使用难度高很多而且在锁竞争激烈时效率反而下降并且它不支持重入。我个人的看法是如果你的业务确实简单读多写少并且能接受代码稍微复杂一点可以考虑StampedLock里的乐观读否则优先使用ReadWriteLock就够了。4.3 ConcurrentHashMap源码里的几个隐形考点提起并发集合ConcurrentHashMap是绕不开的。很多初中级面试都会问“HashMap和ConcurrentHashMap的区别”高级面试则会深入到更细的机制比如JDK 8的ConcurrentHashMap为什么把分段锁改成了CAS synchronized它的size()方法是怎么算的为什么不是直接维护一个size变量扩容的时候读线程是怎么处理的同时扩容的线程之间是怎么协作的先说第一个问题。JDK 7的分段锁确实减小了锁粒度但Segment数一旦初始化就固定了也就是说锁粒度是固定的。JDK 8改成对每个桶头节点用synchronized加锁桶数量可以动态扩容锁粒度更细而且头节点为空时用CAS写入连锁都不用加。再加上synchronized已经经过JVM优化这个改动的性价比很高。size()方法之所以用CounterCell数组间接计数原因是在高并发下如果用一个long来累加多线程同时更新会出现缓存行伪共享的问题进而拖慢性能。把计数分散到多个CounterCell上最后汇总求和是一个经典的用空间换性能的方案。面试里你如果能顺带解释这个“为什么不用一个long”的细节面试官一般会眼前一亮。扩容的并发协作也是高并发场景里很重要的设计当某个线程发现桶数组需要扩容时它不会自己把所有数据复制完才返回而是先帮整个扩容过程做一些工作然后把任务转交给其他线程继续参与。这种思想叫“多线程协助扩容”。设计得极为精妙理解它需要对CAS、volatile、数组替换这些底层操作都足够熟悉。如果你能把源码里的迁移逻辑讲清楚说明你对并发包的理解已经很深了。5. 从一次分布式事务事故看工程实践的取舍最后我想聊聊分布式事务。这个话题不只是面试题更是工程实践里容易翻车的地方。我参与过一个项目曾经因为对分布式事务方案选型不当导致了一笔订单数据错乱的事故事后复盘了很久。5.1 事故是怎么发生的当时那个订单系统接了一个下游积分服务他们希望“创建订单”这个操作能同时给用户增加积分。技术负责人直接引入了分布式事务框架把两个服务的数据库更新包进同一个全局事务。看似完美的设计线上跑了一阵之后发现下游积分服务偶尔因为网络抖动导致事务回滚上游订单服务也跟着回滚了。结果用户发现自己花钱买的订单消失了还以为是系统出了Bug投诉量一下子就上来了。复盘时发现问题的本质不是框架的Bug而是选型就不合理。积分增加这个动作根本不应该跟订单创建强一致地绑在同一个事务里。订单创建是主流程积分变动是周边流程。就算积分服务暂时不可用也应该让订单先创建成功积分异步重试后最终补上。引入强一致性的分布式事务等于把两个服务的可用性绑在了一起任何一个服务抖动整个链路都会被拖下水。这个事故让我对分布式事务有了一个非常深刻的认识分布式事务不是一项技术选型问题而是一个业务一致性需求设计问题。先想清楚你的业务到底需要强一致还是最终一致再决定要不要引入分布式事务这远比一开始就塞一个框架更重要。5.2 强一致和最终一致各有什么代价面试里遇到分布式事务相关的问题你如果能主动区分“强一致”和“最终一致”两个方向并且说明各自代价就已经赢了大半。先看强一致方向比如2PC两阶段提交和TCC。2PC最大的问题是整个事务过程是同步阻塞的而且协调者单点风险高如果协调者在prepare阶段之后宕机了参与者只能一直等整个链路就被卡死。TCC则把每个事务拆成Try、Confirm、Cancel三个阶段业务侵入性很强每一阶段都得写对应的补偿逻辑。这个方案不是不能用但它只应该用在资金类、强校验类场景因为它已经把“业务补偿”的复杂度压制在了可控范围内。再看最终一致方向比如可靠消息、本地消息表、事务消息。这种方案的思路是上游先把自己的事务提交掉同时记录一条消息然后通过消息队列异步通知下游。如果下游处理失败就靠重试来达到最终一致。这种方式对主流程的可用性影响最小但代价是数据在中间某一个时刻是“暂时不一致”的需要业务上接受这个设计。我们后续把这个积分场景改造成了事务消息方案订单创建本地事务成功后发送一条事务消息积分服务消费消息处理积分处理失败就自动重试同时加了一张手工补偿表兜底。改造之后再也没出现过因为积分服务抖动导致订单被回滚的事故。这个经验向我反复证实了一个结论如果你不能确定业务需要强一致就老老实实走最终一致不要为了技术上的“高大上”而引入复杂度。5.3 面试中如何把分布式事务的坑说成亮点如果你在面试中被问到分布式事务最好不要只是把2PC、TCC、消息事务的概念复述一遍那跟背课文没区别。真正能打动面试官的是你把自己对这个话题的“手感”讲出来。比如你可以说我在订单系统里做过事务方案的对比发现强一致方案对业务侵入性太大而且把核心链路的可用性绑在了周边服务上后来改成事务消息 本地消息表的最终一致方案既保证主流程的顺利完成又让积分变更有重试和补偿的兜底。这种回答之所以好是因为它同时体现了三个能力第一你理解不同方案的本质差异第二你有真实的方案判断力知道什么场景该选什么方案第三你有落地的工程意识不是停留在理论层面。这三点其实就是高级工程师和初中级工程师的分水岭不是看你会不会背某个知识点而是看你在业务约束和技术复杂度之间能不能做出合理的取舍。如果你现在正准备面试我真的建议你挑两个自己实际做过的、哪怕很小的技术决策把它从“为什么这样选”到“不这样选会怎样”到“上线后表现如何”完整梳理一遍。比起再刷几十道题把这些问题讲透面试中的表现会好得多。另外还想说一句我见过不少基础扎实的候选人死在“答得全但答不深”。比如线程池的七大参数背得滚瓜烂熟但你把一个线上场景抛给他问他“假设核心线程数8、队列容量100、最大线程16现在一秒钟来了500个任务会发生什么”他就会卡住。所以平时练习的时候多试着把知识点往场景里套少背结论多想过程这种思维习惯一旦养成带来的提升是长期的。