要上进的柯同学最近项目发版后被线上告警拉起来，一个节点反复重启，看监控内存曲线一路爬升，然后容器直接被杀掉。当时我下意识先打开日志目录查OOM，结果什么都没留下，进程起来得太急，堆转储文件也没来得及落盘。后来才一步步通过jstat和gclog定位到是G1收集器的MaxGCPauseMillis配置跟业务特性不匹配，导致GC压力被放大，CPU飙高后容器探针判定失联，触发了重启。这件事让我更确定一个想法：JVM的“概述”不该是背书，而是你得知道程序运行时的内存、线程、垃圾回收和参数是怎么联动在一起的。
这篇内容就是围绕JVM这个话题的一次完整梳理，覆盖JDK/JRE/JVM的关系、内存模型、类加载、垃圾回收、常用参数和线上调试工具，也会把最近搜到的一批高频痛点（比如Gradle版本和JVM不兼容、Docker里Java进程异常重启怎么找日志、SQL执行10秒被关闭到底谁在管）一起串进去。无论你是准备面试还是正在排查线上故障，这篇文章都能直接拿来对照参考。
1. 先搞清楚JDK、JRE、JVM三者到底是什么关系
这方面的基础问题几乎每次面试都会出现，但很多人真的只是背了定义，问深一点就露馅。我记得有次面试官问：“你装JDK的时候，环境变量配的是JAVA_HOME，那这个目录下到底是JDK还是JRE？”这个问题看着简单，却能把“只会敲命令”和“真懂运行时”的人区分开。
1.1 JVM只是Java生态里的执行引擎，不是一个独立安装包
JVM全称Java Virtual Machine，它的职责是加载class字节码，然后逐条解释执行，或者通过JIT编译成机器码执行。但它本身不负责提供基础类库，也不负责管理源码编译，它只是Java跨平台能力的最底层那台“虚拟电脑”。
你写的System.out.println，编译后是INVOKEVIRTUAL java/io/PrintStream.println，JVM负责找到PrintStream对应的类并初始化，然后把方法跑起来。这些java.io、java.util类库并不属于JVM，而是JDK的一部分。所以JVM更像一个计算核心，外面套着类库和工具，才构成完整的Java运行环境。
1.2 JDK、JRE、JVM别再搞混
我用一个大家熟悉的类比：JDK是“食品加工厂”，JRE是“卖出去的预制菜包”，JVM是“微波炉”。加工厂自带菜谱和原材料，预制菜包只保留了能直接加热的成品，微波炉负责真正把它变成能吃的菜。
| 名称 | 全称 | 包含内容 | 典型场景 |
|---|---|---|---|
| JDK | Java Development Kit | JRE + javac + jar + javap + 调试工具等 | 开发、编译、调试 |
| JRE | Java Runtime Environment | JVM + 核心类库 + 支持文件 | 只运行Java程序 |
| JVM | Java Virtual Machine | 字节码执行引擎 | 被JRE或JDK内嵌调用 |
JDK 9之后官方不再单独发布JRE安装包，因为模块化之后jlink可以按需裁剪运行时镜像，单独装一套完整JRE反而不太实用。你JAVA_HOME指向的目录，既包含bin/javac，也包含bin/java，它本身是一个完整的JDK。
1.3 为什么“JVM参数”和“JDK参数”经常被混着说
这个问题在查资料时很容易让人绕晕。比如你启动Java进程时写的-Xmx2g，它确实是JVM参数，定义在HotSpot虚拟机里。但很多看起来像JVM参数的选项，其实由JDK里的类库读取，比如-Dfile.encoding=UTF-8是系统属性，通过System.getProperty访问，不归虚拟机内部管。
还有一类-XX:开头的参数，那是HotSpot专属的非标准选项，不稳定，版本之间可能增减。所以你在网上看到一份“JVM参数手册”，先确认JDK版本，再判断-XX选项是否在当前版本中仍然有效，否则照着配置可能直接启动报错Unrecognized VM option。
理解这个区分，对于后面排查生产问题很有帮助。因为很多故障看起来是JVM行为异常，实际是JDK类库的参数配置不对，或者容器限制没有传给JVM，导致它拿默认值硬跑，最后内存被顶爆。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JVM内存模型：所有性能问题和崩溃的根源
如果只能选一个板块深入学习，我会选内存模型。JVM的线程调度、垃圾回收、OOM、性能调优，全都围绕内存展开。你在面试中被问的“内存模型”，一般是指JVM规范里的“运行时数据区”，跟并发编程里的“Java内存模型(JMM)”不是一回事，这个要先分清。
2.1 运行时数据区：JVM在运行期间到底把数据放哪
JVM规范把运行时数据区划分为几个区域：
- 堆：存放对象实例，几乎所有对象和数组都在这里分配，是GC工作的主战场。
- 虚拟机栈：每个线程一个栈，里面装栈帧，每个方法调用对应一个栈帧。
- 本地方法栈：为native方法服务，HotSpot把本地方法栈和虚拟机栈合并在一起了。
- 方法区：存放类元信息、常量、静态变量、即时编译后的代码。JDK 8后改为元空间，使用本地内存。
- 程序计数器：记录当前线程执行的字节码行号，线程私有，很小。
还有一个经常被忽略的，是直接内存。NIO里的DirectByteBuffer在堆外分配内存，不占堆空间，但是会受容器或系统的内存总量限制。很多人只调-Xmx，却忘了统计直接内存和元空间，导致整机内存估少了。
2.2 堆内存分代设计与对象的一生
HotSpot把堆分成新生代和老年代。新生代又细分Eden区和两个Survivor区，默认比例是8:1:1。你new出来的对象先进入Eden，Minor GC后存活对象被挪到S0或S1，每熬过一次GC，年龄加一，超过-XX:MaxTenuringThreshold（默认15）后晋升老年代。
为什么要分代？核心是统计规律：绝大多数对象是“朝生夕死”的，比如方法内的临时变量、循环里的中间对象。让这些短命对象在新生代里被频繁清理，避免全堆扫描，效率最高。
我在调优时习惯用jstat -gcutil <pid> 1000观察各代使用率。如果看到Survivor区始终接近100%，说明对象存活时间比预想的长，晋升阈值可能需要调大，或者Eden空间偏小导致频繁Minor GC，对象反复拷贝后年龄增长过快。
2.3 线程栈与栈溢出：什么场景下会碰到
每个Java线程默认栈大小是1MB（-Xss可调）。“栈”里面保存局部变量、操作数栈和部分方法调用的返回信息。如果递归调用没有终止条件，或者方法调用层次太深，就会抛StackOverflowError。
有一次我写一个深度优先遍历的递归方法，测试数据从几百条变成几十万条时直接栈溢出。当时第一反应是对象占太多内存，但jmap -heap一看堆很健康，再jstack看线程栈，里面密密麻麻全是同一个方法的调用帧，才意识到是栈深度问题。解决办法是把递归改成显式栈遍历。这类问题很难靠调大-Xss根治，因为真正的瓶颈是算法深度，而不是单帧大小。
2.4 直接内存和元空间：两个容易让人栽跟头的区域
JDK 8把方法区替换成元空间后，字符串常量池挪到了堆上，类元数据使用本地内存。好处是PermGen OOM基本成为历史，但也带来问题：如果加载类过多，元空间会持续增长。比如你在一个长周期任务里反复用反射生成代理类，或者热部署没做好类卸载，元空间占用就会缓慢爬升，最终把容器内存吃满。
直接内存的坑也类似。Netty的堆外内存、Kafka客户端、Elasticsearch等组件都会用直接内存。生产环境我习惯启动参数里加上-XX:MaxDirectMemorySize，否则默认等于-Xmx，在高吞吐NIO场景下容易超额，进程内存看着不高却被Killed。
内存模型这块，不需要死记硬背每个区域的大小，但要能脑子里画出一张图：对象从哪里来、GC怎么挪动它们、线程栈和堆之间的关系、还有哪些藏在堆外面的内存。这张图能帮你回答80%的JVM面试题，更重要的是，排查问题时不至于方向跑偏。
3. 类加载机制：双亲委派和那些千奇百怪的ClassNotFound
类加载机制这部分，工作前几年我几乎没怎么关心，直到有一次线上出现NoSuchMethodError，我花了一个下午才发现是依赖冲突，同一个类名被两个版本的jar包分别加载。从那时起我才认真把类加载链路捋了一遍。
3.1 类加载从触发到初始化的五个阶段
一个类从被加载到真正可用，要经历加载、验证、准备、解析、初始化五个阶段。
- 加载：根据全限定名读取class文件字节流，生成
Class对象。 - 验证：校验字节码格式、元数据、符号引用，防止恶意或错误字节码破坏JVM。
- 准备：为静态变量分配内存并赋默认零值。
- 解析：把常量池中的符号引用替换为直接引用。
- 初始化：执行
<clinit>方法，给静态变量赋代码里写的初始值。
其中准备和初始化之间的区别是个经典面试题：static int a = 10，准备阶段后a的值是0，初始化阶段后才是10。如果要执行static块里的逻辑，也发生在初始化阶段。
3.2 双亲委派模型为什么是“安全底线”
JVM里默认有三个层级的类加载器：启动类加载器Bootstrap（加载rt.jar等核心类）、扩展类加载器Platform（JDK 9后叫Platform，加载lib/ext中的扩展）、应用类加载器AppClassLoader（加载classpath下的类）。
双亲委派的意思是，加载一个类时先让父加载器尝试加载，父加载器加载不到才轮到子加载器。这样最直接的收益是避免核心类库被覆盖。比如你手动写一个java.lang.String放到classpath里，应用类加载器会先请求父加载器，发现rt.jar里有java.lang.String，就用启动类加载器加载的那个，你自定义的这个类根本不会被加载。这防止了恶意伪造核心类。
3.3 实际工作中会碰到的类加载冲突
最常见的类加载问题就是依赖冲突。同一个全限定名出现在多个版本的jar包里，谁先被加载，谁就生效。表现出来可能是NoSuchMethodError、ClassCastException，甚至行为诡异但没有任何报错。排查时可以用-verbose:class启动，看某个类到底从哪个jar加载；或者用mvn dependency:tree查依赖关系。
另一个是SPI机制绕开双亲委派的问题。比如JDBC驱动，DriverManager在启动类加载器加载，但真正的驱动实现在classpath下，按双亲委派根本加载不到。于是JDK引入了ServiceLoader，用线程上下文类加载器来打破“只能父加载”。这属于正常的设计，不算bug，但你在写插件类框架时如果遇到ClassNotFound，就要想想是不是也走了类似的桥。
类加载这块的知识，最大的价值不在于面试解题，而在于遇到“看起来是ClassNotFound但又时好时坏”的诡异问题时，你能快速判断出方向：不是代码逻辑问题，而是类由谁加载、加载了哪一份。
4. 垃圾回收与垃圾回收器：从分代算法到G1
聊JVM永远绕不开GC。不少开发同学一听到GC就头疼，觉得算法多、参数杂。我的经验是先把主线抓住：JVM怎么判断对象能回收，怎么回收，不同回收器对停顿时间和吞吐量的取舍。
4.1 可达性分析与四种引用
JVM采用可达性分析判断对象存活。从GC Roots出发，沿着引用链遍历，不可达的对象就是垃圾。常见的GC Roots包括虚拟机栈中的局部变量、静态变量、JNI引用、活跃线程等。
引用类型有强引用、软引用、弱引用、虚引用四种。强引用就是普通new出来的对象，只要引用链还在，GC就不回收。软引用在内存不足时回收，适合做缓存。弱引用每次GC都可能被回收。虚引用几乎不能通过它获取对象，只用来感知对象被回收，NIO里DirectByteBuffer的回收就用到了虚引用机制。
这里有个和生产关系很大的点：内存泄漏往往不是“对象没地方可回收”，而是“有引用链让它永远可达”。比如ThreadLocal使用后没移除，线程池里的线程长期存活，ThreadLocalMap里的Entry就永远可达，形成泄漏。排查时用jmap -histo:live看哪些类实例数量异常，再结合jstack找到对应线程，就能定位到这类问题。
4.2 分代收集里的Minor GC、Major GC、Full GC
- Minor GC：发生在新生代，清理Eden和一个Survivor。速度快，但会触发STW。
- Major GC：老年代回收，CMS里会伴随长时间的STW。
- Full GC：整个堆回收，通常同时包含新生代、老年代和元空间。
一个常见误区是：“对象大小超过阈值直接进老年代，所以大对象不会触发Minor GC”。确实有-XX:PretenureSizeThreshold可以让大对象直接进老年代，但这其实是为了避免大对象在Eden和Survivor之间反复拷贝。如果你经常创建大数组，老年代会涨得很快，触发频繁Full GC，反而更糟。
4.3 从CMS到G1：为什么现在的默认收集器是G1
JDK 8默认是Parallel Scavenge + Parallel Old，JDK 9之后默认改为G1，JDK 17里G1仍然是比较稳的默认选择。
CMS（Concurrent Mark Sweep）当年很流行，核心思路是减少STW，但它有碎片化问题，老年代碎片多了会触发Concurrent Mode Failure，然后退化成Serial Old的Full GC，停顿暴涨。CMS还在JDK 14被正式移除。
G1把堆划分成多个大小相等的Region，每个Region逻辑上可能属于Eden、Survivor或Old区，这样就打破了“物理分代”的固定边界。G1可以根据你设定的-XX:MaxGCPauseMillis目标，逐步选择回收收益最高的Region集合，来尽量满足停顿时间要求。
4.4 G1的Region、RSet和Mixed GC
G1有几个核心概念建议搞明白：
- Region：堆被分为多个Region，默认2048个左右，每个Region大小从1MB到32MB。
- RSet：记录外部Region对被回收Region内对象的引用。有了RSet，G1在回收某个Region时不用全堆扫描，只需要找到谁引用了它。
- Mixed GC：G1在全局并发标记后，会把一部分Old Region和新生代一起回收，称为Mixed GC。这个过程是G1实现可预测停顿的关键。
实际使用G1时，我踩过一个坑：-XX:MaxGCPauseMillis设得太小，比如50ms，G1为了保证停顿时间，会激进地增加Young GC频率，反而导致吞吐下降。后来根据业务TP99把目标调到200ms，配合-XX:G1NewSizePercent调节新生代下限，停顿和吞吐才平衡下来。
GC这块最忌“背参数”，因为每个应用的分配速率、存活对象量、堆大小都不一样。正确思路是：先通过jstat -gc和GC日志拿到真实的回收频率、单次回收耗时和各区域占比，再决定调哪个参数。
5. JVM参数与实时调试：面试和排查都会用到的东西
参数这块是最容易“看起来会，上手懵”的地方。很多人能背出-Xms、-Xmx、-XX:MetaspaceSize，但一旦报错“Unrecognized VM option”或者“Could not reserve enough space”，就不知道怎么对应了。其实参数理解起来不复杂，分好类，面试、实战都能用上。
5.1 常用堆栈、GC、调试参数清单
以下是我平时启动Java服务时比较常用的一组参数，可以作为基础模板参考：
bash复制java -Xms4g -Xmx4g \
-Xss1m \
-XX:MetaspaceSize=512m \
-XX:MaxMetaspaceSize=512m \
-XX:MaxDirectMemorySize=1g \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=200 \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/data/logs/dump/ \
-Xlog:gc*:/data/logs/gc.log:time,uptime,level,tags \
-jar app.jar
解释一下几个容易忽略的：
-XX:MetaspaceSize是初始值，MaxMetaspaceSize是上限。如果不设上限，元空间使用本地内存可以一直涨直到操作系统限制。-XX:+HeapDumpOnOutOfMemoryError在OOM时自动生成堆转储文件，这个文件是事后定位内存问题的最关键证据。- JDK 8到JDK 11的GC日志参数不一样。JDK 8用
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/gc.log，JDK 9+用统一的-Xlog:gc*。
5.2 -XX:CompileThreshold与JIT编译器
再回到开头提到的-XX:CompileThreshold热词。HotSpot有解释执行和编译执行两种模式。一个方法被反复调用时，JIT会把它编译成机器码，从而大幅提速。-XX:CompileThreshold默认是10000（C1模式下可能不同），表示方法调用次数超过这个阈值后，触发C2编译。
这个参数常见于性能优化场景。比如某个热点方法每秒调用几十万次，在服务启动阶段解释执行时吞吐偏低，你可以适当调低阈值，让JIT更早介入编译。但别盲目设得很小，因为频繁触发编译本身也有CPU开销。更稳妥的做法是用-XX:+PrintCompilation观察编译日志，再决定要不要调。
JIT是个常被忽略的性能点。我遇到过“服务跑了一段时间TPS突然上涨”的现象，其实不是业务改动，而是热点方法被JIT编译成高效机器码了。理解和利用好JIT，比盲目调堆参数更能提升性能。
5.3 线上必用的调试工具：jps、jstat、jstack、jmap、jcmd
jps：列出Java进程和主类名，确认PID。jstat -gcutil <pid> 1000：每秒打印GC各代占用率，观察GC趋势。jstack <pid>：打印线程栈，排查死锁、线程卡死、高CPU线程。jmap -heap <pid>：打印堆摘要；jmap -histo:live <pid>看存活对象分布。jcmd <pid> GC.heap_dump /path/dump.hprof：JDK 8的jmap -dump也可以，JDK 11以后更推荐jcmd。
jcmd -l可以列出所有Java进程，比jps在某些场景下更稳定。工具不在多，关键是组合使用：CPU高先top -Hp找线程，printf '%x'转十六进制，再jstack匹配线程号；内存高就用jstat看GC，jmap看对象分布，最后jcmd生成heap dump慢慢分析。
5.4 一个完整的排查案例：接口偶尔变慢
之前有个服务接口在高峰期偶尔从几十毫秒涨到几百毫秒，但没有OOM，也没有报错。我先用jstat -gcutil看GC，发现老年代使用率在70%-90%之间波动，Full GC大约每几分钟一次，每次STW接近200ms。进一步jmap -histo:live看到大量byte[]，再配合jstack发现是某个定时任务把几十MB数据一次性读到内存里做汇总。
知道根因后，我把定时任务的数据加载方式改成批量分页查询，并调整了老年代大小。GC日志里Full GC频率明显下降，接口TP99恢复稳定。这个案例里，如果只盯着“调大堆内存”，其实是掩盖问题，刷完一批数据后依旧会涨回来，只有从对象分配源头去解，才是真正的调优。
调试工具和参数，一定要在真实故障里用一遍才能形成肌肉记忆。纸上谈兵看一百遍命令，不如线上真实抓一次线程栈来得直接。
6. 从“JVM相关热搜”里带出的几个实战问题
最后把最近高频出现的几个问题集中拆解一遍。这些不是概念题，全是实际操作里很容易卡住的地方。
6.1 Gradle报错：Gradle 6.7.1 is incompatible with the Gradle JVM
这个报错通常出现在你本地装了更高版本的JDK，但项目用的Gradle版本比较老。Gradle 6.7.1最高支持Java 15左右，如果你用JDK 17去跑，就会提示不兼容。解决办法有几个：
- 用
SDKMAN或jenv切换Gradle用的JDK版本，比如指定JDK 11。 - 修改项目里
gradle-wrapper.properties的distributionUrl，升级到与当前JVM兼容的Gradle版本。 - 在IDEA里配置Gradle JVM路径，指向JDK 11。
这个问题的本质不是Gradle坏了，而是构建工具和运行JVM的版本矩阵匹配关系没对上。碰到类似问题，先看Gradle官方兼容表，再决定是降JDK还是升Gradle，不要硬加-Dorg.gradle.java.home瞎试。
6.2 Docker容器里部署Java程序，异常重启后JVM日志在哪儿
这个问题非常现实。容器被重启后，默认情况下/data/logs下生成的GC日志、hs_err_pid文件，都可能因为容器文件系统一起被清理而丢失。要拿到JVM日志，必须做到两点：
- 启动参数里把GC日志、heap dump路径配置到持久化挂载目录，比如宿主机映射出来的
/opt/app/logs。 - 如果进程是被操作系统OOM Killer杀掉，容器层面会标识
OOMKilled，但JVM自身不一定来得及生成任何日志。这时候要看宿主机dmesg或/var/log/messages，确认是否是内存超限被内核杀。
所以容器化部署时，要给JVM预留足够的堆外内存空间。很多人把-Xmx设成容器内存上限的90%，导致连元空间、直接内存、线程栈的空间都不够，进程直接被内核Kill，却查不到任何Java异常日志。常规建议：堆上限不超过容器内存的70%-80%，留出给元空间和直接内存的余量。
6.3 Spring Boot里“SQL执行10秒自动关闭”到底是不是JVM在管
这个热搜问题，答案是：JVM不管SQL执行超时。你看到的“10秒自动关闭”，通常是数据库连接池（比如HikariCP、Druid）或者JDBC驱动层面的超时配置。HikariCP默认没有SQL执行超时，Druid默认的timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis控制的是连接空闲回收，不是SQL执行时间。
如果是MySQL，常见的是wait_timeout、interactive_timeout，以及驱动URL上的socketTimeout。当连接被数据库服务端断开后，连接池还在用这个“死连接”，业务线程就会卡在获取连接或执行SQL上，表现就像“SQL执行10秒被自动关闭”。
排查这类问题不要往JVM调参上想。正确动作是看数据库连接池配置、MySQL的show processlist，以及网络层的连接空闲断开策略。JVM层面能做的，是配置合理的连接池超时、把未使用连接提前回收，避免拿出去执行时才发现连接已失效。
6.4 “could not get JVM parameters and dynamic configurations properly”这类报错的解法
这个报错常见于Elasticsearch这类重度依赖JVM配置的框架启动时。本质是Elasticsearch在启动阶段读取JVM参数和动态配置时失败，通常和以下原因有关：
- 内存配置不合法，比如
-Xms和-Xmx不一致，或者堆大小超过真实可用内存。 - 容器内运行ES，但JVM没有识别到容器内存限制，拿默认配置硬来。
bootstrap.memory_lock: true时，mlockall失败。
解决思路是先确认jvm.options里堆参数是否规范，然后看系统内存和容器内存是否足够，再用ES_JAVA_OPTS或环境变量覆盖默认JVM参数。这类报错的关键是：报错信息往往不直接告诉你具体哪个参数不对，需要结合启动日志和jcmd查看当前生效的JVM配置来一起判断。
7. 写在最后：我对JVM学习的建议
说了这么多，最后还是想给一条有操作性的建议：不要按“从大而全的书开始读”的路径学JVM。更高效的方式，是从一个具体故障切入，比如OOM、频繁Full GC、CPU飙高，然后顺着问题去查内存模型、GC和参数。你被一个问题卡住时学到的东西，比漫无目的读三章理论有用得多。
我自己就是这样，被线上故障“虐”过几次后，才真正把jstat、jstack这些工具变成思维的一部分。现在面试别人时，我反而更看重对方能不能把“一个对象从new出来到被回收”完完整整讲清楚，而不是背出一堆参数。
如果你刚接触JVM，建议按这个顺序实践：装好JDK后，先跑一个简单的Spring Boot服务，用jps和jstat -gcutil观察默认GC行为；然后故意把-Xmx调小，触发一次OOM并生成heap dump，尝试用MAT或JProfiler分析；最后再去看G1的Region、RSet这类复杂概念。这个过程走完一遍，你对JVM的理解会超过很多“背了三个月面试题”的人。
最后分享一个小技巧：线上服务器上，随时留意/tmp目录下的hs_err_pid*文件，这类文件是JVM自身崩溃时的“现场记录”，往往包含出错的指令、线程栈和内存状态。很多人忽略它，但其实它比业务日志更接近崩溃根因。每个版本升级后，也建议用java -XX:+PrintFlagsFinal -version | grep Manageable看看当前JDK里哪些参数是运行时可变、哪些是不可变的，避免在线上“调了个寂寞”。