企业官网建设流程全解析

做Java开发，很多人在写了几年业务代码之后会碰到一个明显的瓶颈期：并发问题搞不透，线上OOM排查没思路，项目一启动就频繁GC却只能重启硬扛。这时候你去看任何一份进阶路线图，排在第一位的几乎都是同一个东西——JVM。作为Java进阶系列的第一篇，这篇文章我不会给你堆概念，而是站在一个调过线上生产问题、踩过无数坑的老开发角度，把JVM这套东西从头到尾捋一遍，讲清楚它到底是什么、为什么这么设计、以及你实际排查问题时该怎么下手。

不管你是刚工作一两年的新手，还是写了三五年业务代码想突破瓶颈的同学，只要你在用Java，JVM就是你绕不开的那个底层内核。理解了它，你才能明白为什么多线程要那样写，为什么内存会爆，为什么一段代码在不同运行环境下表现天差地别。这篇文章会从内存结构、类加载机制、垃圾回收、调优实战和问题排查五个层面展开，每一块都会给到可以落地的操作方法和经验心得。

1. JVM内存结构：进阶者的第一张地图

1.1 运行时数据区到底放什么

JVM在运行Java程序时，会把自己管理的内存划分成几个不同的区域，这些区域统称为运行时数据区。很多初学者刚接触这一块时会被各种名词搞晕，其实你只需要抓住一条主线：哪些区域是线程私有的，哪些区域是线程共享的。

线程私有的区域有三个：程序计数器、虚拟机栈、本地方法栈。这三个区域随着线程的创建而创建，随着线程的结束而销毁，不需要考虑垃圾回收的问题。线程共享的区域有两个：堆和方法区。这两个才是GC的主战场。

程序计数器是JVM中最小的内存区域，它记录的是当前线程正在执行的字节码指令地址。因为线程切换后需要恢复到原来的执行位置，所以每个线程必须有一个独立的程序计数器。这里有个冷知识：程序计数器是唯一一个不会抛出OutOfMemoryError的区域。

虚拟机栈就是我们常说的栈，它描述的是Java方法执行时的内存模型。每个方法从调用到执行完毕，对应着一个栈帧的入栈和出栈。栈帧里存储了局部变量表、操作数栈、动态链接、方法返回地址等信息。这个区域最常见的异常是StackOverflowError，当线程请求的栈深度超过虚拟机允许的最大深度时就会抛出。

本地方法栈和虚拟机栈的作用类似，区别在于虚拟机栈为Java方法服务，本地方法栈为native方法服务。HotSpot虚拟机直接把两者合并在了一起，所以你在实际开发中很少能感知到它们的区别。

堆是JVM管理的最大一块内存区块，几乎所有对象实例都在这里分配。堆也是垃圾收集器最主要的工作区域，这也是为什么大部分人提到JVM调优，核心就是在调堆的参数。堆在物理上可以是不连续的，但逻辑上是连续的，这个特性保证了我们可以通过-Xmx和-Xms灵活控制堆的大小。

方法区在JDK 8之前的实现叫永久代，JDK 8之后被元空间（Metaspace）取代。这里存储的是类信息、常量、静态变量、即时编译器编译后的代码缓存等数据。元空间最大的变化是不再占用JVM堆内存，而是使用本地内存，默认情况下上限取决于系统可用内存，这也避免了永久代经常出现的元空间OOM问题。

1.2 堆内存的划分和对象的一生

堆内部并不是统一的一片区域，而是按照对象的存活时长划分成了新生代和老年代。新生代又被进一步划分为一个Eden区和两个Survivor区（通常叫S0和S1）。这个划分不是拍脑袋决定的，而是基于一个重要的统计规律——绝大多数对象都是朝生夕死的。

你在代码中new出来的对象，首先会进入Eden区。Eden区满的时候，JVM会触发一次Minor GC，把存活的对象复制到S0区，并清空Eden。下次Minor GC时，会把Eden和S0中存活的对象一起复制到S1区，然后清空Eden和S0。每经历一次Minor GC存活下来的对象，年龄就加1。当年龄达到阈值（默认15，可以通过-XX:MaxTenuringThreshold调整），或者S区放不下时，对象就会被晋升到老年代。

