拓冰网站定制 
先问个问题你身边有多少Java开发者写了好几年代码遇到ClassNotFoundException就加依赖碰到OOM就改-Xmx被问到“类加载过程分几步”就开始含糊我见过太多这样的案例包括几年前的我。说实话JVM这块内容属于典型的“地基知识”——平时不显山不露水一旦线上出问题排查思路是否清晰全靠这些基础撑场子。这篇笔记是JVM学习系列的第三篇聚焦两个绕不开的核心板块类加载与字节码技术、内存模型JMM。前一个是搞懂“.class文件怎么变成活生生的对象”后一个是搞懂“多线程环境下数据怎么安全地穿梭于内存”。无论你是准备面试、在做性能优化还是单纯想摆脱“面向搜索编程”这篇都值得花半小时慢慢读。我会尽量用实际场景和踩坑经历来讲少讲空洞理论。1. 类加载机制从.class到JVM的完整旅程类加载这块很多人背得滚瓜烂熟“加载、验证、准备、解析、初始化”但真让他解释“准备阶段到底干了什么”就卡壳了。这节我们不只是过流程我会结合字节码反编译和实际报错把每个阶段的前因后果讲透。1.1 一个类的“一生”类加载的五大阶段JVM里的类加载不是一个瞬间动作而是一条流水线。整条流水线包括加载Loading、验证Verification、准备Preparation、解析Resolution、初始化Initialization后面还有使用和卸载但重点是这五个阶段。加载阶段做三件事通过类的全限定名获取定义此类的二进制字节流将字节流所代表的静态存储结构转化为方法区的运行时数据结构在内存中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据的访问入口。注意“通过全限定名获取二进制字节流”没规定必须从ClassPath读所以才有后续那么多花活从ZIP包读、从网络读、运行时动态生成、由其他文件生成比如JSP转Class。这也是为什么像CGLIB、ByteBuddy这类库能存在的根本前提。验证阶段是安全的第一道防线。JVM要保证字节流符合规范不会危害自身安全。这个阶段包括文件格式验证、元数据验证、字节码验证、符号引用验证。说白了就是检查你是不是拿一堆乱写的字节码来糊弄它。这个阶段在开发期经常被忽略但因为一些高版本JDK默认开启了严格校验你如果用了太老的字节码生成库反而会在这里栽跟头——这个后面讲字节码技术时再展开。准备阶段是很多人理解最容易跑偏的地方。官方定义是为类变量static修饰的变量分配内存并设置零值。什么概念public static int value 123;在准备阶段结束后value的值是0不是123。123要到初始化阶段执行clinit方法时才会真正赋值。但有一个例外如果静态字段被final修饰且是编译期常量比如public static final int value 123;准备阶段就会直接赋值为123。解析阶段是把常量池内的符号引用替换为直接引用的过程。符号引用就是一组描述目标的字面量直接引用就是指向目标的指针、相对偏移量或者能间接定位到目标的句柄。这里不展开太深你只需知道早期绑定比如invokestatic指令调用静态方法在解析阶段就能完成而动态绑定比如invokevirtual调用实例方法要等运行时才能确定具体方法。初始化阶段才是真正执行类构造器clinit方法的时刻。虚拟机会保证在初始化前父类已经初始化完毕如果多线程同时初始化一个类JVM会加锁保证只有一个线程能执行clinit其他线程必须等待。这也是为什么静态代码块里的耗时操作会成为多线程环境下的隐藏性能瓶颈。1.2 双亲委派模型为什么必须“先问爸爸”搞清楚双亲委派之前得先认识JVM自带的三个类加载器类加载器加载路径主要职责Bootstrap ClassLoader$JAVA_HOME/lib下的核心类库rt.jar等加载JDK核心类C实现Platform/Extension ClassLoader$JAVA_HOME/lib/ext加载扩展类JDK9后改为平台类加载器Application ClassLoaderclasspath环境变量指定的路径加载我们自己写的类及第三方依赖双亲委派模型的规则很简单当一个类加载器收到类加载请求时它不会自己先去加载而是先把这个请求委派给父加载器每一层都是如此直到顶层Bootstrap。只有当父加载器反馈自己无法完成加载时子加载器才会尝试自己加载。这套规则的好处通俗说有三个一是避免重复加载父加载器加载过的类子加载器不会重复加载二是保证核心类不能被篡改比如你自己写一个java.lang.String扔到classpath即使编译能过双亲委派也会让Bootstrap先把标准String加载了你的“李鬼”根本没有执行机会三是安全性更有保障核心API的访问边界不会被随意突破。面试里经常追问的一个点是**什么情况下双亲委派会失效**最典型的场景是JDBC的驱动加载——DriverManager在rt.jar里由Bootstrap加载但它要调用的MySQL驱动实现却在classpath下的第三方jar包里Bootstrap根本加载不到。这时候就引入了线程上下文类加载器Thread Context ClassLoader通过Thread.currentThread().getContextClassLoader()来破坏双亲委派链让“上层”的类能回调“下层”的加载器去加载实现类。**SPI机制Service Provider Interface**就是这么运作的。1.3 打破双亲委派Tomcat和SPI背后的真相除了JDBC这种SPI场景Web容器是破坏双亲委派的另一大阵营。以Tomcat为例它需要保证一个Tomcat里部署两个不同版本的Spring应用互不影响还要保证应用之间的类隔离。如果走传统双亲委派所有应用的类都交给同一个Application ClassLoader加载版本冲突必然炸锅。Tomcat的做法是给每个Web应用一个独立的WebAppClassLoader实例它优先加载自身WEB-INF/classes和WEB-INF/lib下的类加载不到才委托给父加载器。这实际上是**“逆向”了双亲委派**——子加载器先下手为强。这里有一个值得记住的教训因为Tomcat类加载体系复杂线上经常遇到NoClassDefFoundError或者诡异的版本冲突问题。排查思路上除了看依赖树还要考虑是不是同一个jar被多个classloader加载了多次。用-verbose:class参数启动或者在代码里临时打印Class.forName(...).getClassLoader()能帮你快速定位是哪个加载器在作祟。还有个高频面试题**Class.forName和ClassLoader.loadClass有什么区别**前者默认会执行初始化即触发clinit而后者默认只做加载不执行初始化。JDBC驱动注册用的就是Class.forName(driverClassName)因为它要驱动类里的静态代码块主动向DriverManager注册自己。2. 字节码技术亲手读懂JVM的语言类加载看似玄乎其实入口就是那一堆字节码文件。字节码是JVM的“机器语言”不懂字节码很多JVM层面的问题你永远只能靠猜。这一节我们从javap开始一步步学会“阅读”它。2.1 为什么要逼自己看懂字节码三个字值不值。你可以不手写字节码但你一定要能读懂它。理由有三第一排查问题需要。比如线上突然出现NullPointerException但报错行号对应的代码明明不可能为空这时候打开字节码一看问题往往出在编译器自动生成的代码上比如switch对String的匹配、lambda表达式生成的invokedynamic指令。我之前遇到过一起奇怪的NPE其实是对switch字符串做hashCode()匹配时目标引用为null导致的。第二理解语法糖的本质。Java的foreach、自动装箱、泛型擦除、字符串拼接背后全是字节码层面的巧妙操作。你以为的“简简单单一句话”编译器在背后可能生成了几十条指令。第三读懂框架原理。Spring的AOP、MyBatis的Mapper代理、Lombok的注解处理器全都在操作字节码或者直接生成字节码。你理解了字节码再去看框架源码很多“魔法”瞬间祛魅。2.2 用javap扒开一个类的“底裤”写一段最简单不过的代码public class Hello { public static void main(String[] args) { String s hello jvm; System.out.println(s); } }然后在命令行执行javac Hello.java javap -c -v Hello你会看到大量的输出。先挑关键指令看看public static void main(java.lang.String[]); Code: 0: ldc #7 // String hello jvm 2: astore_1 3: getstatic #9 // Field java/lang/System.out:Ljava/io/PrintStream; 6: aload_1 7: invokevirtual #15 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 10: return每条指令后面基本都跟着常量池的索引。比如ldc #7的意思是从常量池第7号位置取出常量“hello jvm”并压入操作数栈astore_1是把栈顶引用存到局部变量表索引为1的位置getstatic获取静态字段System.outinvokevirtual调用实例方法println。这里你能直观地看到操作数栈和局部变量表是怎么配合的——JVM的指令集本质上是一个基于栈的架构。这也解释了另一个面试高频题为什么局部变量表要预留this的位置因为实例方法的第0个局部变量槽位固定是this。javap -v还会输出常量池的完整信息。这一步比较枯燥但当你排查NoSuchMethodError这类错误时对照一下异常信息里的方法描述符和常量池里的描述符往往能瞬间定位到是依赖冲突导致版本不匹配。2.3 ASM与ByteBuddy用代码生成代码会读字节码只是第一步真正的“生产力”在于动态生成字节码。做Java服务端开发你一定用过Spring AOP它的底层不是反射而是一套动态代理机制JDK动态代理基于接口生成$Proxy类CGLIB则通过ASM生成目标类的子类字节码。ASM是一个直接操作字节码的库核心API包括ClassReader、ClassWriter、MethodVisitor等。它的性能极好但API设计非常底层手写容易出错。比如给一个类增加方法你不但要写对指令序列还要处理好局部变量表和操作数栈的平衡——栈深度计算错误生成出来的类在验证阶段就会被JVM拒绝。如果是做业务开发我更推荐直接用ByteBuddy。它的API友好太多了生成一个子类可能就是几行代码的事Class? dynamicType new ByteBuddy() .subclass(Object.class) .method(ElementMatchers.named(toString)) .intercept(FixedValue.value(Hello ByteBuddy!)) .make() .load(Hello.class.getClassLoader()) .getLoaded(); Object instance dynamicType.getDeclaredConstructor().newInstance(); System.out.println(instance.toString());这段代码动态生成了一个继承Object的类重写了toString方法让它固定返回字符串。底层依然是字节码操作但你对开发人员暴露出来的语义变得非常直观。关于字节码生成我一直强调一个排查点如果你在JDK高版本尤其是JDK 17使用老版本的CGLIB或ASM极容易遇到IllegalAccessError、UnsupportedClassVersionError或者ExceptionInInitializerError。原因通常是老库生成的字节码不满足新版JVM的强封装校验比如模块系统对不同包的访问控制。解决方案很直接升级ASM版本或者切换到ByteBuddy而不是试图修改JVM参数绕过。3. 内存模型JMM多线程下的内存“交通规则”如果说类加载和字节码解决的是“类怎么来、长什么样”的问题JMMJava Memory Model解决的就是“多线程读写共享数据时如何保证一致性”的问题。这部分是并发编程的理论根基也是面试重灾区。3.1 主内存与工作内存线程间傻傻分不清的数据拷贝先明确一个容易混淆的点JMM和JVM运行时数据区内存结构不是一回事。运行时数据区是JVM规范里规定的物理区域划分堆、栈、方法区等而JMM是一个抽象的内存模型它定义了一组规则用来规范线程和内存之间的交互。JMM的规定可以概括成几条核心原则所有变量存储在主内存中。每条线程有自己的工作内存线程对变量的所有操作读取、赋值等都必须在工作内存中进行不能直接读写主内存中的变量。线程间变量值的传递需要通过主内存来完成。你用生活化场景来理解主内存是公司数据库工作内存是每个人电脑上的本地缓存。你改一条数据时先改自己本地的缓存然后同步回数据库别人读数据时先从数据库拉到自己的本地缓存再读。如果同步时机不对你改的数据别人看不到这就是可见性问题。这也就引出了并发编程的三大问题原子性、可见性、有序性。原子性可以通过synchronized、Lock、Atomic*类解决可见性可以靠volatile、synchronized和Lock解决有序性除了靠volatile、synchronized和Lock还需要理解指令重排序带来的影响。重排序是编译器、JIT、处理器为了优化性能而做出的指令调整在单线程下没问题多线程下就可能把一个“看似没问题”的程序变成有并发缺陷的程序。3.2 happens-before判定数据竞争的最高法则很多人学JMM卡在了“两个内存模型规则”和“六个原子操作”这些细节上太抽象。我建议换个角度直接掌握JMM制定的happens-before先行发生规则。这条规则的用途是如果两个操作满足happens-before关系那么前一个操作的结果对后一个操作是可见的且前一个操作的执行顺序排在后一个操作之前。规则有很多条常用的我列成表格规则名称说明典型例子程序次序规则同一个线程中书写在前的操作happens-before书写在后的操作单线程内代码顺序执行管程锁定规则一个unlock操作happens-before后面对同一个锁的lock操作synchronized加锁解锁volatile变量规则对一个volatile变量的写操作happens-before后面对这个变量的读操作volatile修饰的状态标志位线程启动规则Thread对象的start()方法happens-before此线程的每一个动作线程内能看到启动线程之前的数据变更线程终止规则线程中的所有操作happens-before对此线程的终止检测Thread.join()返回后能看到线程内所有变更传递性如果A happens-before BB happens-before C那么A happens-before C多个规则组合判定实际开发中90%的并发Bug都可以归结为“违反了某条happens-before规则”。比如经典的两阶段终止模式用一个volatile boolean标志位来控制线程停止就是因为volatile变量的写-读天然具备happens-before关系写线程修改标志、读线程检查标志时能保证写线程之前的所有共享变量修改都对读线程可见。我再举个反面案例。很多人写过一个带boolean stop标志的后台线程这个标志没有加volatile结果主线程把stop设为true后台线程却迟迟不退出。原因就是JIT优化时后台线程可能把stop的值一直缓存在工作内存中没有重新读取主内存。这就是典型的可见性问题。加volatile之后每次读都会强制到主内存拿最新值问题迎刃而解。3.3 volatile与synchronized的底层博弈我见过太多人背概念“volatile保证可见性和有序性不保证原子性synchronized三者都保证”。但一到实际场景就不知道选谁。先看synchronized。它的底层依赖Monitor锁机制。在HotSpot虚拟机里每个对象都有一个Monitor与之关联。当多个线程同时访问同步代码块时只有一个线程能持有Monitor进入临界区其他线程阻塞等待。JDK 6之后JVM对synchronized做了大量优化引入了偏向锁、轻量级锁、重量级锁的升级路径。这也是为什么现代JDK里简单场景下synchronized性能已经不输ReentrantLock。再看volatile。它的语义有两条保证被修饰变量的可见性一个线程修改了这个变量的值新值对其他线程立即可见。禁止指令重排序编译器和处理器不会把volatile变量读写操作前后的指令随意重排。注意它不保证复合操作的原子性。比如经典的count就算count加了volatile多线程下依然会丢更新。volatile最常见的应用场景是状态标志位比如我前面提的两阶段终止模式。还有单例模式双重检查锁DCLpublic class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }这里instance为什么不加volatile就不行关键在于new Singleton()不是原子操作它实际分三步分配内存、初始化对象、把引用指向内存。如果不禁止重排序理论上第2步和第3步可能被调换——线程A执行了“分配内存”和“把引用指向内存”但对象还没初始化完线程B进来发现instance ! null直接拿去用就拿到了一个半初始化的对象。加了volatile之后JVM保证这个变量的读写全流程上禁止这类重排序。**一句话总结volatile和synchronized的选择策略只需要保证一个线程写、多个线程读的标志位场景用volatile既有读又有写、需要保证复合操作原子性的共享数据场景用synchronized或者其他锁机制。**这个原则我用了很多年几乎没有选错过。4. 运行时数据区与对象的一生搞清楚了类怎么加载、线程怎么访问共享数据接下来把目光转向JVM内部的内存布局。这一节内容同样是面试必考更重要的是它直接关联到OOM和GC调优。4.1 五大内存区域的职责划分与异常JVM规范把运行时数据区划分为以下几个区域程序计数器Program Counter Register记录当前线程正在执行的字节码指令地址。这是唯一一个不会发生OOM的内存区域也是线程私有的。因为JVM的多线程是线程轮流切换、分配处理器执行时间来实现的任何一个确定的时刻一个处理器只会执行一条线程中的指令所以每条线程都需要独立的程序计数器互不影响。虚拟机栈VM Stack线程私有生命周期与线程一致。它描述的是Java方法执行的内存模型每个方法执行时JVM都会同步创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。如果线程请求的栈深度大于虚拟机允许的深度抛StackOverflowError如果栈容量允许动态扩展但无法申请到足够内存则抛OutOfMemoryError。本地方法栈Native Method Stack为虚拟机使用到的Native方法服务。HotSpot直接把本地方法栈和虚拟机栈合二为一了平时我们基本感知不到它的存在。Java堆Heap所有线程共享的内存区域存放对象实例。垃圾收集器的主要战场就在这块。堆可以处于物理上不连续、逻辑上连续的空间。如果堆中没有内存完成实例分配并且堆也无法扩展时会抛OutOfMemoryError。方法区Method Area存储已被虚拟机加载的类型信息、常量、静态变量、JIT编译后的代码缓存等。JDK 8以前方法区用永久代PermGen实现JDK 8之后改为元空间Metaspace直接使用本地内存。这也是为什么JDK 8以后-XX:MaxPermGen参数被废弃改成了-XX:MaxMetaspaceSize。关于堆和栈的比例性能调优时经常用到这些参数参数作用示例-Xms堆初始大小-Xms512m-Xmx堆最大大小-Xmx1g-Xmn新生代大小-Xmn256m-XX:NewRatio老年代与新生代比例-XX:NewRatio2表示老年代新生代 2:1-XX:SurvivorRatioEden与Survivor比例-XX:SurvivorRatio8表示Eden:S0:S1 8:1:1-XX:MaxMetaspaceSize元空间最大值-XX:MaxMetaspaceSize256m4.2 对象的内存布局与访问定位在HotSpot虚拟机中对象在堆中的内存布局分三块对象头Header、实例数据Instance Data、对齐填充Padding。对象头包含两部分信息Mark Word存储对象自身的运行时数据比如哈希码、GC分代年龄、锁状态标志、线程持有的锁等。这部分在32位和64位虚拟机中长度不同但设计上尽量用极少的空间存储尽量多的信息。这就是Synchronized锁升级的基础——锁状态就记录在对象头里。类型指针Klass Pointer对象指向它的类元数据的指针JVM通过这个指针来确定这个对象是哪个类的实例。不过如果是数组对象对象头里还会多一块记录数组长度的区域。实例数据部分是对象真正存储的有效信息也就是程序代码中定义的各种类型字段内容包括父类继承的。对齐填充不是必然存在的它只是起占位符的作用。HotSpot要求对象起始地址必须是8字节的整数倍所以对象大小不够8字节倍数时需要靠对齐填充补全。关于对象的访问定位主流有两种方式句柄访问堆中划分一块句柄池栈上的reference存储句柄地址。好处是对象移动时GC时整理内存只需要修改句柄池里的指针reference不用改。直接指针访问reference直接存储对象地址好处是访问速度快少一次指针定位。HotSpot默认采用直接指针访问方式。4.3 GC与内存参数把OOM扼杀在摇篮里对象在堆里“生死轮回”离不开垃圾收集器GC。很多人一说GC就头大记不住各种收集器的区别。我从实际使用的角度给你一个筛选思路单核小内存场景Serial Serial Old简单可靠停顿虽长但可控。多核、追求低延迟G1Garbage First是目前绝大多数服务端应用的默认选择。JDK 9以后G1成为默认垃圾收集器。它把堆划分成多个Region可以做到可预测的停顿时间模型。超大堆、追求高吞吐ZGC和Shenandoah适合堆内存几十GB以上的场景。ZGC的核心设计是染色指针和读屏障能实现几乎不影响应用线程的并发收集。不管是哪种收集器调优的核心不是“调GC参数”而是减少对象的无效创建。很多OOM的根源不是参数给太小而是代码里存在内存泄漏或大量对象的无意义堆积。比如把大对象存进static集合忘记清理。使用ThreadLocal后没有调用remove()配合线程池复用线程造成“内存泄漏”。使用String.intern()在JDK 7把字符串缓存放进了堆滥用会导致元空间或堆内存膨胀。我在项目里给新人定的规矩是**GC参数原则上不动先把代码写干净。**真到需要调整时优先关注-Xms和-Xmx是否相等减少运行期堆扩展开销以及-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path这两个参数先把OOM现场保存下来再说。5. 实战排查类加载与内存问题的“病理诊断”前面四节把原理讲得差不多了这一节是压轴重头戏专门解决实际工作中高频撞上的几个坑。我按亲身踩坑经历整理尽量让大家少走弯路。5.1 “找不到或无法加载主类”到底是谁的锅这个报错太经典了经典到我在团队里几乎每周都要看到一次。搜索热词里也有两个真实案例一个是运行DolphinScheduler时提示错误: 找不到或无法加载主类 org.apache.dolphinscheduler.standaloneserver一个是Eclipse启动Tomcat时提示错误: 找不到或无法加载主类 org.apache.catalina.startup.Bootstrap。这类报错的本质是**类加载器沿着classpath找了一圈愣是没找到你指定的主类。**排查路径很固定第一确认类全限定名是否正确。是不是包名写错了是不是类名大小写不对。Java对大小写敏感standaloneserver和standAloneServer是两个完全不同的类名。第二确认classpath里确实有这个类。最简单的方式# 列出jar包内容 jar tf xxx.jar | grep -i 类名 # 或者用javap直接看 javap -classpath xxx.jar org.apache.dolphinscheduler.standaloneserver.StandaloneServer第三检查JDK版本是否匹配。有些jar包是高版本JDK编译的低版本JVM根本读不了那类字节码报的错往往不是ClassNotFoundException而是UnsupportedClassVersionError但翻译成中文提示时可能变成“找不到主类”。第四看环境变量。JAVA_HOME、PATH、CLASSPATH是否配错。Eclipse这类IDE里还要检查项目的JRE配置是不是指向了一个空目录或错误路径。还有一类隐藏极深的坑**主类所在jar包在classpath里存在但依赖的传递jar包缺失。**比如org.apache.catalina.startup.Bootstrap在catalina.jar里但它依赖的jakarta.servlet-api不在运行时classpath中JVM加载Bootstrap类失败时也会报“找不到或无法加载主类”。我总结了一套排错口诀**先看类名拼写再看classpath三看JDK版本四看依赖完整性。**按这个顺序九成问题都能定位。5.2 内存分析工具箱jps、jmap、jstack、Arthas排查JVM问题有一整套命令行工具链。这些工具我能用它们解决线上问题比任何图形化工具都快。先记住一个前提不知道进程ID一切白搭。jps就是查JVM进程的jps -l # 输出12345 com.example.Main然后是jstat查看JVM统计信息重点是GC情况jstat -gcutil 12345 1000 10 # 每隔1秒输出一次共10次 # S0 S1 E O M CCS YGC YGCT FGC FGCT GCT看到O那一列老年代使用率持续高位不下降基本可以断定老年代对象堆积严重要么是内存泄漏要么是Major GC频率跟不上对象晋升速度。jmap用来导出堆内存快照或者查看堆信息jmap -heap 12345 jmap -dump:live,formatb,fileheap.bin 12345导出heap.bin之后用Eclipse MAT或者JProfiler分析很快能找到是哪些对象占了大头。这里有个经验线上导出堆快照一定要加-dump:live它会先触发一次Full GC只保留存活对象文件体积小分析起来也更有针对性。jstack用来输出线程快照jstack 12345 thread_dump.txt排查死锁、线程池满、CPU飙高问题这个命令是主力。比如CPU飙高时用top -Hp 12345找到占用CPU最高的线程ID转成十六进制再到thread_dump.txt里搜这个十六进制ID就能定位到具体是哪段代码在疯狂执行。如果线上环境不方便用这些传统工具那一定要试试Arthas。它是阿里开源的Java诊断工具已经成了我线上排查的“瑞士军刀”。它的dashboard命令一眼扫过线程、内存、GC情况trace命令可以精确定位方法调用耗时的细节watch命令可以动态观察方法入参出参。最关键的是它不需要重启应用直接attach到目标进程就能用。5.3 开发期OOM防范IDEA与测试环境的JVM参数设置最后说一个所有Java开发者都经历过的痛开发环境或测试环境一不小心就OOM。搜热词里那句“设置IDEA的JVM运行内存的大小防止开发测试时出现OOM的问题”简直是我自己初学时的真实写照。IDEA里设置JVM运行内存入口在Help - Edit Custom VM Options打开后是一个idea64.vmoptions文件核心参数如下-Xms128m -Xmx1024m -XX:ReservedCodeCacheSize512m -XX:UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB50我个人的建议是-Xmx不要随便拉到好几个G因为你本机还要跑其他服务。一般开发项目给-Xms256m -Xmx2048m足够用了加大之后IDE卡顿不明显反而可能拖垮整个系统。真要跑超大工程优先考虑给IDE分配4G以内的堆然后加一条-XX:UseG1GC用G1收集器。在跑Spring Boot本地启动时千万不要忽略应用本身也要配JVM参数。启动配置文件里加上java -Xms256m -Xmx512m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/app.hprof -jar app.jarHeapDumpOnOutOfMemoryError这个参数建议从开发到生产一以贯之地打开。它能在OOM发生时自动导出堆快照这个快照就是你排查问题的最宝贵现场证据。没有这个参数OOM发生后进程直接退出你连复盘的机会都没有。关于测试环境我有一次惨痛教训测试环境跑着一堆微服务每个服务都只配了默认堆大小结果高峰期内存直接被打爆全部OOM崩溃。后来我统一给每个服务脚本加上了-Xms256m -Xmx256m让堆大小固定避免动态伸缩带来的性能抖动同时配合-XX:MaxMetaspaceSize256m限制元空间防止动态生成类把内存拖垮。实战下来稳定性提升非常明显。还有个小技巧如果测试环境经常莫名其妙发生OOM但又不想每次盯着堆栈日志可以在启动参数加-XX:ExitOnOutOfMemoryError让JVM在OOM发生时自动退出配合容器的自动重启策略把“半死不活的服务”变成“快速恢复的服务”。这个参数在生产环境慎用但在非核心的测试服务上非常好使。经验沉淀下来就一句话JVM调优和技术选型是建立在“能看懂问题现场”的基础之上的。我见过太多人盲目在网上抄一段GC参数就贴到生产环境结果不但没解决问题反而把原本还能扛住的服务整挂。正确路径永远是先复现、拿到堆栈、分析数据再决定要不要动参数、动哪个参数。如果这篇文章能让你在遇到类加载报错、内存溢出时第一时间想到“哦这个我熟”那这几千字就没白写。 深入理解JVM：类加载、字节码与内存模型全解析
先问个问题你身边有多少Java开发者写了好几年代码遇到ClassNotFoundException就加依赖碰到OOM就改-Xmx被问到“类加载过程分几步”就开始含糊我见过太多这样的案例包括几年前的我。说实话JVM这块内容属于典型的“地基知识”——平时不显山不露水一旦线上出问题排查思路是否清晰全靠这些基础撑场子。这篇笔记是JVM学习系列的第三篇聚焦两个绕不开的核心板块类加载与字节码技术、内存模型JMM。前一个是搞懂“.class文件怎么变成活生生的对象”后一个是搞懂“多线程环境下数据怎么安全地穿梭于内存”。无论你是准备面试、在做性能优化还是单纯想摆脱“面向搜索编程”这篇都值得花半小时慢慢读。我会尽量用实际场景和踩坑经历来讲少讲空洞理论。1. 类加载机制从.class到JVM的完整旅程类加载这块很多人背得滚瓜烂熟“加载、验证、准备、解析、初始化”但真让他解释“准备阶段到底干了什么”就卡壳了。这节我们不只是过流程我会结合字节码反编译和实际报错把每个阶段的前因后果讲透。1.1 一个类的“一生”类加载的五大阶段JVM里的类加载不是一个瞬间动作而是一条流水线。整条流水线包括加载Loading、验证Verification、准备Preparation、解析Resolution、初始化Initialization后面还有使用和卸载但重点是这五个阶段。加载阶段做三件事通过类的全限定名获取定义此类的二进制字节流将字节流所代表的静态存储结构转化为方法区的运行时数据结构在内存中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据的访问入口。注意“通过全限定名获取二进制字节流”没规定必须从ClassPath读所以才有后续那么多花活从ZIP包读、从网络读、运行时动态生成、由其他文件生成比如JSP转Class。这也是为什么像CGLIB、ByteBuddy这类库能存在的根本前提。验证阶段是安全的第一道防线。JVM要保证字节流符合规范不会危害自身安全。这个阶段包括文件格式验证、元数据验证、字节码验证、符号引用验证。说白了就是检查你是不是拿一堆乱写的字节码来糊弄它。这个阶段在开发期经常被忽略但因为一些高版本JDK默认开启了严格校验你如果用了太老的字节码生成库反而会在这里栽跟头——这个后面讲字节码技术时再展开。准备阶段是很多人理解最容易跑偏的地方。官方定义是为类变量static修饰的变量分配内存并设置零值。什么概念public static int value 123;在准备阶段结束后value的值是0不是123。123要到初始化阶段执行clinit方法时才会真正赋值。但有一个例外如果静态字段被final修饰且是编译期常量比如public static final int value 123;准备阶段就会直接赋值为123。解析阶段是把常量池内的符号引用替换为直接引用的过程。符号引用就是一组描述目标的字面量直接引用就是指向目标的指针、相对偏移量或者能间接定位到目标的句柄。这里不展开太深你只需知道早期绑定比如invokestatic指令调用静态方法在解析阶段就能完成而动态绑定比如invokevirtual调用实例方法要等运行时才能确定具体方法。初始化阶段才是真正执行类构造器clinit方法的时刻。虚拟机会保证在初始化前父类已经初始化完毕如果多线程同时初始化一个类JVM会加锁保证只有一个线程能执行clinit其他线程必须等待。这也是为什么静态代码块里的耗时操作会成为多线程环境下的隐藏性能瓶颈。1.2 双亲委派模型为什么必须“先问爸爸”搞清楚双亲委派之前得先认识JVM自带的三个类加载器类加载器加载路径主要职责Bootstrap ClassLoader$JAVA_HOME/lib下的核心类库rt.jar等加载JDK核心类C实现Platform/Extension ClassLoader$JAVA_HOME/lib/ext加载扩展类JDK9后改为平台类加载器Application ClassLoaderclasspath环境变量指定的路径加载我们自己写的类及第三方依赖双亲委派模型的规则很简单当一个类加载器收到类加载请求时它不会自己先去加载而是先把这个请求委派给父加载器每一层都是如此直到顶层Bootstrap。只有当父加载器反馈自己无法完成加载时子加载器才会尝试自己加载。这套规则的好处通俗说有三个一是避免重复加载父加载器加载过的类子加载器不会重复加载二是保证核心类不能被篡改比如你自己写一个java.lang.String扔到classpath即使编译能过双亲委派也会让Bootstrap先把标准String加载了你的“李鬼”根本没有执行机会三是安全性更有保障核心API的访问边界不会被随意突破。面试里经常追问的一个点是**什么情况下双亲委派会失效**最典型的场景是JDBC的驱动加载——DriverManager在rt.jar里由Bootstrap加载但它要调用的MySQL驱动实现却在classpath下的第三方jar包里Bootstrap根本加载不到。这时候就引入了线程上下文类加载器Thread Context ClassLoader通过Thread.currentThread().getContextClassLoader()来破坏双亲委派链让“上层”的类能回调“下层”的加载器去加载实现类。**SPI机制Service Provider Interface**就是这么运作的。1.3 打破双亲委派Tomcat和SPI背后的真相除了JDBC这种SPI场景Web容器是破坏双亲委派的另一大阵营。以Tomcat为例它需要保证一个Tomcat里部署两个不同版本的Spring应用互不影响还要保证应用之间的类隔离。如果走传统双亲委派所有应用的类都交给同一个Application ClassLoader加载版本冲突必然炸锅。Tomcat的做法是给每个Web应用一个独立的WebAppClassLoader实例它优先加载自身WEB-INF/classes和WEB-INF/lib下的类加载不到才委托给父加载器。这实际上是**“逆向”了双亲委派**——子加载器先下手为强。这里有一个值得记住的教训因为Tomcat类加载体系复杂线上经常遇到NoClassDefFoundError或者诡异的版本冲突问题。排查思路上除了看依赖树还要考虑是不是同一个jar被多个classloader加载了多次。用-verbose:class参数启动或者在代码里临时打印Class.forName(...).getClassLoader()能帮你快速定位是哪个加载器在作祟。还有个高频面试题**Class.forName和ClassLoader.loadClass有什么区别**前者默认会执行初始化即触发clinit而后者默认只做加载不执行初始化。JDBC驱动注册用的就是Class.forName(driverClassName)因为它要驱动类里的静态代码块主动向DriverManager注册自己。2. 字节码技术亲手读懂JVM的语言类加载看似玄乎其实入口就是那一堆字节码文件。字节码是JVM的“机器语言”不懂字节码很多JVM层面的问题你永远只能靠猜。这一节我们从javap开始一步步学会“阅读”它。2.1 为什么要逼自己看懂字节码三个字值不值。你可以不手写字节码但你一定要能读懂它。理由有三第一排查问题需要。比如线上突然出现NullPointerException但报错行号对应的代码明明不可能为空这时候打开字节码一看问题往往出在编译器自动生成的代码上比如switch对String的匹配、lambda表达式生成的invokedynamic指令。我之前遇到过一起奇怪的NPE其实是对switch字符串做hashCode()匹配时目标引用为null导致的。第二理解语法糖的本质。Java的foreach、自动装箱、泛型擦除、字符串拼接背后全是字节码层面的巧妙操作。你以为的“简简单单一句话”编译器在背后可能生成了几十条指令。第三读懂框架原理。Spring的AOP、MyBatis的Mapper代理、Lombok的注解处理器全都在操作字节码或者直接生成字节码。你理解了字节码再去看框架源码很多“魔法”瞬间祛魅。2.2 用javap扒开一个类的“底裤”写一段最简单不过的代码public class Hello { public static void main(String[] args) { String s hello jvm; System.out.println(s); } }然后在命令行执行javac Hello.java javap -c -v Hello你会看到大量的输出。先挑关键指令看看public static void main(java.lang.String[]); Code: 0: ldc #7 // String hello jvm 2: astore_1 3: getstatic #9 // Field java/lang/System.out:Ljava/io/PrintStream; 6: aload_1 7: invokevirtual #15 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 10: return每条指令后面基本都跟着常量池的索引。比如ldc #7的意思是从常量池第7号位置取出常量“hello jvm”并压入操作数栈astore_1是把栈顶引用存到局部变量表索引为1的位置getstatic获取静态字段System.outinvokevirtual调用实例方法println。这里你能直观地看到操作数栈和局部变量表是怎么配合的——JVM的指令集本质上是一个基于栈的架构。这也解释了另一个面试高频题为什么局部变量表要预留this的位置因为实例方法的第0个局部变量槽位固定是this。javap -v还会输出常量池的完整信息。这一步比较枯燥但当你排查NoSuchMethodError这类错误时对照一下异常信息里的方法描述符和常量池里的描述符往往能瞬间定位到是依赖冲突导致版本不匹配。2.3 ASM与ByteBuddy用代码生成代码会读字节码只是第一步真正的“生产力”在于动态生成字节码。做Java服务端开发你一定用过Spring AOP它的底层不是反射而是一套动态代理机制JDK动态代理基于接口生成$Proxy类CGLIB则通过ASM生成目标类的子类字节码。ASM是一个直接操作字节码的库核心API包括ClassReader、ClassWriter、MethodVisitor等。它的性能极好但API设计非常底层手写容易出错。比如给一个类增加方法你不但要写对指令序列还要处理好局部变量表和操作数栈的平衡——栈深度计算错误生成出来的类在验证阶段就会被JVM拒绝。如果是做业务开发我更推荐直接用ByteBuddy。它的API友好太多了生成一个子类可能就是几行代码的事Class? dynamicType new ByteBuddy() .subclass(Object.class) .method(ElementMatchers.named(toString)) .intercept(FixedValue.value(Hello ByteBuddy!)) .make() .load(Hello.class.getClassLoader()) .getLoaded(); Object instance dynamicType.getDeclaredConstructor().newInstance(); System.out.println(instance.toString());这段代码动态生成了一个继承Object的类重写了toString方法让它固定返回字符串。底层依然是字节码操作但你对开发人员暴露出来的语义变得非常直观。关于字节码生成我一直强调一个排查点如果你在JDK高版本尤其是JDK 17使用老版本的CGLIB或ASM极容易遇到IllegalAccessError、UnsupportedClassVersionError或者ExceptionInInitializerError。原因通常是老库生成的字节码不满足新版JVM的强封装校验比如模块系统对不同包的访问控制。解决方案很直接升级ASM版本或者切换到ByteBuddy而不是试图修改JVM参数绕过。3. 内存模型JMM多线程下的内存“交通规则”如果说类加载和字节码解决的是“类怎么来、长什么样”的问题JMMJava Memory Model解决的就是“多线程读写共享数据时如何保证一致性”的问题。这部分是并发编程的理论根基也是面试重灾区。3.1 主内存与工作内存线程间傻傻分不清的数据拷贝先明确一个容易混淆的点JMM和JVM运行时数据区内存结构不是一回事。运行时数据区是JVM规范里规定的物理区域划分堆、栈、方法区等而JMM是一个抽象的内存模型它定义了一组规则用来规范线程和内存之间的交互。JMM的规定可以概括成几条核心原则所有变量存储在主内存中。每条线程有自己的工作内存线程对变量的所有操作读取、赋值等都必须在工作内存中进行不能直接读写主内存中的变量。线程间变量值的传递需要通过主内存来完成。你用生活化场景来理解主内存是公司数据库工作内存是每个人电脑上的本地缓存。你改一条数据时先改自己本地的缓存然后同步回数据库别人读数据时先从数据库拉到自己的本地缓存再读。如果同步时机不对你改的数据别人看不到这就是可见性问题。这也就引出了并发编程的三大问题原子性、可见性、有序性。原子性可以通过synchronized、Lock、Atomic*类解决可见性可以靠volatile、synchronized和Lock解决有序性除了靠volatile、synchronized和Lock还需要理解指令重排序带来的影响。重排序是编译器、JIT、处理器为了优化性能而做出的指令调整在单线程下没问题多线程下就可能把一个“看似没问题”的程序变成有并发缺陷的程序。3.2 happens-before判定数据竞争的最高法则很多人学JMM卡在了“两个内存模型规则”和“六个原子操作”这些细节上太抽象。我建议换个角度直接掌握JMM制定的happens-before先行发生规则。这条规则的用途是如果两个操作满足happens-before关系那么前一个操作的结果对后一个操作是可见的且前一个操作的执行顺序排在后一个操作之前。规则有很多条常用的我列成表格规则名称说明典型例子程序次序规则同一个线程中书写在前的操作happens-before书写在后的操作单线程内代码顺序执行管程锁定规则一个unlock操作happens-before后面对同一个锁的lock操作synchronized加锁解锁volatile变量规则对一个volatile变量的写操作happens-before后面对这个变量的读操作volatile修饰的状态标志位线程启动规则Thread对象的start()方法happens-before此线程的每一个动作线程内能看到启动线程之前的数据变更线程终止规则线程中的所有操作happens-before对此线程的终止检测Thread.join()返回后能看到线程内所有变更传递性如果A happens-before BB happens-before C那么A happens-before C多个规则组合判定实际开发中90%的并发Bug都可以归结为“违反了某条happens-before规则”。比如经典的两阶段终止模式用一个volatile boolean标志位来控制线程停止就是因为volatile变量的写-读天然具备happens-before关系写线程修改标志、读线程检查标志时能保证写线程之前的所有共享变量修改都对读线程可见。我再举个反面案例。很多人写过一个带boolean stop标志的后台线程这个标志没有加volatile结果主线程把stop设为true后台线程却迟迟不退出。原因就是JIT优化时后台线程可能把stop的值一直缓存在工作内存中没有重新读取主内存。这就是典型的可见性问题。加volatile之后每次读都会强制到主内存拿最新值问题迎刃而解。3.3 volatile与synchronized的底层博弈我见过太多人背概念“volatile保证可见性和有序性不保证原子性synchronized三者都保证”。但一到实际场景就不知道选谁。先看synchronized。它的底层依赖Monitor锁机制。在HotSpot虚拟机里每个对象都有一个Monitor与之关联。当多个线程同时访问同步代码块时只有一个线程能持有Monitor进入临界区其他线程阻塞等待。JDK 6之后JVM对synchronized做了大量优化引入了偏向锁、轻量级锁、重量级锁的升级路径。这也是为什么现代JDK里简单场景下synchronized性能已经不输ReentrantLock。再看volatile。它的语义有两条保证被修饰变量的可见性一个线程修改了这个变量的值新值对其他线程立即可见。禁止指令重排序编译器和处理器不会把volatile变量读写操作前后的指令随意重排。注意它不保证复合操作的原子性。比如经典的count就算count加了volatile多线程下依然会丢更新。volatile最常见的应用场景是状态标志位比如我前面提的两阶段终止模式。还有单例模式双重检查锁DCLpublic class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }这里instance为什么不加volatile就不行关键在于new Singleton()不是原子操作它实际分三步分配内存、初始化对象、把引用指向内存。如果不禁止重排序理论上第2步和第3步可能被调换——线程A执行了“分配内存”和“把引用指向内存”但对象还没初始化完线程B进来发现instance ! null直接拿去用就拿到了一个半初始化的对象。加了volatile之后JVM保证这个变量的读写全流程上禁止这类重排序。**一句话总结volatile和synchronized的选择策略只需要保证一个线程写、多个线程读的标志位场景用volatile既有读又有写、需要保证复合操作原子性的共享数据场景用synchronized或者其他锁机制。**这个原则我用了很多年几乎没有选错过。4. 运行时数据区与对象的一生搞清楚了类怎么加载、线程怎么访问共享数据接下来把目光转向JVM内部的内存布局。这一节内容同样是面试必考更重要的是它直接关联到OOM和GC调优。4.1 五大内存区域的职责划分与异常JVM规范把运行时数据区划分为以下几个区域程序计数器Program Counter Register记录当前线程正在执行的字节码指令地址。这是唯一一个不会发生OOM的内存区域也是线程私有的。因为JVM的多线程是线程轮流切换、分配处理器执行时间来实现的任何一个确定的时刻一个处理器只会执行一条线程中的指令所以每条线程都需要独立的程序计数器互不影响。虚拟机栈VM Stack线程私有生命周期与线程一致。它描述的是Java方法执行的内存模型每个方法执行时JVM都会同步创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。如果线程请求的栈深度大于虚拟机允许的深度抛StackOverflowError如果栈容量允许动态扩展但无法申请到足够内存则抛OutOfMemoryError。本地方法栈Native Method Stack为虚拟机使用到的Native方法服务。HotSpot直接把本地方法栈和虚拟机栈合二为一了平时我们基本感知不到它的存在。Java堆Heap所有线程共享的内存区域存放对象实例。垃圾收集器的主要战场就在这块。堆可以处于物理上不连续、逻辑上连续的空间。如果堆中没有内存完成实例分配并且堆也无法扩展时会抛OutOfMemoryError。方法区Method Area存储已被虚拟机加载的类型信息、常量、静态变量、JIT编译后的代码缓存等。JDK 8以前方法区用永久代PermGen实现JDK 8之后改为元空间Metaspace直接使用本地内存。这也是为什么JDK 8以后-XX:MaxPermGen参数被废弃改成了-XX:MaxMetaspaceSize。关于堆和栈的比例性能调优时经常用到这些参数参数作用示例-Xms堆初始大小-Xms512m-Xmx堆最大大小-Xmx1g-Xmn新生代大小-Xmn256m-XX:NewRatio老年代与新生代比例-XX:NewRatio2表示老年代新生代 2:1-XX:SurvivorRatioEden与Survivor比例-XX:SurvivorRatio8表示Eden:S0:S1 8:1:1-XX:MaxMetaspaceSize元空间最大值-XX:MaxMetaspaceSize256m4.2 对象的内存布局与访问定位在HotSpot虚拟机中对象在堆中的内存布局分三块对象头Header、实例数据Instance Data、对齐填充Padding。对象头包含两部分信息Mark Word存储对象自身的运行时数据比如哈希码、GC分代年龄、锁状态标志、线程持有的锁等。这部分在32位和64位虚拟机中长度不同但设计上尽量用极少的空间存储尽量多的信息。这就是Synchronized锁升级的基础——锁状态就记录在对象头里。类型指针Klass Pointer对象指向它的类元数据的指针JVM通过这个指针来确定这个对象是哪个类的实例。不过如果是数组对象对象头里还会多一块记录数组长度的区域。实例数据部分是对象真正存储的有效信息也就是程序代码中定义的各种类型字段内容包括父类继承的。对齐填充不是必然存在的它只是起占位符的作用。HotSpot要求对象起始地址必须是8字节的整数倍所以对象大小不够8字节倍数时需要靠对齐填充补全。关于对象的访问定位主流有两种方式句柄访问堆中划分一块句柄池栈上的reference存储句柄地址。好处是对象移动时GC时整理内存只需要修改句柄池里的指针reference不用改。直接指针访问reference直接存储对象地址好处是访问速度快少一次指针定位。HotSpot默认采用直接指针访问方式。4.3 GC与内存参数把OOM扼杀在摇篮里对象在堆里“生死轮回”离不开垃圾收集器GC。很多人一说GC就头大记不住各种收集器的区别。我从实际使用的角度给你一个筛选思路单核小内存场景Serial Serial Old简单可靠停顿虽长但可控。多核、追求低延迟G1Garbage First是目前绝大多数服务端应用的默认选择。JDK 9以后G1成为默认垃圾收集器。它把堆划分成多个Region可以做到可预测的停顿时间模型。超大堆、追求高吞吐ZGC和Shenandoah适合堆内存几十GB以上的场景。ZGC的核心设计是染色指针和读屏障能实现几乎不影响应用线程的并发收集。不管是哪种收集器调优的核心不是“调GC参数”而是减少对象的无效创建。很多OOM的根源不是参数给太小而是代码里存在内存泄漏或大量对象的无意义堆积。比如把大对象存进static集合忘记清理。使用ThreadLocal后没有调用remove()配合线程池复用线程造成“内存泄漏”。使用String.intern()在JDK 7把字符串缓存放进了堆滥用会导致元空间或堆内存膨胀。我在项目里给新人定的规矩是**GC参数原则上不动先把代码写干净。**真到需要调整时优先关注-Xms和-Xmx是否相等减少运行期堆扩展开销以及-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/path这两个参数先把OOM现场保存下来再说。5. 实战排查类加载与内存问题的“病理诊断”前面四节把原理讲得差不多了这一节是压轴重头戏专门解决实际工作中高频撞上的几个坑。我按亲身踩坑经历整理尽量让大家少走弯路。5.1 “找不到或无法加载主类”到底是谁的锅这个报错太经典了经典到我在团队里几乎每周都要看到一次。搜索热词里也有两个真实案例一个是运行DolphinScheduler时提示错误: 找不到或无法加载主类 org.apache.dolphinscheduler.standaloneserver一个是Eclipse启动Tomcat时提示错误: 找不到或无法加载主类 org.apache.catalina.startup.Bootstrap。这类报错的本质是**类加载器沿着classpath找了一圈愣是没找到你指定的主类。**排查路径很固定第一确认类全限定名是否正确。是不是包名写错了是不是类名大小写不对。Java对大小写敏感standaloneserver和standAloneServer是两个完全不同的类名。第二确认classpath里确实有这个类。最简单的方式# 列出jar包内容 jar tf xxx.jar | grep -i 类名 # 或者用javap直接看 javap -classpath xxx.jar org.apache.dolphinscheduler.standaloneserver.StandaloneServer第三检查JDK版本是否匹配。有些jar包是高版本JDK编译的低版本JVM根本读不了那类字节码报的错往往不是ClassNotFoundException而是UnsupportedClassVersionError但翻译成中文提示时可能变成“找不到主类”。第四看环境变量。JAVA_HOME、PATH、CLASSPATH是否配错。Eclipse这类IDE里还要检查项目的JRE配置是不是指向了一个空目录或错误路径。还有一类隐藏极深的坑**主类所在jar包在classpath里存在但依赖的传递jar包缺失。**比如org.apache.catalina.startup.Bootstrap在catalina.jar里但它依赖的jakarta.servlet-api不在运行时classpath中JVM加载Bootstrap类失败时也会报“找不到或无法加载主类”。我总结了一套排错口诀**先看类名拼写再看classpath三看JDK版本四看依赖完整性。**按这个顺序九成问题都能定位。5.2 内存分析工具箱jps、jmap、jstack、Arthas排查JVM问题有一整套命令行工具链。这些工具我能用它们解决线上问题比任何图形化工具都快。先记住一个前提不知道进程ID一切白搭。jps就是查JVM进程的jps -l # 输出12345 com.example.Main然后是jstat查看JVM统计信息重点是GC情况jstat -gcutil 12345 1000 10 # 每隔1秒输出一次共10次 # S0 S1 E O M CCS YGC YGCT FGC FGCT GCT看到O那一列老年代使用率持续高位不下降基本可以断定老年代对象堆积严重要么是内存泄漏要么是Major GC频率跟不上对象晋升速度。jmap用来导出堆内存快照或者查看堆信息jmap -heap 12345 jmap -dump:live,formatb,fileheap.bin 12345导出heap.bin之后用Eclipse MAT或者JProfiler分析很快能找到是哪些对象占了大头。这里有个经验线上导出堆快照一定要加-dump:live它会先触发一次Full GC只保留存活对象文件体积小分析起来也更有针对性。jstack用来输出线程快照jstack 12345 thread_dump.txt排查死锁、线程池满、CPU飙高问题这个命令是主力。比如CPU飙高时用top -Hp 12345找到占用CPU最高的线程ID转成十六进制再到thread_dump.txt里搜这个十六进制ID就能定位到具体是哪段代码在疯狂执行。如果线上环境不方便用这些传统工具那一定要试试Arthas。它是阿里开源的Java诊断工具已经成了我线上排查的“瑞士军刀”。它的dashboard命令一眼扫过线程、内存、GC情况trace命令可以精确定位方法调用耗时的细节watch命令可以动态观察方法入参出参。最关键的是它不需要重启应用直接attach到目标进程就能用。5.3 开发期OOM防范IDEA与测试环境的JVM参数设置最后说一个所有Java开发者都经历过的痛开发环境或测试环境一不小心就OOM。搜热词里那句“设置IDEA的JVM运行内存的大小防止开发测试时出现OOM的问题”简直是我自己初学时的真实写照。IDEA里设置JVM运行内存入口在Help - Edit Custom VM Options打开后是一个idea64.vmoptions文件核心参数如下-Xms128m -Xmx1024m -XX:ReservedCodeCacheSize512m -XX:UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB50我个人的建议是-Xmx不要随便拉到好几个G因为你本机还要跑其他服务。一般开发项目给-Xms256m -Xmx2048m足够用了加大之后IDE卡顿不明显反而可能拖垮整个系统。真要跑超大工程优先考虑给IDE分配4G以内的堆然后加一条-XX:UseG1GC用G1收集器。在跑Spring Boot本地启动时千万不要忽略应用本身也要配JVM参数。启动配置文件里加上java -Xms256m -Xmx512m -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/tmp/app.hprof -jar app.jarHeapDumpOnOutOfMemoryError这个参数建议从开发到生产一以贯之地打开。它能在OOM发生时自动导出堆快照这个快照就是你排查问题的最宝贵现场证据。没有这个参数OOM发生后进程直接退出你连复盘的机会都没有。关于测试环境我有一次惨痛教训测试环境跑着一堆微服务每个服务都只配了默认堆大小结果高峰期内存直接被打爆全部OOM崩溃。后来我统一给每个服务脚本加上了-Xms256m -Xmx256m让堆大小固定避免动态伸缩带来的性能抖动同时配合-XX:MaxMetaspaceSize256m限制元空间防止动态生成类把内存拖垮。实战下来稳定性提升非常明显。还有个小技巧如果测试环境经常莫名其妙发生OOM但又不想每次盯着堆栈日志可以在启动参数加-XX:ExitOnOutOfMemoryError让JVM在OOM发生时自动退出配合容器的自动重启策略把“半死不活的服务”变成“快速恢复的服务”。这个参数在生产环境慎用但在非核心的测试服务上非常好使。经验沉淀下来就一句话JVM调优和技术选型是建立在“能看懂问题现场”的基础之上的。我见过太多人盲目在网上抄一段GC参数就贴到生产环境结果不但没解决问题反而把原本还能扛住的服务整挂。正确路径永远是先复现、拿到堆栈、分析数据再决定要不要动参数、动哪个参数。如果这篇文章能让你在遇到类加载报错、内存溢出时第一时间想到“哦这个我熟”那这几千字就没白写。