企业官网建设流程全解析

“说说你遇到过的高并发场景，以及你是怎么调优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,format=b,file=heap.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:MaxGCPauseMillis=200（目标停顿时间，不是绝对保证）

-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系统里，每个连接都会占用内存和脏页缓存。我做过压测：单机MySQL，20个连接时吞吐量最高，加到200个连接，由于锁争用和事务等待，吞吐反而下降。连接池大小 = 磁盘IO核心数 4。对SSD而言，这个数通常在8~16之间。

另外一个高频面试题：如何避免缓存雪崩、穿透、击穿？

雪崩：大量Key同时过期，加随机过期时间。

穿透：查询不存在的数据，布隆过滤器或者缓存空值加短过期。

击穿：单个热点Key失效，用互斥锁（SETNX）或缓存永不过期+异步更新。

记住：缓存层和数据库层之间要有一层熔断降级逻辑。当缓存命中率低于阈值（如30%），直接降级为限流，而不是无脑冲数据库。

面试官最爱问的“灵魂拷问”

面试官：给你一个业务，每天千万级订单，要求高峰期接口RT<100ms，你怎么设计系统？

这不是让你写代码，是让你画架构草图和性能保障点。我建议从这些维度回答：

无状态化：所有节点可横向扩展，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就是你的武器，今天讲的所有知识点都只是开始。