还有两种情况对象会直接进入老年代。一种是大对象，比如一个超大数组或长字符串，直接进入老年代可以避免在新生代反复复制带来的开销。大对象的判定阈值可以通过-XX:PretenureSizeThreshold设置，但要注意我只在ParNew和Serial收集器下这个参数才有效。另一种是动态年龄判定：如果S区中相同年龄的所有对象大小总和超过S区空间的一半，那么年龄大于等于这些对象的对象将直接进入老年代，不需要等到最大年龄阈值。

老年代里存放的是长期存活的对象，它的GC频次比新生代低很多，但是一旦发生GC（Major GC或Full GC），停顿时间通常会更长。这就是为什么很多调优手段的底层逻辑都是让对象尽量在新生代就被回收掉，不要跑到老年代里去。

1.3 栈帧里到底发生了什么

你在IDE里打断点调试时，看到的面板一层一层的调用栈，对应的就是虚拟机栈里的栈帧。每调用一个方法，JVM就会在当前线程的虚拟机栈上压入一个新的栈帧，方法执行完或者抛出未捕获异常时，栈帧出栈。

一个栈帧包含四个核心部分。局部变量表存放方法参数和方法内定义的局部变量，它是一个索引数组，基本类型存值，引用类型存指针。操作数栈是JVM的工作区，所有计算的中间结果都在这里完成，比如执行a + b这条字节码指令，先把a压入操作数栈，再把b压入，最后执行iadd指令把两个值弹出并相加，再把结果压回去。动态链接指向运行时常量池中该方法的引用，支持多态的实现。返回地址记录方法调用方的执行位置，方法return时能知道该回到哪里继续执行。

理解了栈帧，你就能明白为什么递归过深会栈溢出。每次递归调用都会压入一个栈帧，而线程的虚拟机栈容量是有限的，默认在Linux x64下通常为1MB，压到容量耗尽自然就StackOverflowError了。有些同学面试被问到递归和循环的取舍时，只知道递归代码简洁但可能栈溢出，但原理就在这里。

1.4 从内存模型看OOM

说到OOM，大多数人都被线上故障轰炸过。要排查OOM，第一步不是看监控，而是先弄清楚是哪个区域溢出了，因为不同区域的OOM根本原因完全不同。

堆内存OOM是最常见的，报错信息类似java.lang.OutOfMemoryError: Java heap space。业务高峰期创建对象过猛、内存泄漏导致对象无法回收、堆设置太小都是可能的原因。元空间OOM报错是Metaspace，通常是动态生成大量类导致的，比如反射、CGLIB代理、JSP编译这些场景。直接内存OOM报错是Direct buffer memory，NIO中频繁分配堆外内存且没有释放就会出现。还有一种是线程相关的OOM，报错无法创建新的线程，这往往是操作系统线程数耗尽，解决办法是降低每个线程的栈容量或者减少线程数量，而不是调大堆内存。

定位思路其实很简单：发生OOM时先看日志里完整的异常栈信息，它会明确指出发生在哪个区域。如果是堆OOM，用内存分析工具加载堆转储文件，找到占用内存最大的对象，顺着引用链往上追踪就能定位到根因。这个流程后面我会展开讲，这里先记住一个原则——区分区域再排查，别在堆上瞎转。

2. 类加载机制：你真的了解.class怎么进来的吗

2.1 类加载的三个阶段

一个Java文件经过编译变成.class字节码后，要被JVM加载才能运行。类加载机制包含加载、连接、初始化三个阶段，连接阶段又细分为验证、准备、解析三步。很多人以为类加载就是读文件，其实远不止于此。

加载阶段做的事情是：通过类的全限定名获取定义此类的二进制字节流，把字节流代表的静态存储结构转换为方法区的运行时数据结构，然后在内存中生成代表这个类的Class对象，作为方法区这个类的各种数据的访问入口。注意，这里获取二进制字节流的来源不一定是.class文件，也可以通过ZIP包、网络、动态代理生成等方式。

验证阶段是为了确保字节流符合JVM规范、不会危害JVM自身的安全。这个阶段包括文件格式验证、元数据验证、字节码验证和符号引用验证。准备阶段为类变量分配内存并设置初始零值，注意这里是零值，比如int是0，引用类型是null，而不是代码中写的初始值。真正给静态变量赋代码中的值要到初始化阶段。解析阶段把常量池中的符号引用替换为直接引用，比如把类名变成具体的内存地址。

