“说说你遇到过的高并发场景以及你是怎么调优JVM的”这几乎是每一场Java高级面试的必答题。面试官不会满足于你背诵“堆内存分代”“GC算法”这些概念他更想听到当你面对真实的生产环境——CPU飙升到99%、接口响应耗时超过10秒、应用每隔几小时就OOM重启——你是如何抽丝剥茧、用工具和思路一步步定位并解决的。今天我们不聊虚的直接进入十几个经典问答每一刀都砍在痛点上。从CPU飙高说起——排查与调优实战面试官线上某个Java进程突然导致整台机器CPU负载打满你怎么办第一时间不要慌别猜是死循环还是频繁GC。拿出手里的三板斧top -Hp pid找出占用CPU异常的线程ID转为十六进制后用jstack -l pid导出线程快照然后搜索对应的nid。这是底层基本功但很多人第一反应是“重启一下试试”。真正的调优者必须亲手看过线程堆栈里那几行代码。常见的几种元凶无意识的空循环或自旋锁比如while(true)里没有sleep或条件判断直接吃掉单核100%。频繁的Full GC垃圾回收线程本身占CPU且Stop-The-World导致业务线程阻塞后恢复时又争抢CPU。死锁或线程阻塞后大量线程被唤醒又阻塞形成“活锁”式抖动。拿到堆栈后注意观察BLOCKED状态下的线程是否持有了锁以及WAITING状态下的线程是否在park。一个典型的“高CPU 死循环”的堆栈标志是大量线程停留在同一个业务方法里且没有锁等待。这时你只需要找到对应的代码行加上Thread.sleep或重写条件表达式就能解决。而如果是GC导致你需要切换视线到堆内存和GC日志。内存溢出OOM的“三座大山”面试官JVM参数你一般怎么设置遇到过OOM吗怎么分析JVM调优不是算命每一组参数都对应你应用的实际特征。先记住三种最常见的OOM错误及对应排查路径java.lang.OutOfMemoryError: Java heap space—— 堆内存爆了。马上用jmap -dump:live,formatb,fileheap.hprof pid导出堆转储文件然后通过MAT或JProfile分析大对象、内存泄漏的引用链。面试时你至少能说出“负载均衡下的单点内存泄漏往往来自未关闭的IO流、ThreadLocal使用不当或HashMap缓存无上限。”java.lang.OutOfMemoryError: Metaspace—— 元空间溢出。常见于CGLIB代理、大量动态生成类的框架如Spring AOP、MyBatis的Mapper接口扫描。调整-XX:MaxMetaspaceSize只是临时方案根本解决需要检查类加载器是否泄漏或精简扫描范围。java.lang.OutOfMemoryError: Direct buffer memory—— 直接内存堆外溢出。NIO或Netty的ByteBuffer频繁分配未释放或未限制堆外内存总量。通过-XX:MaxDirectMemorySize控制上限同时监控jstat -gcutil中的OU老年代使用率与系统pmap比对。我见过最典型的案例一个支付系统在双十一时OOM频繁团队花了三天看代码没找出问题最后用MAT发现一个大对象是“订单详情字符串”长度超过100MB根源是前端允许用户无限制上传评论图片并全部base64存储到订单快照字段。高并发下的OOM八成是数据量超过设计预期剩下一成是框架bug一成是配置不合理。GC调优——吞吐量与响应时间的平衡木面试官CMS和G1有什么区别你的线上应用用哪个GC参数怎么配这问题不是让你背八股文而是考察你对自己业务的理解。先明确几个原则吞吐量优先单位时间内完成请求多适合后台任务、批处理用Parallel Scavenge Parallel Old。响应时间优先停顿时间短适合交互式应用用G1或ZGC。CMS已经被Oracle标记为废弃但仍有大量老系统在用。它的主要问题是浮游垃圾、内存碎片化、以及并发模式失败导致的“后备Full GC”。面试官一旦问你“CMS的缺点”立刻指出“CMS默认在老年代达到68%时开始并发标记如果应用的对象产生速度太快GC来不及回收就会触发Serial Old做单线程Full GC停顿可达秒级。”而G1通过Region分区和预测停顿模型在堆内存大于6GB且业务对停顿敏感时优势明显。核心参数就三样-XX:UseG1GC-XX:MaxGCPauseMillis200目标停顿时间不是绝对保证-XX:ParallelGCThreads根据物理核心调整面试时的高光时刻你说出“我从不指望GC参数能解决内存泄漏GC调优的意义是在同样代码、同样内存泄漏的情况下让系统多撑10分钟给运维争取重启时间。”这句话表明你懂权衡。实际工作中我遇到过一个低延迟交易系统使用G1但业务高峰期经常出现到日志中to-space overflow。最终调整了-XX:G1ReservePercent和增加堆大小才稳定下来。真正的调优不是调一个参数而是结合业务流量、对象分配速率、存活数据大小综合判断。你需要会看GC日志里的Young GC (Allocation Failure)、Concurrent Mark Phase耗时、以及Pause Time的分布。线程池——高并发的第一道防线面试官你设计一个线程池核心线程数、最大线程数、队列长度怎么定拒绝策略怎么选这是送分题也是送命题。正面回答核心线程数 CPU核心数 (1 平均等待系数)。等待系数通常取0.5~1.5。IO密集型如数据库操作、RPC调用取大一点2CPU核心数计算密集型取小一点CPU核心数1。但是面试官真正想听的是你能否根据系统特性调整例如一个账户查询接口平均耗时50ms其中45ms在等待数据库IO那么核心线程数可以设为CPU核心数的两倍甚至更大但绝不能无限制扩大因为线程切换也有成本。我见过太多团队把核心线程设成200最大2000结果CPU在上下文切换上花掉60%请求耗时反而增加。队列长度通常设置为“核心线程数 200”作为粗略起点但要根据容灾、平均响应时间进行压测。拒绝策略选CallerRunsPolicy时要小心如果调用者线程也被阻塞可能引发级联雪崩。在高并发场景下更安全的做法是用自定义策略把堆积的任务持久化到Redis或数据库等流量低谷再重试。经典陷阱为什么线程池的maximumPoolSize不能设置为CPU核心数的几十倍因为操作系统调度大量线程时CPU时间片被极度切碎每个线程获得运行的间隔变长反而增加了平均响应时间。所以线程池的本质是用有限资源平滑突发流量而不是无限堆积。缓存与数据库——分层降级策略面试官高并发下数据库撑不住怎么办你用过哪些缓存策略这个问题已经从JVM本身延伸到了系统整体架构。但调优者必须理解缓存不是万能药更不是让你把所有数据都放内存。你需要设计“两级缓存”结构本地缓存Guava、Caffeine 分布式缓存Redis、Memcached。本地缓存的优势是无网络开销适合热点Key极少的场景。但要设置合理的expireAfterWrite和大小上限否则就是本地的内存泄漏。面试时你可以抛出两个反直觉的观点“本地缓存虽快但会引入数据不一致问题高并发下我宁愿用带着Redis几毫秒的延迟也不愿让用户看到旧数据。”“如果热点Key只有100个本地缓存命中率99%没人会关心Redis但如果热点Key有几万个本地缓存会频繁失效抖动反而导致缓存雪崩。”数据库层面的调优连接池大小别听默认配置。大多数DBA会告诉你连接数设成100-200但OLTP系统里每个连接都会占用内存和脏页缓存。我做过压测单机MySQL20个连接时吞吐量最高加到200个连接由于锁争用和事务等待吞吐反而下降。连接池大小 磁盘IO核心数 4。对SSD而言这个数通常在8~16之间。另外一个高频面试题如何避免缓存雪崩、穿透、击穿雪崩大量Key同时过期加随机过期时间。穿透查询不存在的数据布隆过滤器或者缓存空值加短过期。击穿单个热点Key失效用互斥锁SETNX或缓存永不过期异步更新。记住缓存层和数据库层之间要有一层熔断降级逻辑。当缓存命中率低于阈值如30%直接降级为限流而不是无脑冲数据库。面试官最爱问的“灵魂拷问”面试官给你一个业务每天千万级订单要求高峰期接口RT100ms你怎么设计系统这不是让你写代码是让你画架构草图和性能保障点。我建议从这些维度回答无状态化所有节点可横向扩展JVM参数统一通过配置文件或配置中心下发。异步化下单的核心链路用消息队列解耦非实时数据发短信、积分、日志异步处理。同步阻塞是性能的第一杀手。预分配与池化数据库连接池、线程池、HTTP连接池全部在系统启动时预热。包括JIT热点代码预热——这个很多人忽略可通过上线前压测“预热流量”防止首次请求慢。内存与GC的“毫秒级”保障对于低延迟接口避免在请求路径上分配大对象。比如不要用String.format生成日志字符串再判断日志级别而应该用占位符或延迟求值。限流与降级基于令牌桶或漏桶做接口级别限流超过阈值直接返回“繁忙”。这比让系统崩溃后OOM优雅一万倍。一个真正有经验的面试者还会提到JVM调优不是一次性工作。线上流量模型会随业务变化每隔一两个月就需要重新审视GC日志、线程转储和堆转储。比如某次大促前我们团队基于压测发现了“Minor GC耗时从20ms飙到80ms”原因是年轻代晋升阈值被调得太低导致大量存活对象过早进入老年代引发Full GC。调整-XX:MaxTenuringThreshold后GC停顿降回20ms。调优不是炫技是生存法则你看高并发与JVM调优的经典问答本质上是两条线索的汇合一条是系统层面的吞吐量与响应时间一条是Java虚拟机内部的堆管理、垃圾回收与线程调度。面试官通过这些问题判断你是在背答案还是真的经历过线上火拼。我的建议是每一次调优决定都要带上数据和场景。比如“我把-XX:NewRatio从2改成3”这句话必须跟着“因为通过GC日志分析发现年轻代GC频率过高但每次GC后存活对象很少增大年轻代可以减少Minor GC次数。”这样面试官才会觉得你有理有据。真正的灵魂拷问其实不是“你怎么调优”而是“你为什么认为那是问题”。举个例子当CPU正常波动在30%偶尔跳到80%后回落这是健康行为但如果你因为看见一次Full GC就修改所有参数反而可能引入更大的问题。调优的终极奥义是克制是理解系统当前的状态只动一个参数验证一次再动另一个。把这些问答内化成你自己的经验面试时你自然能游刃有余。记住高并发不是一场考试而是一场无限游戏你手里的jstack、jstat、MAT就是你的武器今天讲的所有知识点都只是开始。