1. 为什么非要把Java执行过程搞明白我看到这个项目的标题是“java执行环境与执行过程--简单demo化理解”第一反应就是很多人写了几年Java代码天天在用IDE点运行按钮但你要是突然问他“你点了运行之后到控制台打印出Hello World中间到底发生了什么”他大概率会愣住。这其实不怪大家因为Java的“一次编写到处运行”特性把运行细节藏得太深了IDE又帮我们干掉了所有命令行操作时间长了底层机制反而成了盲区。但这个东西重要到什么程度呢面试问JVM、问类加载、问内存溢出本质上问的都是执行环境和执行过程线上排查CPU飙升、内存飙高还是要回到执行环境和执行过程甚至连你配置环境变量的时候把JAVA_HOME指错位置导致项目起不来也是执行环境的问题。我把这个标题拆解成一句话就是Java代码从文件变成进程再从进程变成运行结果这整条链路是怎么跑通的我们要用最简单的小例子把它还原出来而不是去背八股文。这篇文章适合三类人看一是刚学完Java语法、准备开始接触JVM的初学者你需要一条不劝退的入门路径二是准备跳槽、正在刷Java基础面试题的同学你看完会有一种“原来八股文背后是这么回事”的通透感三是写了好几年业务代码、但没认真排查过JVM问题的开发者你可以把这篇文章当成一份留档的排查笔记。我会尽量不用那些吓人的术语堆砌每个概念都拿一个demo级别的代码片段把它钉死。对于已经熟练使用Java的朋友这篇文章也能帮你把零散的知识点串成一条线从.java源文件到.class字节码从字节码到JVM内存布局再从内存布局到垃圾回收和性能调优。走完这条线之后你再回头看那些Java面试题比如“什么是栈帧”“堆和栈的区别”“类加载过程是什么”基本不需要死记。2. 先从宏观链路开始一次运行到底经历了什么2.1 一条最简单的执行链为了后面所有内容都有个共同语境我先把最经典的HelloWorld摆出来public class HelloWorld { public static void main(String[] args) { System.out.println(Hello, World!); } }在命令行下面你要做两件事javac HelloWorld.java java HelloWorld第一行是编译第二行是运行。很多人在IDE里点一键运行反而忽略了这两行命令背后暗含的整个体系。执行环境的最小组成也就是这三样组件角色对应产物JDKJava Development Kit开发工具包提供编译器等javac、jar、javadoc等命令JREJava Runtime Environment运行环境提供JVM和基础类库java命令、lib目录下的运行时库JVMJava Virtual Machine真正执行字节码的虚拟机一个进程JDK包含了JREJRE包含了JVMJDK是给开发用的JRE是给部署用的。这也是很多初学者第一次迷惑的地方我明明装的是JDK为什么老是听说JRE因为你装的那个JDK内部已经自带JRE了你敲java命令时用的就是它自带的JVM。继续往下走真正执行链路的细节是javac把HelloWorld.java编译成HelloWorld.class也就是字节码文件。字节码文件是JVM能识别的指令集不是机器指令。java命令启动一个JVM进程。这个进程会先做类加载把HelloWorld.class里的字节码加载进内存。JVM内部有一个执行引擎负责解释或编译字节码把它翻译成当前操作系统能识别的机器指令。JVM运行时把内存划分成不同的区域方法调用、对象创建、常量存储各归各的区域。main方法执行后从类加载、方法调用到打印输出所有数据在JVM内部流转一遍。进程退出内存回收操作系统回收相关资源。这个过程如果只用一句话概括Java源文件是被javac编译成字节码然后由JVM解释执行或JIT编译执行的。但这句话背后的细节才是我们排查问题和理解面试题的关键。2.2 为什么Java非要翻译两次我用一个再通俗不过的类比来解释Java为什么“慢半拍但到处能跑”。如果你写一份会议通知中文版只能给中国同事看英文版只能给外国同事看。现在你改用了一种“通用手语”写通知哪个国家的同事来了只需要找个翻译员把手语翻成当地话就行了。Java就是这么干的.java是你写给人类看的源代码.class是那个“通用手语”也就是字节码而每台机器上的JVM就是那个“翻译员”。翻译员只需要认识字节码就能把动作翻译成这台机器上的CPU指令。为什么要设计成两次翻译而不是像C/C那样直接编译成机器码因为第一次翻译javac编译成字节码和操作系统无关第二次翻译JVM执行字节码才跟操作系统有关。于是Sun公司只需要为每个操作系统写一个JVMJava开发者写一次源代码就全平台通用了。代价就是多了一道解释/翻译的环节所以纯Java程序在很多场景下比C慢一些这也是JIT编译器Just-In-Time Compiler即时编译器存在的理由程序跑起来之后热点代码会被JIT直接编译成本地机器码缓存起来后续再执行就不用重复翻译了性能可以接近甚至赶超纯编译型语言。这里有一个非常典型的面试加分点现在Java程序里其实同时存在两种执行方式解释执行和编译执行。早期的JVM是纯解释执行的所以慢现代JVM引入了JIT运行时会统计哪些方法被调用得最频繁把这种“热点代码”直接编译成机器码所以实际线上跑的Java程序并没有我们想象中那么慢。这也是为什么同一个Java程序长时间运行后性能反而会比刚启动时更好因为热点代码渐渐都被JIT“编译”过了。3. 用最小Demo理解JVM运行时数据区3.1 运行时数据区到底分几块执行过程不是发生在真空里的JVM启动后要管理自己的内存Java里叫运行时数据区Runtime Data Area。这块内容面试必考也是排查OOMOutOfMemoryError内存溢出的基础。我用表格先把五块主要区域列出来然后逐一说人话。区域存放内容是否线程共享会抛什么Error一句话记忆法程序计数器Program Counter Register当前线程正在执行的字节码地址线程私有无线程执行到哪一行了Java虚拟机栈JVM Stack每个方法调用对应一个栈帧线程私有StackOverflowError方法调用的堆叠本地方法栈Native Method Stack本地方法native的调用线程私有StackOverflowError给C/C方法用的栈Java堆Heap对象实例、数组线程共享OutOfMemoryErrornew出来的东西都在这里方法区Method Area类信息、常量、静态变量、JIT编译产物线程共享OutOfMemoryError类的结构说明书不同JDK版本对方法区的实现方式不太一样这个点之前也很容易成为面试的坑。在JDK 8之前方法区叫永久代PermGenJDK 8之后改名为元空间Metaspace。我之前在维护老项目时见过java.lang.OutOfMemoryError: PermGen space的报错升级到JDK 8之后就基本没见过这个错误了因为元空间默认走的是本地内存不再占用JVM堆内存。这类变化属于经验沉淀实际排查时知道版本差异能少走很多弯路比如网上很多老教程说“调大-XX:MaxPermSize参数”JDK 8及以后版本根本不认这个参数要改成-XX:MaxMetaspaceSize。接下来我用一个很小的demo把每块区域的作用演示清楚。3.2 Demo一个加法和对象创建的执行过程public class RuntimeDemo { public static void main(String[] args) { Calculator cal new Calculator(); int result cal.add(10, 5); System.out.println(result result); } } class Calculator { int add(int a, int b) { int sum a b; return sum; } }先不涉及到那些复杂的并发和锁问题单纯看这个程序在JVM里怎么流转。main是入口方法JVM启动时通过类加载器把RuntimeDemo.class的类信息加载到方法区然后在Java虚拟机栈里为main方法分配一个栈帧。你可以把栈帧理解为“这个方法干活时的临时工位”每次调用一个方法JVM就在栈上压入一个栈帧方法结束栈帧弹出。栈帧里包含局部变量表、操作数栈、动态链接和方法出口。Calculator cal new Calculator()这一行很有意思它干了不止一件事在Java堆中为Calculator对象分配一块内存并初始化对象头和类型指针。在栈帧的局部变量表中保存一个引用类型cal这个引用指向堆里的那个对象。new触发的类加载只是把Calculator类的信息加载进来对象本身的成员变量还没赋默认值不对要严谨一点JVM会先为对象分配内存然后把实例变量赋默认值比如引用类型为nullint为0然后再执行构造方法如果有所以new之后我们拿到的对象状态已经是符合预期的了。接下来调用cal.add(10, 5)时会把实参10和5压入新的栈帧局部变量表然后执行字节码操作。程序计数器会时刻记录当前线程执行到哪一条字节码指令当add方法里做a b计算时两个操作数会先被压入操作数栈然后执行加法指令把它们弹出计算结果再压回。整型计算的结果通过栈帧一层层返回给main方法最终main方法把局部变量result的值作为String拼接参数交给System.out.println方法。为了更直观地对应字节码我强烈建议大家手写一下javap -verbose RuntimeDemo看一段字节码就能明白操作数栈到底怎么工作。我摘一段add方法最常见的字节码给大家看一眼public int add(int, int); Code: 0: iload_1 // 把局部变量第1个int变量即a压入操作数栈 1: iload_2 // 把局部变量第2个int变量即b压入操作数栈 2: iadd // 执行int加法弹出两个值压回结果 3: istore_3 // 把栈顶结果存入局部变量表下标为3的位置sum 4: iload_3 // 把sum再压入栈 5: ireturn // 返回栈顶int值看到这个流程之后你对“栈是JVM执行的核心区域”这句话的理解会完全不一样。你以后再看到StackOverflowError就会本能地想到是不是递归太深导致栈帧无限压栈内存爆了不会再局限在“可能代码写错了”这种模糊认识上。3.3 堆的划分和对象“活多久”的关系除了栈之外Java堆是另一个需要重点理解的地方。堆里存对象实例但堆不是一块大平板而是分区域的。为什么分区域主要是为了配合垃圾回收策略。绝大多数Java对象都是“朝生夕灭”的比如方法里new一个临时对象方法结束就该被回收。只有少数对象会活很久比如Spring容器里的单例Bean。于是JVM把堆分成新生代Young Generation和老年代Old Generation。新生代又细分为Eden区和两个Survivor区一般叫S0、S1。新的对象一般在Eden区分配经过几次垃圾回收还活着的对象会被移动到Survivor区年龄足够大的对象最终被晋升到老年代。默认的年龄阈值是15可以通过-XX:MaxTenuringThreshold调整。对应到我上面那个demoCalculator cal对象创建之后几乎马上就不用了如果这时候发生Minor GC它就会被回收掉。而System类这种从JVM启动就一直存在的类相关的静态数据和方法信息会一直驻留在元空间/方法区不会被轻易回收。很多人学到这里容易糊涂的一个点是栈帧里的引用变量和堆里的对象不是一回事。局部变量cal本身在栈里它只是存放了对象在堆里的地址对象实体本身在堆里。如果cal变量离开作用域栈帧被弹出“保存地址的格子”没了但堆里的对象还在要等垃圾回收器来判定它“不可达”之后才回收。也就是说栈管运行堆管存储两者通过引用来联络。这也是Java面试中“堆和栈的区别”类问题的核心答题思路。4. 类加载机制别人都new了类是谁先准备好的4.1 类加载的五个阶段继续用我们那个demo说事。虽然在代码里是先写了一个main方法然后在方法里new Calculator()但JVM真正执行时不会等执行到new那一行才去加载Calculator类。类加载有自己的时机JVM规范里列了好多触发条件最常见的就是“当虚拟机遇到new、getstatic、putstatic或invokestatic这4条字节码指令时如果类没有被初始化则要先触发初始化”。一个类的完整生命周期包括加载Loading、验证Verification、准备Preparation、解析Resolution、初始化Initialization、使用Using、卸载Unloading。加载、验证、准备、解析、初始化这前五个就是常说的类加载过程。加载通过类的全限定名读取二进制字节流把字节流代表的静态存储结构转化为方法区的运行时数据结构并在堆中生成一个java.lang.Class对象作为方法区这个类的访问入口。验证确保.class文件中的字节流符合JVM规范不会危害JVM自身的安全。这一步是虚拟机自我保护的重要防线。准备为类的静态变量分配内存并设置默认零值。比如public static int count 10;在准备阶段结束后count的值是0不是10把10赋值成真正的初始值要等到初始化阶段。解析把常量池中的符号引用替换为直接引用。简单理解就是代码里写的Calculator只是一个符号引用解析阶段才真正把它定位到内存里的某个具体地址或句柄。初始化执行类构造器clinit()方法把静态变量赋值和静态代码块合并在一起执行。我特别想把“准备阶段赋默认值”讲细一点因为这是我见过最容易出面试题的地方。看这个demopublic class InitDemo { public static int x 10; static { System.out.println(static block); } }加载完成进入准备阶段后x在方法区的静态变量中先等于0类初始化阶段才执行x 10。而对static final修饰的编译期常量比如public static final int Y 99;它在准备阶段就会被直接赋值为99因为JVM规范明确把这种常量视为常量池内容的一部分。如果你只背“准备阶段默认零值”就把这个点答错一半了必须补一句“常量例外”。4.2 双亲委派模型为什么要让爸爸先看类加载里还有一个绕不开的核心知识点双亲委派模型。JVM的类加载器有条加载顺序链Bootstrap ClassLoader启动类加载器 - Platform/Extension ClassLoader平台/扩展类加载器 - Application ClassLoader应用类加载器这三个类加载器各有分工。启动类加载器负责加载$JAVA_HOME/lib目录下的核心类库比如rt.jar里的java.lang.String平台/扩展类加载器负责加载一些扩展库应用类加载器负责加载classpath类路径下我们自己写的类。常见的ClassNotFoundException以及我们代码里经常写漏依赖导致编译期过得去但运行期报错多半都要去应用类加载器加载的classpath里找原因。双亲委派的核心逻辑是**一个类加载器收到加载请求先不自己尝试加载而是把请求委派给父加载器处理每一层都往上抛直到启动类加载器只有父加载器反馈自己加载不了子加载器才自己尝试加载。**这样做最大的好处是保证核心类库的安全比如你就算写了一个java.lang.String类试图覆盖JDK自带的类也不可能成功因为启动类加载器永远是爸爸它会先把真正的JDK核心类加载了等不到应用类加载器自作主张。我记得自己第一次看这段源码时代码很直观protected Class? loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { Class? c findLoadedClass(name); if (c null) { try { if (parent ! null) { c parent.loadClass(name, false); } else { c findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { } if (c null) { c findClass(name); } } return c; } }这段源码就是双亲委派的最直观实现。遇到ClassNotFoundException时不要盲目去翻自己的代码而是要沿着类加载的链条排查是不是依赖冲突了是不是classpath没包含那个Jar包是不是应用服务器或框架自定义了类加载器把加载顺序改了比如Tomcat里多个应用部署同一个Jar包不同版本就涉及更复杂的类加载隔离问题那就是另一篇长文的体量了。5. 真正跑起来从字节码解释到JIT编译5.1 执行引擎怎么工作类加载完成、内存划分好之后真正干活的叫执行引擎Execution Engine。JVM不能直接执行我们写的Java语法只能执行字节码指令。执行引擎可以拆成三种实现方式方式概念特点解释执行逐条把字节码翻译成机器指令执行启动快执行慢JIT编译执行把热点字节码一次性编译成本地机器码启动慢运行快混合模式先解释执行收集到足够热点后JIT编译现代JVM默认策略最典型的混合模式就是HotSpot VM默认会先解释执行然后统计热点方法。当某个方法被调用次数超过阈值-XX:CompileThreshold就会触发JIT编译。很多运维老手配置JVM参数时只盯着堆栈大小其实-XX:PrintCompilation这个参数也能帮你在日志里看到JIT编译了哪些方法。线上某台机器刚启动时负载很低运行一段时间后CPU突然飙高除了业务流量增加也有可能是JIT正在编译热点方法要结合日志一起看才能分清是业务代码问题还是JVM自身的编译行为。这里的体验案例我之前印象很深一个接口刚上线时平均耗时10ms压测跑到一小时后平均耗时降到3ms很多人以为是数据库缓存生效了查了一圈发现数据库没变化最后看日志才知道是JIT把该接口的热点代码编译成了本地机器码执行效率一下子提升了。这个故事拿去面试时谈“JIT的作用”比背概念要生动得多。5.2 强引用、软引用、弱引用对垃圾回收的影响说到执行过程只聊对象怎么创建是不够的还得聊聊对象“怎么死”。JVM垃圾回收判断对象是否存活的核心算法有两个引用计数法和可达性分析算法。引用计数法因为无法解决循环引用问题现在已经不是主流HotSpot默认采用可达性分析从一组称为GC Roots的根对象出发向下搜索引用链。如果一个对象到GC Roots没有任何引用链相连就认为它是不可达的可以被回收。哪些对象可以做GC Roots之前面试时很多人只答出“局部变量引用对象”其实完整的集合是虚拟机栈中局部变量表引用的对象比如当前正在执行的方法里引用的对象静态变量引用的对象比如方法区中类的静态属性引用的对象常量引用的对象比如方法区中常量池里引用的对象JNIJava Native InterfaceJava本地接口引用的对象也就是本地方法栈中native方法引用的对象被同步锁synchronized持有的对象。所以你在栈里持有一个局部变量还在跑循环即使这个对象内部引用关系已经断开但在栈帧被弹出前它依然不会被回收。这也是很多内存溢出的隐藏来源你的局部变量集合太大哪怕某个元素早就该不用了但引用还在集合里垃圾回收器只能干瞪眼。我之前排查过一个案例有人把几百万条明细数据查出来放在一个List里做后续过滤代码思路是先过滤再分批处理但实际写成了先全部装载再循环结果Old区不断增长长时间跑出OOM问题根源就在这个超大List无条件持有了所有对象引用。下面用一个小demo展示手动解除引用前后的差别import java.util.ArrayList; import java.util.List; public class GcRootDemo { public static void main(String[] args) throws Exception { Listbyte[] bigDataList new ArrayList(); for (int i 0; i 100; i) { bigDataList.add(new byte[10 * 1024 * 1024]); // 每块10MB } System.out.println(准备把引用置空); bigDataList null; // 让bigDataList失去对列表的强引用 System.gc(); // 不代表立即回收只是建议 Thread.sleep(5000); System.out.println(执行结束); } }如果真的内存吃紧这段代码在bigDataList null之后立刻gc()的效果会很明显。工程里处理大集合的通用准则是尽早让集合失效不要让引用一直活着等到方法结束才释放把大对象的生命周期控制在最小范围内。6. 环境配置与常见报错速查6.1 为什么JAVA_HOME非要配聊执行环境绕不开环境变量配置。很多人一开始不理解Windows上明明把JDK的bin目录加进Path了就能用java和javac为什么还要单独配置JAVA_HOME真实原因主要有两个一是很多中间件Tomcat、Maven、Gradle、IDEA启动时要找JAVA_HOME来确定用哪个JDK如果你只配置Path没配JAVA_HOME这些工具可能会找不到JVM二是JDK升级时只需要改JAVA_HOME指向新版本目录Path里的%JAVA_HOME%\bin如果写成了绝对路径升级时就要改很多地方配置不统一容易出乱子。推荐大家按这个标准化流程来配下载安装JDK后复制安装根目录例如C:\Program Files\Java\jdk-17。新建系统变量JAVA_HOME变量值就是上面的安装根目录。在Path变量里添加%JAVA_HOME%\binWindows或$JAVA_HOME/binLinux/macOS。命令行验证java -version、javac -version、echo %JAVA_HOME%Windows或echo $JAVA_HOMELinux。如果同时装了多个JDK版本建议用JAVA_HOME做统一切换避免改Path。之前遇到一个新手常见问题命令行里java -version显示的是老版本但JAVA_HOME明明指向了新的JDK 17。一查才知道是系统PATH里某个其他软件把JDK 8的bin目录写到了前面Windows Path是从左往右匹配的优先级高于JAVA_HOME里追加的bin。这种情况处理起来也简单把Path里其他的JDK项移除或者把%JAVA_HOME%\bin挪到最前面就行。6.2 常见运行期报错的定位思路结合热词里提到的那些高频错误我把常见的Java执行期问题整理成一个速查表。这张表不只是面试前背日常开发遇到报错也能按图索骥现象/报错原因方向排查手段Exception in thread main java.lang.ClassNotFoundExceptionclasspath缺少依赖Jar包或类名写错检查构建工具的依赖声明确认目标类在哪个Jar里Error: Could not find or load main class启动命令的类名/classpath路径错误检查是否执行了编译、类名是否包含包名前缀、classpath是否漏配当前目录java.lang.StackOverflowError栈帧无限压栈递归无出口、无限调用查看堆栈找递归入口检查循环调用条件java.lang.OutOfMemoryError: Java heap space堆内存不足或存在大对象强引用用jmap -heap查看堆使用导出dump做分析java.lang.OutOfMemoryError: Metaspace元空间不足常见于大量动态生成类检查CGLib/ASM/热部署场景调大Metaspace参数java: You arent using a compiler supported by lombokLombok与当前JDK版本不兼容或注解处理器配置异常升级Lombok版本检查IDE/构建工具的注解处理开关java: 编码GBK的不可映射字符源文件编码与编译默认编码不一致javac加-encoding UTF-8IDE统一字符编码为UTF-8vscode运行java报错乱码控制台编码、编译器编码不统一确认终端编码为UTF-8配置-Dfile.encodingUTF-8java sun.misc.不存在代码依赖了旧JDK内部API新版本模块化之后移除了删除对sun.misc.*的依赖寻找替代API我拿其中两个案例展开讲一下这种排查习惯比背参数更有价值。第一个是Lombok报错。新项目用了JDK 21maven依赖里的Lombok还是旧版编译时直接报“You arent using a compiler supported by lombok”。这不是代码逻辑问题是Lombok通过注解处理器在编译期修改语法树JDK升级后编译器内部API变动旧版Lombok跟不上。解法很简单把Lombok依赖升到支持对应JDK的版本即可。类似的还有旧版CGLib在JDK高版本上运行直接抛IllegalArgumentException也是内部API变动引起的不是业务代码错误。第二个是乱码问题。Java编译和执行中间涉及到两次编码转换一次是javac读取源文件默认按平台字符集解析Windows中文环境通常是GBK另一次是JVM运行时输出到控制台。如果项目文件是UTF-8而编译时没指定-encoding UTF-8就会出现中文乱码。在命令行编译时我习惯把编译参数固定成javac -encoding UTF-8 HelloWorld.java java -Dfile.encodingUTF-8 HelloWorld在Maven里则建议在pom.xml中显式定义项目编码properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties这一个配置能避免团队协作时因为操作系统字符集不同导致“本地编译没问题、放到服务器上乱码”的经典尴尬。6.3 JVM启动参数给执行环境“定制”执行环境不只是JDK装好就完事生产环境运行Java应用时JVM启动参数决定了很多行为。常用参数我先按功能归个类大家直接拷贝使用即可参数分类示例作用堆内存设置-Xms512m -Xmx1024m初始堆、最大堆大小元空间设置-XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m方法区大小新生代设置-Xmn256m新生代内存大小垃圾回收器-XX:UseG1GC -XX:UseZGC选择GC实现GC日志-Xlog:gc*:filegc.logJDK 9输出GC日志内存溢出快照-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/app.hprofOOM时自动导出堆转储远程调试-agentlib:jdwptransportdt_socket,servery,suspendn,address5005开放远程调试端口很多应用服务器比如Tomcat、Spring Boot应用JVM参数也有自己指定的配置方式比如Spring Boot打成Jar包通过java -jar启动时直接加参数即可Tomcat则要写到catalina.sh里的JAVA_OPTS。我记得刚开始用Spring Boot时总是把-Xmx往启动命令的末尾放但Java命令要求JVM参数必须在-jar之前写成java -jar -Xmx512m app.jar就会报“Unrecognized option: -Xmx512m”。正确的写法是java -Xmx512m -jar app.jar。这个顺序问题虽然很小但踩过坑的人都知道启动脚本跑不起来是最容易让人抓狂的因为报错信息还不太显而易见。6.4 经典OOM排查实操流程最后关于java.lang.OutOfMemoryError: insufficient memory这类报错专门说一下。热词里这个英文提示很典型看起来像是“内存不足”但实际上它分好多个子类型每种对应的排查侧重点都不一样先查看完整的报错信息看是Java heap space、Metaspace、GC overhead limit exceeded还是unable to create new native thread。如果是堆内存溢出先用jmap -heap pid看堆使用概况再用jmap -dump:formatb,fileheap.hprof pid导出堆转储文件。用MAT或VisualVM分析堆转储找出占据空间最大的对象以及对象引用链。定位到超大的集合、缓存、或者有泄漏嫌疑的业务对象后检查是否在频繁new对象并保持引用。我之前处理过一个问题程序周期性从消息队列拉取数据处理完之后放到一个静态的HashMap里做去重。因为一直没清理Map越来越大最后堆被撑爆。Java常识是静态变量作为GC Roots只会被类卸载时回收所以这种缓存一旦放进静态Map基本就成了“永久残留物”。排查到这一步时代码逻辑本身很清晰唯一的修改方案是引入弱引用缓存、定时清理或者限制Map大小。一个小小的实操经验JVM在OOM时不一定是马上就崩溃退出有些场景下进程会陷入频繁GC但总是回收不掉对象的循环然后抛出GC overhead limit exceeded。这种场景比瞬时OOM更难捕捉因为它不立刻退出但是CPU打满服务一直在“假死”。遇到这种情况最好的办法是提前在启动参数里加上-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/oom.hprof让进程在OOM的第一时间自动dump堆快照。否则等进程被运维重启了想查都没材料可查。7. 环境搭建中的版本匹配与工具链协同执行环境这个概念再往外扩一层除了JDK本身还牵扯到构建工具、IDE和项目需求的协同。这一节主要讲版本匹配和生态里的经典坑因为很多执行过程问题其实是从开发环境和部署环境不一致引出来的。先看JDK版本本身。java -version输出里的不同字段代表了不同含义最稳的验法是同时看三个信息java version 17.0.8这是Java版本号2023-07-18 LTS是发布日期和是否为长期支持板后面还有Java(TM) SE Runtime Environment以及HotSpot(TM) 64-Bit Server VM表示JVM实现和运行模式。如果你在64位操作系统上跑Java看到Server VM是正常的如果看到Client VM反而要注意说明你用的可能是老版本JDK的32位安装包这时堆大小受限严重是生产环境的大忌。再说Maven和Gradle。这两个构建工具都有自己的JRE执行环境它们本身也是Java程序。这就导致一个很有意思的问题你用JDK 17写代码如果Maven自身跑在JDK 8上编译时依然可能遇到“release version不支持”之类的错误。现在很多项目会通过maven-compiler-plugin指定编译版本plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version3.11.0/version configuration source17/source target17/target encodingUTF-8/encoding /configuration /pluginsource和target都设成17就行同时确保你的IDE里的Project SDK也指向JDK 17。很多新手配置都是“命令行能编译但IDEA报错”或者反过来不用怀疑是代码写错了99%是IDE的Project SDK、Module SDK、Maven的JRE三处版本没对齐。我最常用的检查口诀是一看IDEA里File - Project Structure - Project SDK二看Maven Settings里的JRE三看环境变量的JAVA_HOME三个地方必须指向同一个JDK。最后是Spring Boot这类框架对Java执行环境的默认要求。Spring Boot 2.x默认支持Java 8Spring Boot 3.x则要求Java 17以上。如果你在本地用JDK 8照着Spring Boot 3的文档写代码启动时会报各类UnsupportedClassVersionError或缺失类错误。这类问题在排查时特别容易让人迷茫因为你看到的报错信息千奇百怪实际根因就是版本不对。下次遇到诡异报错时不妨先把执行环境的版本清单列出来JDK版本、Maven/Gradle版本、Spring Boot版本、Lombok版本然后逐项比对官方支持矩阵往往比直接搜报错信息更高效。8. 实际排查笔记一个线上CPU飙高问题的全过程复盘讲到这里我分享一个亲手排查过的案例帮大家把前面提到的执行环境、类加载、JIT、堆内存和线程栈知识串成一个完整的实战方法。现象是某服务每到中午业务高峰期CPU使用率达到90%以上接口平均耗时上升明显但业务量并没有等比例增长。一开始先加机器治标不治本。后来我们登录服务器执行了以下排查步骤先用top -Hp pid查看进程里的线程CPU占用。看到某个线程PID占用特别高其余线程相对正常。用jstack pid导出线程快照搜到那个线程ID对应的十六进制表示printf %x\n 线程PID确认线程在哪个方法里执行。最后定位到的代码是这样一段自定义的字符串解析解析逻辑它内部用了一个非常大的HashMap做状态存储每次请求都会对这个Map做一次全量遍历来查找匹配规则。代码层面看似没有问题但状态数据因为长久不清理Map越来越大导致每次遍历的时间复杂度无限接近O(n)CPU计算量就上来了。这个复盘的深层原因就是执行过程问题JVM执行字节码过程中随着堆中对象不断增加GC时间变长CPU占用也水涨船高jstat -gcutil pid 1000能看到Full GC全局垃圾回收频率飙升。之前代码里有一个低频但很耗时的清理任务因为任务执行间隔太久且一直持有Map引用导致大量对象滞留老年代。修掉引用和清理策略以后CPU立刻降下来了。如果没有对Java执行环境和内存分区的理解光看到高CPU是很难把现象和“老年代堆积、GC压力大”关联起来的。这个案例告诉我们Java执行过程不只是面试题线上问题分析和调优时整条链路上任何一个环节出了问题都会以“奇怪”的形态暴露出来可能是CPU高、可能是内存报警、可能是接口突然变慢。掌握执行环境和执行过程的意义也并不在于能默写概念而是为一个复杂的分布式系统里的Java应用提供一套可定位问题的底层心智模型。再看JVM参数设计对这类线上问题的作用我们在这个项目里给堆设置了-Xms4g -Xmx4g同时开启-XX:UseG1GC让G1垃圾回收器根据暂停时间目标自动调控老年代和新生代的比例。因为服务峰值流量波动大如果把初始堆设得太小运行初期会频繁触发扩容GC把初始堆和最大堆设成相同值JVM启动时一次申请到位减少了运行期的动态扩容更稳。一个经验是启动参数不要抄模板堆大小要根据服务器的物理内存、容器配额、应用的常驻对象大小综合判断。如果机器只有8G内存你非把-Xmx设为6G操作系统还需要给页面缓存和其他进程预留空间很容易把整台机器压垮。做一个Java后台服务的基本配比建议是预留系统20%-30%的内存给操作系统和其他进程JVM堆和相关元空间控制在这之内如果做容器化部署JVM对容器内存限制的识别是另一个话题——高版本JDK配合-XX:MaxRAMPercentage75等参数会更适配容器环境。9. 把知识落进面试八股文的“活”法最后这块算是给准备面试的同学留的福利。前面说过单纯背八股文没意义但理解执行环境和执行过程后你自己就能回答那些高频问题了。我列几个常见面试题并给出对应活学活用的答法。面试题一Java是编译型还是解释型这个题的满分答法其实不是二选一。Java首先通过javac编译成字节码这一步是编译。JVM执行字节码时先解释执行这是解释型特征但现代JVM引入了JIT编译器会把热点字节码编译成本地机器码这一步又是编译型特征。所以更准确的说法是Java是“半编译半解释”的语言严格来说它是先编译后解释再编译的混合执行模式。很多人能答出前两句能补上JIT的就很少但恰恰是JIT相关的延伸最能体现你真的理解执行过程。面试题二StackOverflowError和OutOfMemoryError的区别StackOverflowError一般在方法递归过深时抛出线程私有的虚拟机栈空间被消耗完了。OutOfMemoryError则是Java堆、方法区等线程共享区域空间不足时抛出。有些人会把两者混为一谈认为都是内存不够。如果能顺着栈帧机制讲到无限递归导致的栈帧压栈过程再补充一个常见的堆溢出场景这个题就活起来了。面试题三说说双亲委派模型的优点。直接背优点是避免核心类被篡改保证类加载的唯一性。但更好的答法是从加载过程讲起当Application ClassLoader收到一个类加载请求会逐级委派给父加载器父加载器无法完成时才由子类自己加载。这样就能保证比如你手写的java.lang.String永远不会顶替JDK自带的String。如果面试官继续追问“能不能打破双亲委派”你可以答可以比如Tomcat为了实现多个应用依赖隔离就自定义了类加载器先加载WEB-INF/classes下的类再委派给父加载器。面试题四JVM参数怎么设置有什么经验这里切忌背参数不解释要说出为什么。比如-Xms和-Xmx建议设成一致是为了避免运行期动态扩容带来的性能损耗和不确定性-Xmn设置新生代大小时要考虑业务对象生命周期如果大量对象都是短命的可以给大一点新生代-XX:HeapDumpOnOutOfMemoryError是为了保留现场不然OOM后连分析素材都没有。这种答法传达的信息是你不只会配参数还真的用它排查过问题。很多Java面试造火箭、工作拧螺丝的话题一直被吐槽但客观地说执行环境与执行过程恰恰是少数“造火箭知识和拧螺丝工作高度重合”的领域。因为无论你是处理内存泄漏、调GC、排查死锁还是做容量规划这些知识都必须有一个扎实的底层模型垫底。八股的意义不在于复述在于通过它形成假设、验证假设、解决真实问题。把八股当导航图用它去索引真实世界的现象这应该是这篇文章最想传达的一点。10. 动手试试推荐自己亲手完成的小实验理论讲完了我还是强烈建议你自己动手做几组小实验有些感知是看文章怎么都替代不了的。第一个实验把运行时数据区可视化。写一个死循环不停new对象然后通过jvisualvm或者jconsole实时观察堆内存的变化曲线。我当年做这个实验时印象极深眼看着Eden区曲线像心跳一样规律波动Old区却在缓慢爬坡第一次真正理解了“分代回收”到底在做什么。第二个实验人为制造StackOverflowError。写一个没有出口的递归方法运行后看报错的堆栈深度。随后调小虚拟机栈大小比如-Xss128k再运行一次你会发现栈深度更浅就报错了。这个实验可以非常直观地告诉你-Xss这个参数影响的是什么。public class StackOverflowDemo { private static int depth 0; public static void main(String[] args) { try { recurse(); } catch (StackOverflowError e) { System.out.println(递归最大深度: depth); } } private static void recurse() { depth; recurse(); } }加上-Xss256k和默认配置分别跑一次对比输出的最大递归深度这种体验比背十遍“栈是线程私有的”都来得快。第三个实验自己编译再用反编译工具看看字节码。写完类后执行javac再用javap -c和javap -verbose查看常量池和字节码指令对照我们前面讲的操作数栈和局部变量表。如果再结合IDEA里的jclasslib插件图形化查看字节码门槛会更低。虽然平时写业务代码确实不直接操作字节码但理解了这些底层结构后遇到“为什么这个写法性能更好”“为什么这段代码会造成性能问题”这类问题时就很容易自己推导出来。第四个实验模拟OOM并配置堆转储。启动参数加上-Xmx64m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/oom.hprof然后写一段不停往List里塞数据的代码。程序OOM后去/tmp目录找到.hprof文件打开MAT点一下“Leak Suspects”看看它帮你自动定位到的可疑对象是什么。全程十分钟但对“OOM不是瘟疫而是待分析线索”的认识会牢固很多。这些实验的共同特点是成本极低、反馈直接。能自动化思维的前提是见过足够多的运行现象亲手制造并观察过异常。等你在本地把这些现象都“玩”过一遍再回到工位上处理Java进程崩溃、变慢、卡顿之类的问题思路会清晰得多先看线程栈、再看堆内存、然后分析GC日志、最后定位到具体代码对象。这样的排障顺序不是谁教的是你自己理解了执行过程之后自然长出来的能力。