初始化阶段是类加载过程的最后一步，执行类构造器clinit方法，也就是执行代码中的静态变量赋值和静态代码块。触发初始化的时机有几种：遇到new、getstatic、putstatic、invokestatic字节码指令时；使用反射调用时；初始化子类时如果父类未初始化会先初始化父类；JVM启动时初始化包含main方法的主类。

2.2 双亲委派模型为什么这么设计

JVM中的类加载器按层级分为三类：启动类加载器（Bootstrap ClassLoader）、平台类加载器（Platform ClassLoader）和应用类加载器（Application ClassLoader）。启动类加载器负责加载JAVA_HOME/lib目录下JVM自身需要的类库，它由C++实现，是JVM的一部分。平台类加载器负责加载一些扩展相关的类，JDK 9之后改名为平台类加载器。应用类加载器负责加载classpath下的类，也就是我们业务代码里绝大部分类。

三层类加载器之间不是继承关系，而是组合复用关系，协作机制叫双亲委派模型。当一个类加载器收到加载请求时，它不会自己先去尝试加载，而是把请求委派给父类加载器，层层向上，直到最顶层的启动类加载器。只有父类加载器反馈自己无法完成加载时，子加载器才会自己去尝试加载。

为什么要这样设计？核心是安全。举个例子，如果你自己写了一个java.lang.String类并且放到classpath下，没有双亲委派模型的话，应用类加载器可能就把你的String给加载了，那整个JVM的字符串逻辑就全乱套了。有了双亲委派，加载String类时最顶层的启动类加载器会发现JAVA_HOME/lib下已经存在rt.jar中的String，直接返回父加载器的加载结果，你写的那份自定义String永远不会被加载。

另一个原因是避免重复加载。同一个类被不同加载器重复加载会导致类型不匹配问题，双亲委派保证了同一个Class对象在JVM中只被加载一次。

2.3 打破双亲委派的实际场景

双亲委派不是铁律，在实际框架中经常被打破。最典型的是Tomcat的WebAppClassLoader。一个Tomcat实例上可以部署多个Web应用，每个应用可能有不同版本的类库。双亲委派模型下，子加载器会优先让父加载器加载，这会导致版本冲突。Tomcat给每个Web应用单独创建了一个类加载器，它优先加载自己目录下WEB-INF/classes里的类，只有自己找不到时才委派给父加载器，这样每个应用都有自己的类隔离空间。

SPI（服务提供者接口）是另一个打破场景。Java的SPI机制允许第三方提供服务实现，比如JDBC驱动。JDK核心的java.sql.DriverManager类由启动类加载器加载，但它要调用第三方驱动实现类，而这些实现类在classpath下需要应用类加载器加载。启动类加载器无法加载应用类，这就出现了反向加载的需求，于是引入了线程上下文类加载器来解决，把启动类加载器无法完成的加载请求反向委派给应用类加载器。

还有热部署场景。比如IDEA里改了代码自动生效，本质是创建了一个新的类加载器来加载更新后的类，因为JVM中同一个类加载器对同一个全限定名的类只会加载一次，要想加载新版本必须换一个全新的加载器。理解了这一点，你在做热部署功能时就能明白为什么更换类加载器比传统重新加载类更彻底。

3. 垃圾回收：JVM最核心的能力

3.1 对象怎么判断生死

垃圾回收的第一步，就是要判断哪些对象可以被回收。早期JVM用过引用计数法，每个对象维护一个计数器，当计数器为0就回收。但这个方法存在致命缺陷——无法处理循环引用。A引用了B，B也引用了A，它们俩的计数器都不是0，但外界已经没有任何引用了，这俩对象就该被回收却回收不了。

所以现代JVM采用可达性分析算法。从一组称为GC Roots的根对象出发，通过引用链遍历所有可达对象，凡是不可达的对象都判定为可回收。GC Roots包括：虚拟机栈中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象、以及被synchronized锁持有的对象。

