JVM这词儿Java程序员基本天天见但说实话很多人对它的理解就停在“Java虚拟机”这个字面意思上。前阵子有个工作五年的朋友问我“JRE和JVM到底啥区别我装JDK是不是就带JRE了”我当场有点愣住。后来想想这东西确实挺拧巴的——我们每天都在跟堆内存、GC日志打交道可真要刨根问底能把JVM的内存模型、编译器种类、参数调优串成一条完整逻辑链的人其实不多。面试题问来问去就那几道但背后牵着的是一整套运行时体系。这篇我打算从JVM的身份定位讲起一路聊到内存模型、字节码与编译器的关系、Tomcat里怎么实际配参数、线上调优该看哪些指标最后把面试里最容易踩坑的几个点也扒一扒。内容尽量贴着实战走该给参数给参数该上命令上命令看完你能在项目中直接照着做的那种。1. JVM到底是个啥它跟JRE、JDK的关系为什么总有人绕晕先说那个经典问题JRE和JVM之间的关系。很多教程会给你画一个三层套娃图——JDK包含JREJRE包含JVM然后让你背下来。背是能背可真到了实际环境里还是容易搞混。我用一句话给你捋清楚JVM是Java程序真正运行的地方它是一个“进程级”的虚拟机JRE是运行Java程序所需要的整套环境JDK是开发Java程序所需要的整套工具集。你写了一个Main.class在命令行敲下java Main的时候操作系统会启动一个新的进程这个进程就是JVM。JVM加载你的字节码解释或者编译成机器码然后执行。而JRE呢它是JVM加上Java基础类库rt.jar、jce.jar那些和运行时依赖的文件的集合体。为什么需要这些类库因为你的代码里用到System.out.println这个System类不是你自己写的是JRE帮你提供的。JVM负责“怎么跑”基础类库负责“跑的时候能用到什么”。那JDK就更往外一层了——它包含了JRE的全部内容再加上编译器javac、诊断工具jmap/jstat/jstack、打包工具jar这些开发用的东西。这里有个实操中很容易犯迷糊的点你装了JDK是不是就一定自带JRE得看版本。JDK 8及以前JDK安装目录下确实直接带了一个jre文件夹。但从JDK 9开始Oracle搞了模块化Project Jigsaw安装目录下就不再有独立的jre目录了。你用java命令跑程序的时候它用的是JDK内置的运行时。所以现在面试要是有人说“JDK里一定包含独立的JRE目录”这观点在JDK 9之后是不成立的。还有一层关系是更底层的——JVM本身不是一个软件而是一份规范。Oracle的HotSpot只是这份规范最流行的实现除此之外还有OpenJ9、GraalVM、Zing等等。规范规定了JVM该有哪些区域比如堆、栈、方法区、该支持哪些指令集字节码指令、类加载机制大概是什么流程但具体内存布局怎么优化、垃圾收集器怎么设计都是各个实现自己发挥。这也是为什么JVM只认字节码不认语言——只要你能把源代码编译成符合规范的class文件就能跑在JVM上。理解到这层你才算把一个最关键的问题想明白了JVM调优调的从来不是Java本身而是一个字节码执行环境。Kotlin、Scala、Groovy这些语言最后都编译成class文件它们跑在JVM上的内存模型、GC行为跟Java是一模一样的。2. JVM内存模型拆解堆、栈、方法区到底各自管什么JVM的内存模型是面试必考也是调优必懂的基础。很多人一上来就背“堆存对象、栈存引用、方法区存类信息”听起来对可真遇到线上OOM还是不知道该查哪块。我带你把这个区域地图画得细一点。2.1 线程私有区程序计数器、虚拟机栈、本地方法栈程序计数器Program Counter Register是JVM里最迷你的区域它存的只是“当前线程执行到哪一条字节码指令”的地址。这块区域不需要调优也不会OOM面试官问到它你答“用于记录字节码执行位置、分支、循环、跳转、异常处理等”就够了。虚拟机栈VM Stack才是真正跟“方法调用”强相关的区域。每次调用一个方法JVM就压入一个栈帧栈帧里保存着局部变量表、操作数栈、动态链接和方法出口。局部变量表里存的是基本类型int、boolean、double这类和对象引用不是对象本身。这是个高频考点也是初学者的重灾区后面我会专门再提。本地方法栈Native Method Stack跟虚拟机栈类似区别只在于它是给native方法用的。HotSpot的实现里把这两个栈合并成了一个所以日常排查基本不用单独区分。这两块区域该关注什么栈的容量是固定的或者动态的固定容量超了会抛StackOverflowError动态扩展内存不够了会抛OutOfMemoryError。最常见的场景就是无限递归——你写了个没有终止条件的递归方法跑几千层之后栈就爆了。2.2 线程共享区堆、方法区、运行时常量池堆Heap是JVM管理的内存中最大的一块所有通过new创建出来的对象实例和数组都在这上面分配。堆内部又划分成新生代Eden、From Survivor、To Survivor和老年代这是为了配合分代垃圾回收策略。新生代里绝大多数对象活不过第一轮GC朝生夕灭老年代则存放长期存活的对象。方法区Method Area在JDK 8之前叫永久代PermGen从JDK 8开始改成了元空间Metaspace。这里面存的是类元信息类的结构、字段描述、方法描述、静态变量、常量池等。切换的动机很实际永久代的大小是固定的-XX:MaxPermSize很容易因为加载的类太多而OOM而且跟堆共用一个内存区域导致互相挤兑。元空间直接使用本地内存native memory默认情况下只受操作系统可用内存限制大大减少了类过多导致的OOM问题。运行时常量池Runtime Constant Pool是方法区的一部分存放编译期生成的字面量和符号引用。比如字符串hello字面量、类的符号引用都在这。2.3 直接内存JVM调优经常忽略的一块直接内存Direct Memory不在JVM运行时数据区的规范里但在JDK 1.4引入NIO之后它变得特别重要。ByteBuffer.allocateDirect()分配的就是堆外内存它的优势是省掉了“内核态到用户态”的数据拷贝I/O性能更高。但副作用是你得自己管理GC管不到它很多细节分配过多一样会抛OutOfMemoryError。我在实际项目里排查过一个诡异的问题程序堆内存占用很低可整个进程的RSS物理内存占用一直涨最后被操作系统OOM Killer干掉了。查到最后就是Netty框架大量用了直接内存默认的-XX:MaxDirectMemorySize又没设。这是个非常经典的“堆没事、直接内存爆了”案例调优的时候一定别漏掉它。2.4 一个对象创建的全流程分配到老年代的路径是怎样的为了把上面的知识点串起来我给了自己团队一个小练习new一个对象它在JVM里到底经历了什么这个练习对理解GC很有帮助。类加载检查JVM先确认这个类是否已被加载、解析、初始化过。如果没有先走类加载流程——加载、验证、准备、解析、初始化。分配内存对象所需的内存在堆上必须是连续的。分配方式有两种一种是指针碰撞Bump the Pointer用于内存规整的时候另一种是空闲列表Free List用于内存碎片化的时候。初始化零值将分配到的内存区域除对象头外全部清零保证不赋值的情况下字段默认值是0或者null。设置对象头存对象属于哪个类的元数据指针、对象的哈希码、GC分代年龄、锁状态标志等。执行构造方法也就是init方法把对象的字段按代码真正初始化。晋升老年代的路径大概是对象先在Eden区分配Minor GC之后存活且年龄1在Survivor区来回倒腾年龄达到阈值默认15就晋升老年代。但有几个特殊情况大对象超过-XX:PretenureSizeThreshold设置的值直接进老年代Survivor区放不下存活对象了也会直接晋升还有动态年龄判定——如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于等于该年龄的对象直接进入老年代。3. Java的“编译器”不是只有javac前端、JIT、AOT一条链路看完热搜词里有个“java jvm编译器有几种”的问题。很多人以为编译器就是javac其实JVM体系里至少有三层编译关系前端编译器javac、即时编译器JIT、提前编译器AOT。这三者管的事完全不同。3.1 javac把Java源码翻译成字节码的前端编译器javac干的事是把.java文件翻译成.class文件也就是字节码。它不会直接生成机器码。为什么要有这么一层中间产物因为JVM只看得懂字节码。字节码是一套很精巧的指令集比如iload是加载int类型局部变量invokevirtual是调用实例方法new是创建对象。每条指令都有对应的操作码opcodeclass文件里全是这些紧凑的二进制指令。前端编译器的执行过程大致是词法分析、语法分析、语义分析、生成字节码。这跟其他语言的前端编译没什么本质区别值得注意的是一些语法糖在这里被拆解比如泛型的类型擦除就是javac阶段干的。你用ListString编译出来的字节码跟List没区别这就是类型擦除——泛型只在编译期做类型检查运行期就没了。3.2 JIT即时编译器热点代码的机器码加速JVM运行class文件时不是从头到尾纯解释执行。HotSpot的名字本身就点出了关键机制——它会找到“热点代码”Hot Spot Code把高频执行的方法直接编译成本地机器码然后缓存起来后续调用直接跑机器码速度大幅提升。HotSpot里有两款主力JIT编译器C1编译器Client Compiler编译速度快但优化程度低适合桌面应用追求启动速度。C2编译器Server Compiler编译速度慢但优化程度高适合服务端应用追求峰值性能。现代JDK默认是分层编译Tiered Compilation——先用解释器快速响应然后C1编译做第一层优化如果某个方法调用频率进一步增加C2再上场做更激进的优化包括方法内联、循环展开、逃逸分析、锁消除等。逃逸分析值得单独说一下因为它直接影响我们写的代码。如果JVM能确认一个对象不会“逃逸”出方法比如只在方法内部new出来用一下没有返回也没有赋给全局变量它可能直接在栈上分配对象对象随着方法结束自动销毁根本不用进堆也就没有GC压力。这也是为什么局部对象别动不动就塞进全局容器——你是在破坏JVM优化它的机会。3.3 AOT提前编译GraalVM Native Image带来的新思路除了JIT现在还有一个方向是AOTAhead Of Time编译。GraalVM的Native Image工具可以把你的Java/Kotlin应用连同JVM运行时一起提前编译成原生可执行文件。好处非常明显启动速度极快毫秒级、内存占用低、没有JIT预热过程非常适合云原生场景的Serverless函数、微服务小实例。代价也很实在不支持运行时动态生成类反射要额外配置reflect-config、不支持频繁的JIT优化、GC选择受限。所以我的建议是常规业务系统别盲目上AOT等你的痛点真的是“启动太慢”或者“内存太小”了再考虑。3.4 Kotlin在JVM上跑Agent字节码面前众生平等热搜词里有条“adk.dev的kotlin快速上手在jvm上跑通一个agent”这正好能用来解释字节码的通用性。Java Agent技术通过premain或者agentmain方式挂载本质上是依赖java.lang.instrument接口在类加载的时候对字节码做增强比如加日志、加监控、做链路追踪。既然JVM只认字节码那你用Kotlin写的Agent逻辑只要最后编译成class文件跟Java写的Agent没有任何区别。实际操作起来你只需要在Kotlin项目里定义一个类里面加上class MyAgent { companion object { JvmStatic fun premain(agentArgs: String?, inst: Instrumentation) { inst.addTransformer(MyTransformer()) println(Agent attached.) } } }然后打包成带Premain-Class属性的jar包运行时加上-javaagent:my-agent.jar就能挂载。这里有个细节Kotlin的顶层函数和companion object默认生成的static方法跟Java的调用方式不太一样如果不加JvmStatic注解JVM平台上就找不到对应的static入口Agent启动会直接失败。这种跨语言细节只有把“JVM只认字节码”这个底层逻辑吃透了才能理解。4. Tomcat启动设置JVM参数从配JAVA_OPTS到验证一次到位线上最常见的实操场景就是给Tomcat调JVM参数。这个活儿看起来简单就是改个环境变量但真正踩过坑的人都知道设置位置、参数生效顺序、大小核数适配处处有讲究。4.1 参数到底写在哪catalina.sh和setenv.sh的分工Tomcat启动脚本核心是catalina.sh它会去读取环境变量JAVA_OPTS、CATALINA_OPTS。两者的区别是JAVA_OPTS在Tomcat启动、关闭、执行各种命令时都会被读取。CATALINA_OPPS只在启动Tomcat主进程的时候读取执行关闭操作时不会加载。所以如果你要设置的是JVM运行参数堆大小、GC算法建议放CATALINA_OPTS这样执行shutdown.sh的时候不会因为某个参数不对导致关不掉进程。不过生产环境很多团队的脚本是直接用JAVA_OPTS一把梭也能用但不够严谨。更推荐的做法是使用专门的环境变量文件setenv.sh。Tomcat启动时catalina.sh会自动检查$CATALINA_BASE/bin/setenv.sh是否存在存在就source它。这样你就不用去改Tomcat自带的catalina.sh升级Tomcat版本的时候不会被覆盖。具体操作是在Tomcat的bin目录下新建setenv.sh内容大致如下export JAVA_HOME/usr/local/jdk17 export CATALINA_OPTS-Xms2048m -Xmx2048m -XX:MetaspaceSize512m -XX:MaxMetaspaceSize512m然后记得给脚本加执行权限chmod x setenv.sh不要小看setenv.sh这种“约定优于配置”的做法它最大的好处是升级Tomcat、迁移环境的时候你的JVM参数配置跟Tomcat自身配置是解耦的。4.2 核心参数解读别只认得Xmx和Xms很多人在线上只敢设置-Xmx和-Xms其他参数一概不加。我理解这种保守但有些默认值真的需要看一下。堆大小相关-Xms初始堆大小推荐设置为跟-Xmx一样大避免JVM启动后因为堆扩容触发多次Full GC扩容本身是重操作而且发生在旧GC体系里会更明显。-Xmx最大堆大小。设太大会浪费内存设太小会频繁GC甚至OOM。建议设置前先监控一下应用常态下的堆占用峰值在这个基础上加30%缓冲。元空间相关-XX:MetaspaceSize触发Full GC的元空间阈值。很多人以为这个是最大值其实不是它是“达到这个值就触发GC来尝试回收类元数据”的阈值。-XX:MaxMetaspaceSize元空间上限超过会OOM。线程栈和直接内存-Xss每个线程的栈大小一般默认1MB就够了别乱调小调小会导致递归深度变浅、容易StackOverflow调大则线程数会变少因为线程栈内存是从操作系统层面申请的。-XX:MaxDirectMemorySize直接内存上限用Netty、Vert.x这类框架的必须显式配置。GC日志相关JDK 8的写法JDK 11用-Xlog:gc*-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/app/logs/gc.log4.3 配置完怎么确认生效三个小命令配了参数最怕的就是“以为生效了”。我先教你一个最直接的验证方法ps -ef | grep tomcat看启动命令行里有没有带-Xmx2048m。如果你的参数是通过环境变量传进去的命令行里会直接显示出来。更准确的验证方式是启动后看实际使用的GC器和堆大小jcmd pid -XX:PrintFlagsFinal | grep -E MaxHeapSize|UseG1GC或者用jhsdb jinfo --flags pid。这些工具的优先级是别信配置文件要看JVM运行时刻的最终值。还有个隐藏很深的坑如果你在Tomcat的catalina.sh里改了JAVA_OPTS但系统里的CATALINA_OPTS环境变量优先级更高两个同名变量冲突时环境变量会覆盖脚本里的赋值。排查这种诡异问题第一反应就是打印完整的JVM启动命令看看实际生效的值到底是什么。5. JVM调优不是调参大赛从现象到结论的一次完整排查“JVM调优”这四个字在很多人脑子里约等于“改Xmx”。但真正有经验的开发会告诉你调优的第一步永远是观察第二步才是动手改参数。5.1 先搞懂指标GC频率、停顿时间、吞吐量线上调优最常见的目标是解决这几类问题Full GC频繁CPU飙高、接口偶尔突然卡顿几秒。OOM进程直接挂掉或者报错。内存泄漏堆内存持续上涨GC后回收不掉。关于GC你要看的核心指标有三个吞吐量Throughput应用运行时间占总的可用时间的比例。吞吐量低说明大量时间耗在GC上。延迟LatencyGC停顿Stop The World时间。停顿时间越长接口毛刺越明显。频率GC多久发生一次。有时候一次GC停顿只有几十毫秒但每分钟几十次累积起来对CPU的消耗也不小。这三个指标存在竞争关系——你想通过增大堆来降低GC频率结果每次GC扫描的区域变大了停顿时间反而上升。调优就是在这三者之间找到平衡点。5.2 排查工具链怎么用jstat、jmap、jstack各管一摊我常用的排查组合是下面这一套jstat -gcutil pid 1000每秒输出一次各代的占用百分比和GC次数。这能快速判断是否在频繁GC、老年代占用率是不是居高不下。jmap -heap pid看堆的当前配置和实际使用情况确认各个参数有没有生效。jmap -histo:live pid触发一次Full GC然后列出占用内存最大的对象Top列表定位大对象或疑似泄漏对象。jstack pid打线程栈查死锁、阻塞、长时间停顿的线程。再往下还有jcmd命令能执行诊断指令比如jcmd pid GC.heap_dump heap.hprof可以导出堆转储文件比老的jmap -dump更简洁。5.3 一个真实案例Full GC频繁但堆不算大前不久我处理过一个应用现象是每几分钟一次Full GC每次停顿1秒多接口响应明显变慢。查的第一步是jstat -gcutil输出里老年代O列长期在90%以上而且Full GC之后下降不明显。这就指向老年代里有大量长期存活的对象而且回收效率很差。接着用jmap -histo:live看前几个对象类型发现有一批byte[]占了堆的40%。再配合线程栈检查发现是一个定时任务在不停地往一个全局Listbyte[]里塞数据从没清理。这就是典型的内存泄漏——对象有引用GC根可达但业务上已经没用了。修复方案不是调JVM参数而是在代码里加上清理逻辑和容量上限。所以我想强调一句很多“JVM调优”问题的答案不在JVM里在代码里。调参永远是最后一步而且是在确认代码没问题之后才做。5.4 参数到底怎么调一个相对稳妥的思路如果你的系统确实需要动参数我的建议路径是这样的保持-Xms和-Xmx一致避免堆动态扩容带来的估值波动。如果JDK 8且能升级直接用G1JDK 9默认GC就是G1。G1用-XX:MaxGCPauseMillis来控制停顿初始可以设200ms跑一个周期看日志再微调。设置一个合理的-XX:MaxMetaspaceSize避免元空间无限涨。打开GC日志保留最近一轮数据为后续调优留依据。一次只改一个参数改完观察至少一个业务高峰周期比如一天别一次性堆四五个参数上去。如果你还在用JDK 8的ParallelGC且堆不超过4G其实默认参数通常就能扛得住。真正需要调优的场景通常是堆很大比如8G以上、要求低停顿如线上交易系统、或者有明确响应时间SLA这时候再花精力研究G1/ZGC也不迟。6. JVM面试题考点解读把八股文变成真理解最后聊点实际的——JVM相关的面试题。很多人靠背题过面试但面试官只要深挖一下就露馅了。其实JVM的知识体系是成网的你只要把几个核心模型打通了题目怎么变形都能接住。6.1 高频题强引用、软引用、弱引用、虚引用各自在哪回收这题考的是你对GC Roots和引用类型的理解。我直接用一句话给你区分强引用Strong ReferenceObject obj new Object()这种只要存在强引用GC永不回收。软引用Soft ReferenceSoftReferenceUser包裹的对象内存充足时不回收内存不足时即将OOM前回收。适合做缓存。弱引用WeakReferenceWeakReferenceUser包裹的对象只要发生GC就会被回收不管内存够不够。典型应用是ThreadLocal的ThreadLocalMap的key。虚引用PhantomReference最弱甚至你从它那里都拿不到对象的引用它存在的唯一意义是在对象被回收时收到一个系统通知用来追踪对象销毁时间。实战里我最常遇到的是软引用和弱引用的选择。做缓存设计时如果缓存里放了大量数据不建议用强引用持有否则堆很容易爆掉。这时候软引用就是一个折中方案——平时能用内存紧张时自动腾地方。6.2 高频题String到底在堆里还是常量池里这个问题特别容易答错因为它跟JDK版本强相关。JDK 7之前字符串常量放在方法区永久代的常量池里。JDK 7开始字符串常量池移到了堆中而字符串对象本身也是一直在堆里的。所以准确的说法是通过new String(hello)创建的对象在堆上通过双引号字面量hello创建的字符串JVM会先去字符串常量池现在在堆里查找如果已存在就直接返回池中的引用不存在则在池中创建。而intern()方法的作用就是把一个堆上的String对象设法加入常量池返回池中的引用。面试题常考的对比String s1 hello; String s2 new String(hello); System.out.println(s1 s2); // falses1指向常量池s2指向堆 System.out.println(s1 s2.intern()); // trueintern后s2回到常量池6.3 高频题对象什么时候进入老年代为什么默认晋升年龄是15晋升老年代的几个条件我在前面已经写过了年龄达到阈值、大对象直接进入、Survivor空间不足。默认晋升年龄15这个数字本质上是因为对象头里记录GC年龄的字段只分配了4个bit能表示的最大值就是15。你要是为了减少Young GC次数把这个阈值调大比如调到30JVM其实只能用4bit存储超过15后面就不再记了这是个物理限制。这里可以延伸出一个面试官喜欢问的点为什么Survivor要分From和To两块因为标记-复制算法需要一块空闲区域作为对象交换的中转站。每次Minor GC把Eden和From里存活的对象复制到To然后清空Eden和From下一轮再交换From和To的语义。如果没有这块“To”空间就只能标记-清理会产生碎片且回收效率变低。6.4 高频题什么是Stop The World为什么会发生STWStop The World指的是GC发生时所有用户线程必须暂停等GC完成后再恢复。为什么必须暂停因为JVM要保证在回收对象期间堆里的对象引用关系不能被用户线程同时修改否则会把活对象当垃圾清理掉或者标记过程中引用关系错乱。很多人觉得STW是G1、ZGC才有的问题其实Minor GC也会有STW只是时间短几毫秒到几十毫秒。ZGC和Shenandoah尝试用染色指针、读屏障之类的技术把STW时间压到极低毫秒级别甚至接近零但代价是CPU的额外消耗和更高的内存占用。线上系统选GC器没有银弹还是那句话在吞吐量、停顿时间、内存占用三者之间做取舍。6.5 面试之外的提醒别把JVM当黑盒要当工具箱顺便给准备面试的朋友提个醒现在面试官几乎人手一个线上问题当追问。你说你懂G1他大概率会接着问“线上G1的Mixed GC阶段是什么RSet是干嘛的”你说你设置过-Xmx2g他可能问“线上OOM了你怎么确认报的是堆OOM还是直接内存OOM”我的建议是与其死磕冷门题不如把jstat、jmap、jstack这些工具练熟把一次真实的线上排查流程完完整整走一遍这比背二十道八股文都管用。写了这么多最后分享一点我个人的体会JVM不是一个需要“精通”的黑盒它更像一个工具箱——你不需要记住每个参数的默认值但一定得知道工具在哪、什么时候该调用、调用了之后怎么看结果。很多人在JVM上花了大把时间研究ZGC的参数其实连jstat的输出都还没看明白这属于本末倒置。先把内存模型和GC的基础链路吃透再按需去查参数、做实验你会发现自己对JVM的掌控感完全不一样。真要遇到线上疑难杂症第一步永远是先完整保留现场GC日志、堆转储、线程快照而不是急着改参数重启。
JVM核心知识一文讲透：内存模型、编译器、调优与面试考点
JVM这词儿Java程序员基本天天见但说实话很多人对它的理解就停在“Java虚拟机”这个字面意思上。前阵子有个工作五年的朋友问我“JRE和JVM到底啥区别我装JDK是不是就带JRE了”我当场有点愣住。后来想想这东西确实挺拧巴的——我们每天都在跟堆内存、GC日志打交道可真要刨根问底能把JVM的内存模型、编译器种类、参数调优串成一条完整逻辑链的人其实不多。面试题问来问去就那几道但背后牵着的是一整套运行时体系。这篇我打算从JVM的身份定位讲起一路聊到内存模型、字节码与编译器的关系、Tomcat里怎么实际配参数、线上调优该看哪些指标最后把面试里最容易踩坑的几个点也扒一扒。内容尽量贴着实战走该给参数给参数该上命令上命令看完你能在项目中直接照着做的那种。1. JVM到底是个啥它跟JRE、JDK的关系为什么总有人绕晕先说那个经典问题JRE和JVM之间的关系。很多教程会给你画一个三层套娃图——JDK包含JREJRE包含JVM然后让你背下来。背是能背可真到了实际环境里还是容易搞混。我用一句话给你捋清楚JVM是Java程序真正运行的地方它是一个“进程级”的虚拟机JRE是运行Java程序所需要的整套环境JDK是开发Java程序所需要的整套工具集。你写了一个Main.class在命令行敲下java Main的时候操作系统会启动一个新的进程这个进程就是JVM。JVM加载你的字节码解释或者编译成机器码然后执行。而JRE呢它是JVM加上Java基础类库rt.jar、jce.jar那些和运行时依赖的文件的集合体。为什么需要这些类库因为你的代码里用到System.out.println这个System类不是你自己写的是JRE帮你提供的。JVM负责“怎么跑”基础类库负责“跑的时候能用到什么”。那JDK就更往外一层了——它包含了JRE的全部内容再加上编译器javac、诊断工具jmap/jstat/jstack、打包工具jar这些开发用的东西。这里有个实操中很容易犯迷糊的点你装了JDK是不是就一定自带JRE得看版本。JDK 8及以前JDK安装目录下确实直接带了一个jre文件夹。但从JDK 9开始Oracle搞了模块化Project Jigsaw安装目录下就不再有独立的jre目录了。你用java命令跑程序的时候它用的是JDK内置的运行时。所以现在面试要是有人说“JDK里一定包含独立的JRE目录”这观点在JDK 9之后是不成立的。还有一层关系是更底层的——JVM本身不是一个软件而是一份规范。Oracle的HotSpot只是这份规范最流行的实现除此之外还有OpenJ9、GraalVM、Zing等等。规范规定了JVM该有哪些区域比如堆、栈、方法区、该支持哪些指令集字节码指令、类加载机制大概是什么流程但具体内存布局怎么优化、垃圾收集器怎么设计都是各个实现自己发挥。这也是为什么JVM只认字节码不认语言——只要你能把源代码编译成符合规范的class文件就能跑在JVM上。理解到这层你才算把一个最关键的问题想明白了JVM调优调的从来不是Java本身而是一个字节码执行环境。Kotlin、Scala、Groovy这些语言最后都编译成class文件它们跑在JVM上的内存模型、GC行为跟Java是一模一样的。2. JVM内存模型拆解堆、栈、方法区到底各自管什么JVM的内存模型是面试必考也是调优必懂的基础。很多人一上来就背“堆存对象、栈存引用、方法区存类信息”听起来对可真遇到线上OOM还是不知道该查哪块。我带你把这个区域地图画得细一点。2.1 线程私有区程序计数器、虚拟机栈、本地方法栈程序计数器Program Counter Register是JVM里最迷你的区域它存的只是“当前线程执行到哪一条字节码指令”的地址。这块区域不需要调优也不会OOM面试官问到它你答“用于记录字节码执行位置、分支、循环、跳转、异常处理等”就够了。虚拟机栈VM Stack才是真正跟“方法调用”强相关的区域。每次调用一个方法JVM就压入一个栈帧栈帧里保存着局部变量表、操作数栈、动态链接和方法出口。局部变量表里存的是基本类型int、boolean、double这类和对象引用不是对象本身。这是个高频考点也是初学者的重灾区后面我会专门再提。本地方法栈Native Method Stack跟虚拟机栈类似区别只在于它是给native方法用的。HotSpot的实现里把这两个栈合并成了一个所以日常排查基本不用单独区分。这两块区域该关注什么栈的容量是固定的或者动态的固定容量超了会抛StackOverflowError动态扩展内存不够了会抛OutOfMemoryError。最常见的场景就是无限递归——你写了个没有终止条件的递归方法跑几千层之后栈就爆了。2.2 线程共享区堆、方法区、运行时常量池堆Heap是JVM管理的内存中最大的一块所有通过new创建出来的对象实例和数组都在这上面分配。堆内部又划分成新生代Eden、From Survivor、To Survivor和老年代这是为了配合分代垃圾回收策略。新生代里绝大多数对象活不过第一轮GC朝生夕灭老年代则存放长期存活的对象。方法区Method Area在JDK 8之前叫永久代PermGen从JDK 8开始改成了元空间Metaspace。这里面存的是类元信息类的结构、字段描述、方法描述、静态变量、常量池等。切换的动机很实际永久代的大小是固定的-XX:MaxPermSize很容易因为加载的类太多而OOM而且跟堆共用一个内存区域导致互相挤兑。元空间直接使用本地内存native memory默认情况下只受操作系统可用内存限制大大减少了类过多导致的OOM问题。运行时常量池Runtime Constant Pool是方法区的一部分存放编译期生成的字面量和符号引用。比如字符串hello字面量、类的符号引用都在这。2.3 直接内存JVM调优经常忽略的一块直接内存Direct Memory不在JVM运行时数据区的规范里但在JDK 1.4引入NIO之后它变得特别重要。ByteBuffer.allocateDirect()分配的就是堆外内存它的优势是省掉了“内核态到用户态”的数据拷贝I/O性能更高。但副作用是你得自己管理GC管不到它很多细节分配过多一样会抛OutOfMemoryError。我在实际项目里排查过一个诡异的问题程序堆内存占用很低可整个进程的RSS物理内存占用一直涨最后被操作系统OOM Killer干掉了。查到最后就是Netty框架大量用了直接内存默认的-XX:MaxDirectMemorySize又没设。这是个非常经典的“堆没事、直接内存爆了”案例调优的时候一定别漏掉它。2.4 一个对象创建的全流程分配到老年代的路径是怎样的为了把上面的知识点串起来我给了自己团队一个小练习new一个对象它在JVM里到底经历了什么这个练习对理解GC很有帮助。类加载检查JVM先确认这个类是否已被加载、解析、初始化过。如果没有先走类加载流程——加载、验证、准备、解析、初始化。分配内存对象所需的内存在堆上必须是连续的。分配方式有两种一种是指针碰撞Bump the Pointer用于内存规整的时候另一种是空闲列表Free List用于内存碎片化的时候。初始化零值将分配到的内存区域除对象头外全部清零保证不赋值的情况下字段默认值是0或者null。设置对象头存对象属于哪个类的元数据指针、对象的哈希码、GC分代年龄、锁状态标志等。执行构造方法也就是init方法把对象的字段按代码真正初始化。晋升老年代的路径大概是对象先在Eden区分配Minor GC之后存活且年龄1在Survivor区来回倒腾年龄达到阈值默认15就晋升老年代。但有几个特殊情况大对象超过-XX:PretenureSizeThreshold设置的值直接进老年代Survivor区放不下存活对象了也会直接晋升还有动态年龄判定——如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于等于该年龄的对象直接进入老年代。3. Java的“编译器”不是只有javac前端、JIT、AOT一条链路看完热搜词里有个“java jvm编译器有几种”的问题。很多人以为编译器就是javac其实JVM体系里至少有三层编译关系前端编译器javac、即时编译器JIT、提前编译器AOT。这三者管的事完全不同。3.1 javac把Java源码翻译成字节码的前端编译器javac干的事是把.java文件翻译成.class文件也就是字节码。它不会直接生成机器码。为什么要有这么一层中间产物因为JVM只看得懂字节码。字节码是一套很精巧的指令集比如iload是加载int类型局部变量invokevirtual是调用实例方法new是创建对象。每条指令都有对应的操作码opcodeclass文件里全是这些紧凑的二进制指令。前端编译器的执行过程大致是词法分析、语法分析、语义分析、生成字节码。这跟其他语言的前端编译没什么本质区别值得注意的是一些语法糖在这里被拆解比如泛型的类型擦除就是javac阶段干的。你用ListString编译出来的字节码跟List没区别这就是类型擦除——泛型只在编译期做类型检查运行期就没了。3.2 JIT即时编译器热点代码的机器码加速JVM运行class文件时不是从头到尾纯解释执行。HotSpot的名字本身就点出了关键机制——它会找到“热点代码”Hot Spot Code把高频执行的方法直接编译成本地机器码然后缓存起来后续调用直接跑机器码速度大幅提升。HotSpot里有两款主力JIT编译器C1编译器Client Compiler编译速度快但优化程度低适合桌面应用追求启动速度。C2编译器Server Compiler编译速度慢但优化程度高适合服务端应用追求峰值性能。现代JDK默认是分层编译Tiered Compilation——先用解释器快速响应然后C1编译做第一层优化如果某个方法调用频率进一步增加C2再上场做更激进的优化包括方法内联、循环展开、逃逸分析、锁消除等。逃逸分析值得单独说一下因为它直接影响我们写的代码。如果JVM能确认一个对象不会“逃逸”出方法比如只在方法内部new出来用一下没有返回也没有赋给全局变量它可能直接在栈上分配对象对象随着方法结束自动销毁根本不用进堆也就没有GC压力。这也是为什么局部对象别动不动就塞进全局容器——你是在破坏JVM优化它的机会。3.3 AOT提前编译GraalVM Native Image带来的新思路除了JIT现在还有一个方向是AOTAhead Of Time编译。GraalVM的Native Image工具可以把你的Java/Kotlin应用连同JVM运行时一起提前编译成原生可执行文件。好处非常明显启动速度极快毫秒级、内存占用低、没有JIT预热过程非常适合云原生场景的Serverless函数、微服务小实例。代价也很实在不支持运行时动态生成类反射要额外配置reflect-config、不支持频繁的JIT优化、GC选择受限。所以我的建议是常规业务系统别盲目上AOT等你的痛点真的是“启动太慢”或者“内存太小”了再考虑。3.4 Kotlin在JVM上跑Agent字节码面前众生平等热搜词里有条“adk.dev的kotlin快速上手在jvm上跑通一个agent”这正好能用来解释字节码的通用性。Java Agent技术通过premain或者agentmain方式挂载本质上是依赖java.lang.instrument接口在类加载的时候对字节码做增强比如加日志、加监控、做链路追踪。既然JVM只认字节码那你用Kotlin写的Agent逻辑只要最后编译成class文件跟Java写的Agent没有任何区别。实际操作起来你只需要在Kotlin项目里定义一个类里面加上class MyAgent { companion object { JvmStatic fun premain(agentArgs: String?, inst: Instrumentation) { inst.addTransformer(MyTransformer()) println(Agent attached.) } } }然后打包成带Premain-Class属性的jar包运行时加上-javaagent:my-agent.jar就能挂载。这里有个细节Kotlin的顶层函数和companion object默认生成的static方法跟Java的调用方式不太一样如果不加JvmStatic注解JVM平台上就找不到对应的static入口Agent启动会直接失败。这种跨语言细节只有把“JVM只认字节码”这个底层逻辑吃透了才能理解。4. Tomcat启动设置JVM参数从配JAVA_OPTS到验证一次到位线上最常见的实操场景就是给Tomcat调JVM参数。这个活儿看起来简单就是改个环境变量但真正踩过坑的人都知道设置位置、参数生效顺序、大小核数适配处处有讲究。4.1 参数到底写在哪catalina.sh和setenv.sh的分工Tomcat启动脚本核心是catalina.sh它会去读取环境变量JAVA_OPTS、CATALINA_OPTS。两者的区别是JAVA_OPTS在Tomcat启动、关闭、执行各种命令时都会被读取。CATALINA_OPPS只在启动Tomcat主进程的时候读取执行关闭操作时不会加载。所以如果你要设置的是JVM运行参数堆大小、GC算法建议放CATALINA_OPTS这样执行shutdown.sh的时候不会因为某个参数不对导致关不掉进程。不过生产环境很多团队的脚本是直接用JAVA_OPTS一把梭也能用但不够严谨。更推荐的做法是使用专门的环境变量文件setenv.sh。Tomcat启动时catalina.sh会自动检查$CATALINA_BASE/bin/setenv.sh是否存在存在就source它。这样你就不用去改Tomcat自带的catalina.sh升级Tomcat版本的时候不会被覆盖。具体操作是在Tomcat的bin目录下新建setenv.sh内容大致如下export JAVA_HOME/usr/local/jdk17 export CATALINA_OPTS-Xms2048m -Xmx2048m -XX:MetaspaceSize512m -XX:MaxMetaspaceSize512m然后记得给脚本加执行权限chmod x setenv.sh不要小看setenv.sh这种“约定优于配置”的做法它最大的好处是升级Tomcat、迁移环境的时候你的JVM参数配置跟Tomcat自身配置是解耦的。4.2 核心参数解读别只认得Xmx和Xms很多人在线上只敢设置-Xmx和-Xms其他参数一概不加。我理解这种保守但有些默认值真的需要看一下。堆大小相关-Xms初始堆大小推荐设置为跟-Xmx一样大避免JVM启动后因为堆扩容触发多次Full GC扩容本身是重操作而且发生在旧GC体系里会更明显。-Xmx最大堆大小。设太大会浪费内存设太小会频繁GC甚至OOM。建议设置前先监控一下应用常态下的堆占用峰值在这个基础上加30%缓冲。元空间相关-XX:MetaspaceSize触发Full GC的元空间阈值。很多人以为这个是最大值其实不是它是“达到这个值就触发GC来尝试回收类元数据”的阈值。-XX:MaxMetaspaceSize元空间上限超过会OOM。线程栈和直接内存-Xss每个线程的栈大小一般默认1MB就够了别乱调小调小会导致递归深度变浅、容易StackOverflow调大则线程数会变少因为线程栈内存是从操作系统层面申请的。-XX:MaxDirectMemorySize直接内存上限用Netty、Vert.x这类框架的必须显式配置。GC日志相关JDK 8的写法JDK 11用-Xlog:gc*-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/app/logs/gc.log4.3 配置完怎么确认生效三个小命令配了参数最怕的就是“以为生效了”。我先教你一个最直接的验证方法ps -ef | grep tomcat看启动命令行里有没有带-Xmx2048m。如果你的参数是通过环境变量传进去的命令行里会直接显示出来。更准确的验证方式是启动后看实际使用的GC器和堆大小jcmd pid -XX:PrintFlagsFinal | grep -E MaxHeapSize|UseG1GC或者用jhsdb jinfo --flags pid。这些工具的优先级是别信配置文件要看JVM运行时刻的最终值。还有个隐藏很深的坑如果你在Tomcat的catalina.sh里改了JAVA_OPTS但系统里的CATALINA_OPTS环境变量优先级更高两个同名变量冲突时环境变量会覆盖脚本里的赋值。排查这种诡异问题第一反应就是打印完整的JVM启动命令看看实际生效的值到底是什么。5. JVM调优不是调参大赛从现象到结论的一次完整排查“JVM调优”这四个字在很多人脑子里约等于“改Xmx”。但真正有经验的开发会告诉你调优的第一步永远是观察第二步才是动手改参数。5.1 先搞懂指标GC频率、停顿时间、吞吐量线上调优最常见的目标是解决这几类问题Full GC频繁CPU飙高、接口偶尔突然卡顿几秒。OOM进程直接挂掉或者报错。内存泄漏堆内存持续上涨GC后回收不掉。关于GC你要看的核心指标有三个吞吐量Throughput应用运行时间占总的可用时间的比例。吞吐量低说明大量时间耗在GC上。延迟LatencyGC停顿Stop The World时间。停顿时间越长接口毛刺越明显。频率GC多久发生一次。有时候一次GC停顿只有几十毫秒但每分钟几十次累积起来对CPU的消耗也不小。这三个指标存在竞争关系——你想通过增大堆来降低GC频率结果每次GC扫描的区域变大了停顿时间反而上升。调优就是在这三者之间找到平衡点。5.2 排查工具链怎么用jstat、jmap、jstack各管一摊我常用的排查组合是下面这一套jstat -gcutil pid 1000每秒输出一次各代的占用百分比和GC次数。这能快速判断是否在频繁GC、老年代占用率是不是居高不下。jmap -heap pid看堆的当前配置和实际使用情况确认各个参数有没有生效。jmap -histo:live pid触发一次Full GC然后列出占用内存最大的对象Top列表定位大对象或疑似泄漏对象。jstack pid打线程栈查死锁、阻塞、长时间停顿的线程。再往下还有jcmd命令能执行诊断指令比如jcmd pid GC.heap_dump heap.hprof可以导出堆转储文件比老的jmap -dump更简洁。5.3 一个真实案例Full GC频繁但堆不算大前不久我处理过一个应用现象是每几分钟一次Full GC每次停顿1秒多接口响应明显变慢。查的第一步是jstat -gcutil输出里老年代O列长期在90%以上而且Full GC之后下降不明显。这就指向老年代里有大量长期存活的对象而且回收效率很差。接着用jmap -histo:live看前几个对象类型发现有一批byte[]占了堆的40%。再配合线程栈检查发现是一个定时任务在不停地往一个全局Listbyte[]里塞数据从没清理。这就是典型的内存泄漏——对象有引用GC根可达但业务上已经没用了。修复方案不是调JVM参数而是在代码里加上清理逻辑和容量上限。所以我想强调一句很多“JVM调优”问题的答案不在JVM里在代码里。调参永远是最后一步而且是在确认代码没问题之后才做。5.4 参数到底怎么调一个相对稳妥的思路如果你的系统确实需要动参数我的建议路径是这样的保持-Xms和-Xmx一致避免堆动态扩容带来的估值波动。如果JDK 8且能升级直接用G1JDK 9默认GC就是G1。G1用-XX:MaxGCPauseMillis来控制停顿初始可以设200ms跑一个周期看日志再微调。设置一个合理的-XX:MaxMetaspaceSize避免元空间无限涨。打开GC日志保留最近一轮数据为后续调优留依据。一次只改一个参数改完观察至少一个业务高峰周期比如一天别一次性堆四五个参数上去。如果你还在用JDK 8的ParallelGC且堆不超过4G其实默认参数通常就能扛得住。真正需要调优的场景通常是堆很大比如8G以上、要求低停顿如线上交易系统、或者有明确响应时间SLA这时候再花精力研究G1/ZGC也不迟。6. JVM面试题考点解读把八股文变成真理解最后聊点实际的——JVM相关的面试题。很多人靠背题过面试但面试官只要深挖一下就露馅了。其实JVM的知识体系是成网的你只要把几个核心模型打通了题目怎么变形都能接住。6.1 高频题强引用、软引用、弱引用、虚引用各自在哪回收这题考的是你对GC Roots和引用类型的理解。我直接用一句话给你区分强引用Strong ReferenceObject obj new Object()这种只要存在强引用GC永不回收。软引用Soft ReferenceSoftReferenceUser包裹的对象内存充足时不回收内存不足时即将OOM前回收。适合做缓存。弱引用WeakReferenceWeakReferenceUser包裹的对象只要发生GC就会被回收不管内存够不够。典型应用是ThreadLocal的ThreadLocalMap的key。虚引用PhantomReference最弱甚至你从它那里都拿不到对象的引用它存在的唯一意义是在对象被回收时收到一个系统通知用来追踪对象销毁时间。实战里我最常遇到的是软引用和弱引用的选择。做缓存设计时如果缓存里放了大量数据不建议用强引用持有否则堆很容易爆掉。这时候软引用就是一个折中方案——平时能用内存紧张时自动腾地方。6.2 高频题String到底在堆里还是常量池里这个问题特别容易答错因为它跟JDK版本强相关。JDK 7之前字符串常量放在方法区永久代的常量池里。JDK 7开始字符串常量池移到了堆中而字符串对象本身也是一直在堆里的。所以准确的说法是通过new String(hello)创建的对象在堆上通过双引号字面量hello创建的字符串JVM会先去字符串常量池现在在堆里查找如果已存在就直接返回池中的引用不存在则在池中创建。而intern()方法的作用就是把一个堆上的String对象设法加入常量池返回池中的引用。面试题常考的对比String s1 hello; String s2 new String(hello); System.out.println(s1 s2); // falses1指向常量池s2指向堆 System.out.println(s1 s2.intern()); // trueintern后s2回到常量池6.3 高频题对象什么时候进入老年代为什么默认晋升年龄是15晋升老年代的几个条件我在前面已经写过了年龄达到阈值、大对象直接进入、Survivor空间不足。默认晋升年龄15这个数字本质上是因为对象头里记录GC年龄的字段只分配了4个bit能表示的最大值就是15。你要是为了减少Young GC次数把这个阈值调大比如调到30JVM其实只能用4bit存储超过15后面就不再记了这是个物理限制。这里可以延伸出一个面试官喜欢问的点为什么Survivor要分From和To两块因为标记-复制算法需要一块空闲区域作为对象交换的中转站。每次Minor GC把Eden和From里存活的对象复制到To然后清空Eden和From下一轮再交换From和To的语义。如果没有这块“To”空间就只能标记-清理会产生碎片且回收效率变低。6.4 高频题什么是Stop The World为什么会发生STWStop The World指的是GC发生时所有用户线程必须暂停等GC完成后再恢复。为什么必须暂停因为JVM要保证在回收对象期间堆里的对象引用关系不能被用户线程同时修改否则会把活对象当垃圾清理掉或者标记过程中引用关系错乱。很多人觉得STW是G1、ZGC才有的问题其实Minor GC也会有STW只是时间短几毫秒到几十毫秒。ZGC和Shenandoah尝试用染色指针、读屏障之类的技术把STW时间压到极低毫秒级别甚至接近零但代价是CPU的额外消耗和更高的内存占用。线上系统选GC器没有银弹还是那句话在吞吐量、停顿时间、内存占用三者之间做取舍。6.5 面试之外的提醒别把JVM当黑盒要当工具箱顺便给准备面试的朋友提个醒现在面试官几乎人手一个线上问题当追问。你说你懂G1他大概率会接着问“线上G1的Mixed GC阶段是什么RSet是干嘛的”你说你设置过-Xmx2g他可能问“线上OOM了你怎么确认报的是堆OOM还是直接内存OOM”我的建议是与其死磕冷门题不如把jstat、jmap、jstack这些工具练熟把一次真实的线上排查流程完完整整走一遍这比背二十道八股文都管用。写了这么多最后分享一点我个人的体会JVM不是一个需要“精通”的黑盒它更像一个工具箱——你不需要记住每个参数的默认值但一定得知道工具在哪、什么时候该调用、调用了之后怎么看结果。很多人在JVM上花了大把时间研究ZGC的参数其实连jstat的输出都还没看明白这属于本末倒置。先把内存模型和GC的基础链路吃透再按需去查参数、做实验你会发现自己对JVM的掌控感完全不一样。真要遇到线上疑难杂症第一步永远是先完整保留现场GC日志、堆转储、线程快照而不是急着改参数重启。