JAVA中引用类型一共有四种，按强度依次递减：强引用、软引用、弱引用、虚引用。普通的new赋值就是强引用，只要强引用还在，对象永远不会被回收。软引用用SoftReference包装，在系统将要发生OOM之前，JVM会先把软引用关联的对象回收掉，适合做缓存。弱引用用WeakReference包装，在下一次GC时不管内存够不够都会回收，ThreadLocal的key就是用弱引用的。虚引用用PhantomReference包装，它不能通过get获取对象，作用在于对象被回收时收到一个系统通知，常用于堆外内存的回收管理。

这里要特别注意ThreadLocal的内存泄漏问题。ThreadLocalMap的entry继承了WeakReference，所以key是弱引用，但value是强引用。ThreadLocal对象被外部置为null后，key会被回收，但value还强引用着，如果线程长期存活，value就一直无法回收。这也是为什么阿里开发规范强制要求使用ThreadLocal后必须调用remove清理。

3.2 分代回收与垃圾收集器选型

整个JVM的垃圾回收建立在分代假说之上：绝大多数对象生命周期极短，少数对象会存活较长时间。于是就有了新生代和老年代的划分，以及对应的收集器。

具备新生代收集功能的收集器主要是Serial、ParNew和Parallel Scavenge。Serial是单线程收集器，GC时必须暂停所有用户线程，但简单高效，适合单核CPU或桌面应用。ParNew可以简单看作Serial的多线程版本，在新生代并行回收，常配合CMS使用。Parallel Scavenge的特点是关注吞吐量，适合后台计算任务。

老年代收集器有Serial Old和Parallel Old，分别是Serial和Parallel Scavenge的老年代版本。整个JDK 8默认的组合是Parallel Scavenge加Parallel Old，这是一个面向吞吐量的组合，适合大部分服务端应用。

CMS是第一代里程碑式的并发收集器，它实现了并发标记清理，目标是缩短停顿时间。CMS在老年代收集阶段采用标记-清除算法，因此会产生内存碎片。CMS在并发收集时如果老年代空间不足，会退化为Full GC，用Serial Old进行单线程全堆回收，停顿非常长。

G1是JDK 9之后默认的收集器，它把堆划分为多个大小相等的Region，新生代和老年代不再是物理连续的区域，而是逻辑概念。G1能做到可预测的停顿时间模型，用-XX:MaxGCPauseMillis设置目标停顿时间。兼顾了吞吐量和低延迟，目前是大内存多核服务端的首选。更新的ZGC能做到十毫秒以内停顿，但大部分业务场景其实用不上，G1已经足够了。

3.3 三色标记与并发标记的坑

CMS和G1在可达性分析时都采用三色标记法来标记存活对象。对象被分为三种颜色：白色表示未访问过，灰色表示自身被访问过但引用的对象还未被访问完，黑色表示自身和引用的对象都访问完了。

并发标记最大的坑是漏标问题。想象这个场景：对象B是黑色的，它持有了对象C的引用，同时C和A之间存在引用关系。执行过程中，A到C的引用被删除了，同时B新增了对C的引用。这时候并发标记已经扫过了B，但还没扫过A，那么C虽然是可达的，却可能被错误标成白色，下次GC时就被回收了。这是致命问题，因为回收了一个还在被使用的对象。

解决漏标有两种思路：增量更新和原始快照。CMS用的是增量更新，记录下黑色对象新增的引用，等标记结束后重新扫描这些引用。G1用的是原始快照（SATB），在GC开始时保存对象的引用关系快照，后续引用变了也没关系，按照快照的图继续标记，把这种变化记录下来，相当于把漏掉的对象补救回来。理解了这个区别，你就明白为什么G1在并发标记阶段比CMS更不容易出问题。

3.4 CMS和G1的对比

如果把CMS和G1放在一起对比，很多刚接触的同学会觉得G1全面碾压CMS，其实不完全对。CMS的优点是并发收集停顿短，适合中小堆场景，但是它有两大痛点：内存碎片化和并发失败。并发失败的后果是退化为Serial Old，停顿时间飙升。G1则通过Region划分和可预测停顿模型解决了这两个痛点，并且在堆较大的场景下优势明显。

G1的GC过程分为Young GC、并发标记周期、混合回收和Full GC。Young GC阶段，G1会选择需要回收的多个Region组成回收集，复制存活对象到新的Region，整个过程是可以预测停顿的。并发标记周期类似CMS的并发标记，最后计算每个Region的回收价值和成本。混合回收阶段，除了新生代Region，还会选择一些回收价值高的老年代Region一起回收。如果混合回收后对象占用的空间仍然超过堆内存的预定阈值，则会触发Full GC回退。

实际选型建议：如果堆大小在4GB以下，停顿要求没有极端到毫秒级，CMS照样可以胜任。如果堆大于8GB，或者RTO要求高，优先选G1。JDK 11及以上的版本，如果追求极低停顿，可以试试ZGC，但要接受它占用更多CPU资源。

4. JVM调优实战：从配置到排查

4.1 常用参数速查表

JVM参数分为三类：标准参数、-X参数和-XX参数。标准参数以-开头，比如-version、-server，所有JVM都支持。-X参数并不是标准参数但在HotSpot中通用，比如-Xms、-Xmx。真正做调优时我们大部分操作的是-XX参数。

下面这几组参数是使用频率最高、线上环境几乎必配的：

-Xms和-Xmx设置不同的值，JVM启动时会先分配较小的堆，再逐步扩展到最大值。这在业务流量忽高忽低的场景下会有性能抖动，因为堆扩容和缩容都涉及GC。所以线上建议两个值设置相同，避免动态扩容缩容。

参数怎么设不是靠拍脑袋。核心原则是：堆大小要能容纳活跃对象并留有余量；新生代不能太小，否则对象频繁晋升老年代导致频繁Full GC；也不能太大，否则老年代过小同样危险。经验值是新生存代占堆的1/3到1/4，通过NewRatio和SurvivorRatio搭配调整。

4.2 一次典型的调优流程

我在一个模拟项目中遇到过这么一个问题：一个订单网关服务，堆内存8GB，运行高峰时段Full GC每五分钟一次，每次停顿时间在3到5秒。因为GC停顿，接口超时率飙升，整个网关接近不可用。

排查第一步先看GC日志。配置了-XX:+PrintGCDetails -XX:+PrintGCDateStamps参数后用jstat观察，发现Minor GC很频繁，但每次GC后Eden区很快又满了。再看对象晋升情况，发现每次Minor GC后都有大量对象晋升到老年代，导致老年代迅速膨胀。

为什么对象会大量晋升？看代码发现这是一个用了大量Spring Bean的业务逻辑，新请求大量创建临时对象，Eden区设置的偏小，对象还没来得及在Eden区被回收就被迫晋升。同时SurvivorRatio设置的过大，Survivor区根本装不下存活对象，直接绕过年龄阈值大批晋升到老年代。

调整方案很简单：把-Xms和-Xmx固定为8GB不变，把NewRatio从2调整到1，让新生代和老年代各占4GB。然后调SurvivorRatio从8降到4，给Survivor区更大的空间。最后把G1的-XX:MaxGCPauseMillis从200ms下调到100ms，让G1更频繁地做Young GC控制停顿。

调整后跑了一个多小时，Full GC频率从每五分钟一次降到每半小时一次，GC停顿从3秒以上降到800毫秒以内。这个案例说明一个道理：很多Full GC问题不是需要扩容，而是对象分配的比例配置不合理。

4.3 排查工具怎么用

JVM调优和问题排查离不开工具。哪些是必须掌握的命令行工具，我列一下最常用的：

jps是JVM进程状态工具，列出当前机器上正在运行的Java进程。排查问题时第一件事就是jps找到目标进程PID。jstat用于监视JVM各种运行时状态信息，最常用的是jstat -gcutil PID 1000，每秒打印一次GC情况，包含Young GC次数、Full GC次数、各区域占用比例、GC耗时等指标，用来判断GC频率是否异常。jmap用于导出堆内存映像和查看堆信息。jmap -heap PID查看堆配置和当前使用情况，jmap -dump:format=b,file=heap.hprof PID导出堆快照，供MAT或JProfiler分析。jstack查看线程快照，排查死锁和线程阻塞时是神器。jcmd是一个综合工具，可以用来替代大部分jmap和jstack的功能。

图形化工具方面，VisualVM适合本地开发调试，Arthas是线上排查利器，不用重启应用就能动态观测方法调用、实时查看内存占用、甚至反编译线上代码。我在排查线上问题时，用Arthas的频率比传统命令行工具高很多，特别是trace命令查看慢方法调用链路，dashboard一键看全局GC和内存状态，非常方便。

5. 常见问题与排查技巧实录

5.1 线上频繁Full GC怎么定位

频繁Full GC是最常见的线上问题，表现形式是接口变慢、CPU飙高、监控面板的GC曲线拉满。原因基本逃不出几类：堆内存设置过小、内存泄漏、大对象过多、晋升阈值不合理、元空间频繁扩容触发Full GC。

排查步骤我建议按顺序来。第一步，jstat -gcutil观察Full GC频率以及回收前后的内存占用。如果每次Full GC后老年代占用依然很高，说明有对象无法释放，指向内存泄漏。第二步，导出堆快照jmap -dump，用MAT分析。重点看支配树找最大的对象，以及对象的引用链。第三步结合业务代码定位可疑的持有者。如果是第三方框架的对象占用很大，需要查对应的缓存配置。

有一类隐蔽的问题值得单独提一下：String.intern滥用。Java 7之后String.intern会把字符串放入堆中而不是永久代，如果用它做了大量字符串缓存，堆会被极速撑爆。这种问题从堆快照上能看到大量重复的String对象。

5.2 内存泄漏的典型场景

内存泄漏不像OOM那样瞬间爆发，它是缓慢累积的，最终表现形式往往还是Full GC越来越频繁直到OOM。从我的经验看，最容易踩的坑有这几类：

静态集合类。HashMap被static修饰，持续往里put数据，这个集合永远无法释放。线程池使用不当，任务对象里引用大对象，线程长期存活导致引用链不释放。数据库连接、网络连接、IO流资源未关闭，尤其在使用第三方连接池时，记得要正确调用close方法还回池里。

ThreadLocal没remove，前面已经详细说过，value强引用不会被回收。连接池缓存对象过多，比如数据库连接池的preparedStatement缓存设置不合理。Listener和回调注册没取消，观察者模式中注册了监听器但对象销毁时没有移除，长期累积也会造成泄漏。

5.3 栈溢出与死锁

栈溢出问题比较直接，通常是递归没有终止条件或者递归深度过大。但有的时候问题比较隐蔽，比如某些框架的AOP代理调用链很长，每个代理都会增加栈帧深度。遇到这种问题，用jstack看线程栈就能定位到。

死锁问题在Java层面也有典型表现。两个线程各自持有对方需要的锁并且互相等待，谁都不愿意释放。排查死锁用jstack最有效，它会检测到死锁并打印出死锁线程的完整信息，直接告诉你哪两个线程、哪两个锁、在哪个方法上出了问题。实际开发中，用jstack不仅能看到死锁还能看到线程的各种状态，包括WAITING、BLOCKED、RUNNABLE，配合业务日志很快能定位线上卡顿的原因。

5.4 避坑建议

这几年的排查经历让我总结出几条铁律，希望对你有帮助。

第一，先监控再调优。不要凭感觉改参数，先采集GC日志、内存曲线和线程数据，拿到证据再动手。第二，一次只改一个参数。改完做压测或者观察一段时间，确认效果后改下一个。多个参数一起改，出了问题根本不知道是哪个引起的。第三，不要盲目照抄网上的配置。不同业务、不同硬件、不同JVM版本，最优参数完全不同。第四，配置-XX:+HeapDumpOnOutOfMemoryError这行参数一定要加上，线上出OOM时没有堆转储文件你只能靠猜。第五，监控要用起来。至少能把GC频率、堆内存使用量、线程数这几个指标纳入监控，配合告警，问题可以在爆发前被发现。

最后分享一个我自己的习惯：每次上线新版本，我都会保留旧的GC日志并且对比上线前后的GC指标变化。新代码可能引入内存增长或者GC异常，对比日志是最快的发现方式。JVM本身不复杂，复杂的是运行在上面的业务代码。把基础原理搞透，再配合一套标准的排查流程，线上问题大多能在半小时内定位。这篇是进阶系列的开头，后续我会接着写并发编程、性能优化和线上实战专题，每一步都会有真实案例支撑，希望能带你真正跨过进阶那道坎。