企业官网建设流程全解析

凌晨两点零三分，告警群弹出一条消息：订单服务CPU使用率98%，接口P99延迟从200ms飙升到3s。我登录线上机器，先敲了top，发现Java进程几乎吃掉了一整颗核；再用jstat看了一眼GC情况，Full GC数据每隔几秒就跳一次——内存回收已经跑不过对象分配的速度了。那一刻我意识到，JVM从来不只是面试题，它是Java程序真实运行的那台“机器”。你平时写下的每一行代码，new的每一个对象，起的每一个线程，最终都要在这台机器上跑。

这篇东西我会按自己排查问题的思路来写，不按教科书目录走。先讲清楚JVM的职责边界，再把运行时数据区、类加载、对象分配、GC回收器、调优工具、线程池这些内容串成一条完整链路。适合准备面试的人，也适合线上出问题不知道从哪下手的开发，以及想系统梳理一遍JVM但没时间啃大部头的朋友。

1. 先搞清楚：JVM到底是“什么”和“不是什么”

1.1 JVM的职责边界

很多人一提到JVM，第一反应是垃圾回收。这不算错，但太片面了。JVM是一台完整的虚拟机，它承担着加载字节码、校验字节码、解释执行或即时编译、内存管理、线程调度、与操作系统交互等一系列工作。垃圾回收只是其中的“内存管理”这一部分。

我平时检查一个Java进程，习惯把JVM看作四层结构：最外层是类加载子系统，负责把.class文件搬进来；中间是运行时数据区，也就是那几块内存区域；再往下是执行引擎，包括解释器和JIT编译器（如C1、C2）；最后才是垃圾回收系统。你遇到的大多数OOM、Full GC、CPU飙高，问题根源往往不在JVM本身，而在你写出来的代码和配置。JVM只是把问题暴露出来的那一层。

这个认知非常重要。因为如果你把JVM当成一个黑盒，出问题时就只能重启、加内存，运气好能混过去，但根本原因还在。反过来，如果你理解了JVM的职责边界，你会知道该去看堆、看栈、看GC日志，还是看类加载冲突。

1.2 JDK、JRE、JVM三者的关系

面试里高频出现的问题：JRE和JVM之间是什么关系？我用一个生活化的类比来记：JVM是灶台，JRE是厨房，JDK是整间餐厅。灶台负责真正把菜做熟，也就是运行Java字节码；厨房包含灶台和调料、锅碗瓢盆，相当于JVM加上核心类库；餐厅则在厨房之外，还配了菜谱和刀具，对应JDK里那些javac、jar、jps、jmap等开发工具。

一句话总结：JRE = JVM + 核心类库，JDK = JRE + 开发工具。开发环境装JDK，纯生产环境跑Java程序可以只装JRE，但实际线上部署多数时候还是用JDK，因为需要用诊断工具排查问题。

1.3 跨平台原理和“找不到JVM”的尴尬

Java的跨平台靠的是字节码和JVM分层。源码.java编译成.class字节码，字节码交给不同操作系统上的JVM解释执行或JIT编译成本地机器码。只要每个平台都有对应的JVM实现，你的程序就不用改代码。代价是JVM本身是“平台相关”的，Windows、Linux、macOS各有各的版本。

这里顺便说一个开发中很常见的问题：启动Java程序时报“no jvm could be found on your system”。我遇到十有八九是环境变量配错了。排查顺序很简单：

• 确认java -version能正常输出，不能输出说明JDK没装好或PATH没配。
• 检查JAVA_HOME是否指向JDK根目录，不是bin目录。
• 检查PATH里是否包含%JAVA_HOME%\bin（Windows）或$JAVA_HOME/bin（Linux/macOS）。
• 注意32位和64位混用的问题，DLL或so文件位版本不对也会报找不到。

还有一个坑：有些人改了JAVA_HOME之后没有重新开终端，当前会话里环境变量还是旧的。改完环境变量一定要重开一个终端窗口，这是所有环境变量类问题里最容易忽略的一步。

2. 运行时数据区：把“内存模型”真正看成一栋楼

2.1 五个运行时区域的分工与风险

运行时数据区是JVM执行Java程序时使用的内存划分，共分五块。先记一个总原则：堆和方法区是线程共享的，虚拟机栈、本地方法栈、程序计数器是线程私有的。线程共享的区域需要面对并发和GC，线程私有的区域随着线程创建和销毁自然分配和释放。

下面这张表我建议直接收藏，面试和排查问题都经常要回头看：

其中程序计数器是最容易被忽略的区域。它的作用就是记录当前线程执行到哪一条字节码指令。线程切换后，CPU能通过程序计数器恢复现场。因为它是“线程私有”的，所以不需要GC，也不会OOM。

2.2 堆内存为什么非要分代

堆是JVM管理的最大一块内存，几乎所有对象都在这里出生。为什么堆要分成新生代和老年代？根本原因是“大多数对象朝生夕死”。如果你的代码里创建了大量短命对象，它们很快就会“死亡”，把这些对象集中放在新生代，GC时只需要扫描这一小块区域，用复制算法快速清理，效率远高于扫描整个堆。

新生代内部又分成Eden区和两个Survivor区（S0、S1）。HotSpot默认比例是Eden:S0:S1 = 8:1:1。每次Minor GC后，存活对象从Eden和S0复制到S1，然后清空Eden和S0。也就是说，真正浪费掉的只有S1那10%的空间，比复制算法“对半划分”的50%浪费要小得多。

这个设计直接决定了对象分配的顺序：新对象优先分配在Eden区（如果能通过逃逸分析，可能直接在栈上分配，连堆都不进）；Eden满了触发Minor GC；Minor GC后仍然存活的对象进入Survivor；Survivor里年龄足够大，或者Survivor空间放不下时，才进入老年代。

2.3 虚拟机栈：一个栈帧就是一次方法调用

虚拟机栈描述的是Java方法执行时的内存模型。每次调用一个方法，JVM就创建一个栈帧压入栈中，方法执行完，栈帧出栈。栈帧里有四样东西比较重要：局部变量表、操作数栈、动态链接、方法出口。

局部变量表存放基本类型、引用类型和returnAddress类型；操作数栈是执行字节码指令时的工作区。给你看一个最直观的例子：执行int c = a + b这行代码，字节码层面大概是这样：

// a、b已经存放在局部变量表下标0和1 iload_0 // 将局部变量表下标0的值压入操作数栈 iload_1 // 将局部变量表下标1的值压入操作数栈 iadd // 弹出栈顶两个int相加，结果压回栈 istore_2 // 将栈顶结果存入局部变量表下标2

看不懂字节码没关系，只要理解操作数栈就像厨房台面，局部变量表是储物柜。所有计算都得把食材（变量值）从储物柜拿到台面（操作数栈）上操作，做完再放回去。理解这个，你就知道为什么局部变量表越大、操作数栈越深，单个栈帧占的内存越多。

栈相关的典型故障是StackOverflowError，最常见就是递归没有出口。但还有一个容易被忽略的场景：单个线程栈大小-Xss设置过大，在高并发下会迅速耗尽系统内存，因为每创建一个线程都要分配栈空间。默认-Xss在Linux x64下通常是1MB，如果业务确实需要很大栈深度再调大，不要盲目改。

2.4 方法区到元空间：一张改了很久的“签证”

方法区存放类信息、常量、静态变量、JIT编译后的代码缓存。在JDK 7及以前，方法区的实现叫“永久代”（PermGen），它在JVM堆之外，但大小受-XX:MaxPermSize限制。到了JDK 8，HotSpot把永久代彻底移除，用**元空间（Metaspace）**替代，并改用本地内存。

为什么非要换？我总结三个核心原因：

• 永久代大小难以准确预估，字符串常量池和类元数据稍微多一下就OOM，而且触发的是Full GC，代价很大。
• 永久代引入了不必要的GC复杂度，HotSpot需要专门写一套永久代回收逻辑。
• 为JRockit等虚拟机合并做铺垫，让HotSpot更容易实现统一。

元空间直接使用本地内存，默认情况下只受物理内存限制，所以“Metaspace OOM”反而少了，但如果你用了CGLIB、Spring等大量生成代理类的框架，还是可能因为类元数据过多而OOM。生产环境建议显式设置-XX:MaxMetaspaceSize，给它一个上限，避免本地内存被类元数据悄悄吃光。

2.5 直接内存：容易被当成“不存在”的堆外空间

直接内存不是JVM运行时数据区的一部分，但它常被NIO类使用。DirectByteBuffer通过unsafe.allocateMemory分配堆外内存，绕过堆内存的GC管理，适合大块数据读写和网络传输场景，比如Netty就大量使用直接内存。

这块内存由-XX:MaxDirectMemorySize控制，默认等于-Xmx。我见过一个比较隐蔽的线上故障：代码用Netty框架，但连接没释放，堆内存看起来正常，直接内存却一路涨到机器物理内存上限，最后进程被操作系统杀掉。这种问题用jmap看堆是看不出来的，需要查看NIO缓冲区数量或监控RSS内存。所以调优时别只盯着堆，堆外内存同样要纳入监控。

2.6 必须澄清：运行时数据区 ≠ Java内存模型

这可能是JVM话题里最容易被混淆的概念。平时说的“JVM内存模型”，有时候指“运行时数据区”，也就是上面讲的内存划分；但严格意义的Java内存模型（JMM，Java Memory Model）是另一套东西，定义的是多线程程序里共享变量的读写可见性规则，核心是volatile语义、synchronized语义、happens-before原则。

面试官如果问“介绍一下Java内存模型”，你可以先反问一句“您想听运行时数据区，还是JMM多线程模型？”这不是抬杠，而是体现你真懂区分。如果两个都能展开聊，那这个问题的分数基本就到手了。JMM典型的落地场景是DCL单例为什么需要volatile，以及为什么对long/double的读写不一定有原子性。

3. 类加载：JVM怎么“认识”你的.class文件

3.1 加载、链接、初始化三阶段

类加载机制看起来只是“把类文件读进来”，但它内部有三个阶段，每个阶段都有讲究：加载、链接、初始化。链接还可以细分为验证、准备、解析。

• 加载：通过全限定名找到.class字节码，读入内存，并生成一个java.lang.Class对象作为访问入口。加载阶段并不要求类已经初始化，甚至可以来自jar包、网络、动态代理生成的字节码。
• 验证：检查字节码文件格式、元数据、符号引用等合法性，防止恶意或错误的字节码破坏JVM。这步经常被忽略，但它很重要，ClassFormatError就是这一环节抛出来的。
• 准备：为类变量（static修饰的字段）分配内存并设置默认零值。这里有个高频考点：private static int x = 10;在准备阶段结束后，x的值是0，不是10。真正把10写进去发生在初始化阶段。
• 解析：把常量池里的符号引用替换为直接引用。可以理解为把“人名”解析成“电话号码”。
• 初始化：执行静态代码块和静态变量赋值，按照代码顺序执行。

我遇到过不少线上问题，根因都在“初始化”顺序上。比如静态代码块里抛了异常，类初始化失败，后续访问该类就会抛ExceptionInInitializerError或NoClassDefFoundError。这种问题看起来神出鬼没，实际上就是类加载的初始化阶段没有通过。

3.2 双亲委派模型：为什么默认不能被打破

JVM默认的类加载器有三级：启动类加载器（Bootstrap ClassLoader），负责加载JAVA_HOME/lib下的核心类；平台类加载器（Platform ClassLoader），JDK9后取代了扩展类加载器；应用类加载器（Application ClassLoader），负责加载classpath下的类。

双亲委派的核心规则：每个类加载器收到加载请求后，先把这个请求委派给父加载器，父加载器处理不了，才由自己去加载。这个设计的直接好处是保证核心类不被篡改。比如你自己写一个java.lang.String放到classpath里，双亲委派机制下，启动类加载器会先加载JVM自带的String，你的类加载请求根本轮不到应用类加载器，天然防止核心类被“同款替换”。

那有没有打破双亲委派的场景？有。典型的如JDBC：DriverManager是由启动类加载器加载的，但MySQL驱动Jar包在应用classpath下，启动类加载器不可能认识它。解决方案就是线程上下文类加载器，由驱动管理器委托当前线程上下文加载器去加载具体驱动实现。Tomcat等Web容器也会打破双亲委派，因为要支持同一个JVM里多个Web应用部署同一个类的不同版本。

理解双亲委派后，很多“ClassCastException：类转换异常”的诡异问题就好查了。同一个类，如果被两个不同类加载器各加载一次，它们的Class对象在JVM看来就是两个完全不同的类型，强转必炸。

3.3 常见类加载异常：怎么定位不靠猜

我总结了三种最常见的类加载相关故障，每个都对应不同的现象：

排查类加载问题，我常用的两个工具是启动参数-XX:+TraceClassLoading（打印类加载过程）和Arthas的classloader命令。Arthas能直接查看某个类的类加载器、加载来源jar包，还能查看不同类加载器的层级关系，比翻日志高效得多。

4. 对象的一生：从new到垃圾回收

4.1 对象的创建过程：一次new做了多少事

你写new Object()，JVM实际干了五件事：

1. 类加载检查：检查这个类是否已经被加载、解析、初始化过。如果没有，先走一遍类加载流程。
2. 分配内存：在堆上划分一块大小确定的空间。分配方式有两种：如果堆内存规整，用“指针碰撞”移动指针即可；如果内存碎片多，用“空闲列表”找合适大小的空闲块。GC算法决定了堆是否规整。
3. 内存空间置零：把分配到的内存初始化为默认零值，这样对象的实例字段不赋值也能有默认值。
4. 设置对象头：写入对象所属类的元数据指针、对象的哈希码（懒计算）、GC分代年龄、锁标志位等。
5. 执行构造方法：执行<init>方法，按代码里写的初始化逻辑给字段赋值。

其中第2步有一个并发安全问题：多个线程同时new对象，可能争抢同一块内存。HotSpot的解决方案是CAS加失败重试，以及TLAB（Thread Local Allocation Buffer）。TLAB就是每个线程在Eden区预分配一小块私有缓冲，线程先在自己的缓冲里分配对象，缓冲满了才去共享区分配并申请新的TLAB。这样绝大多数对象分配都不需要锁竞争，这也是为什么“new对象”在Java里非常廉价的原因之一。

4.2 对象的内存布局：一个Java对象到底占多少字节

一个Java对象在堆里由三部分组成：对象头、实例数据、对齐填充。对象头包含Mark Word和类型指针；Mark Word存哈希码、GC年龄、锁信息，32位下占4字节，64位下占8字节；类型指针指向类的元数据，默认开启指针压缩（-XX:+UseCompressedOops）后从8字节压到4字节。实例数据是字段值，对齐填充是为了让对象大小是8字节的整数倍，便于CPU寻址。

举个例子：一个只有int a字段的对象，在64位JVM开启压缩指针的情况下，对象头约12字节，实例数据4字节，共16字节，正好8字节对齐，不需要填充。如果再加一个long b，实例数据变成12字节，对象头12字节，总计24字节，依然对齐。这也是为什么小对象数量巨大时，对象头带来的内存开销非常可观——一个只有几个字段的小对象可能一大半都是对象头。

4.3 对象的访问定位：句柄和直接指针

当你在代码里持有一个对象引用，比如User user = new User()，这个user变量在栈上，它指向堆里的对象，但“指向”有两种实现方式：

• 句柄访问：堆里有个句柄池，引用先指向句柄，句柄里再存对象实例数据的地址和类型数据的地址。好处是GC移动对象时只需要修改句柄里的指针，引用本身不用变。
• 直接指针访问：引用直接指向对象地址，访问对象只需要一次寻址，但GC移动对象后要更新所有引用。

HotSpot使用直接指针方式，因为Java程序访问对象非常频繁，少一次指针定位性能更好。代价就是GC回收时需要更仔细地维护引用关系。

4.4 对象是怎么一步步走进老年代的

很多面试题问“对象什么时候进入老年代”，这其实是一个链条，把GC分代设计串起来了：

• 正常成长：对象在Eden出生，经历一次Minor GC后存活，年龄加1，进入Survivor。默认年龄加到15（-XX:MaxTenuringThreshold），进入老年代。
• 动态年龄判定：JVM不会傻等所有对象都到15岁。如果Survivor里相同年龄的对象大小总和超过Survivor空间的一半，年龄大于等于这个阈值的对象会直接进入老年代。这是为了那些“中等寿命”对象能尽早升到老年代，避免在Survivor之间反复复制。
• 大对象直接进老年代：可以通过-XX:PretenureSizeThreshold设置，大于阈值的大对象直接分配到老年代。为什么？大对象在Eden和Survivor之间复制成本很高，而且很容易撑满Survivor。但注意，这个阈值只对Serial和ParNew回收器有效，G1下行为不同。
• Survivor空间不足：Minor GC后存活对象太多，Survivor装不下，就会通过分配担保机制，把多余的对象直接放到老年代。

理解了这条链路，你就能解释“为什么我的老年代一直涨”：可能是大对象太多，可能是Survivor配置不合理，也可能是确实有对象生命周期长。方向就不会错。

4.5 如何判断一个对象“已死”

GC回收对象前，先要判断对象是否已经“不可达”。引用计数法是最直观的方案：每引用一次加1，失效减1，为0就回收。但循环引用问题直接判了它死刑：A引用B、B引用A，外部没有引用，计数却不为0，永远回收不了。

HotSpot用可达性分析：从一组称为GC Roots的根对象出发，向下遍历引用链，凡是不可达的对象都被判定为可回收。哪些对象可以作为GC Roots？主要有：

• 虚拟机栈（栈帧中局部变量表）里引用的对象。
• 方法区里静态属性引用的对象。
• 方法区里常量引用的对象。
• JNI（native方法）引用的对象。
• 活跃线程、synchronized锁持有的对象。

顺带说一句，Java里的引用分四种强度：强引用、软引用、弱引用、虚引用。强引用只要存在，被引用的对象永远不会被GC回收；软引用在内存不足时才回收；弱引用只要GC就回收；虚引用几乎等于没有引用，只是用来接收对象被回收的通知。做缓存的时候，“软引用+弱引用”是常见思路，但现在的Caffeine等缓存框架已经把这些细节封装好了，日常开发直接用框架即可。

5. GC回收器与回收算法：选对才是王道

5.1 三种基础算法，各有各的代价

GC的基础算法只有三种，所有回收器都是在它们基础上的工程化组合：

• 标记-清除（Mark-Sweep）：先标记所有可回收对象，再统一清理。最直观，但会产生大量内存碎片，后续大对象分配困难，可能提前触发Full GC。
• 标记-复制（Mark-Copy）：把内存分成两块，只在这两块之间复制存活对象。解决了碎片问题，但浪费空间。HotSpot在新生代用Eden和两个Survivor的组合，把浪费控制在10%左右。
• 标记-整理（Mark-Compact）：先标记存活对象，然后把这些对象向内存一端移动，直接清除边界外的空间。没有碎片，但移动对象需要更新引用，且需要Stop The World，停顿时间更长。

一个比较反直觉的结论是：没有一种算法在所有场景下最优。新生代对象存活率低，适合复制；老年代对象存活率高，适合标记-清除或标记-整理。这就是分代收集的理论基础。

5.2 回收器横向对比与选型

HotSpot历史上出现过很多回收器，我直接给结论：

CMS（Concurrent Mark Sweep）当年是为了“低延迟”而生的，名字里就带着“并发”。它的设计思路是用多次短停顿代替一次长停顿，减少业务线程冻结时间。但它有三个硬伤：对CPU资源敏感（并发阶段抢占CPU）、无法处理浮动垃圾（并发阶段的垃圾只能下次处理）、基于标记-清除会产生内存碎片。碎片严重时无法分配大对象，被迫Full GC，停顿可能比Parallel还严重。JDK 9开始，CMS被标记为废弃，慢慢退场。

G1为什么能成为默认？它的核心创新是把整个堆划分成多个大小相等的Region，不再要求物理上连续。G1可以跟踪每个Region的回收价值，在后台维护一个优先级列表，优先回收垃圾最多、成本最低的Region，从而“可预测停顿”。你可以通过-XX:MaxGCPauseMillis设置期望的最大停顿时间，比如200ms，G1会尽量向这个目标靠拢。但注意，这只是一个“软目标”，实际停顿还要看堆大小和对象分配速度。

ZGC则是走得更远的低延迟方案，通过染色指针和读屏障，把GC停顿压到10ms以内，甚至更低。但它对堆大小有要求，适合超大堆（几十GB甚至几TB）的低延迟场景。如果你的堆只有4GB，盲目上ZGC不一定比G1好，还会引入新的排查复杂度。

5.3 关键GC参数速查

直接给一张我做调优时常用的参数表，JDK9+注意日志参数已经变了：

这里强调一个经验：调JVM参数之前，一定要先有监控数据，没有GC日志就去“盲调”堆大小，和闭着眼睛拧螺丝没什么区别。生产环境至少要做到“OOM能出dump、GC有日志、关键指标有监控”，这比什么调优公式都重要。

6. JVM调优实战：从一次OOM的完整排查链路说起

6.1 案例背景：一次大促前的压测事故

我负责的一个订单查询服务，在大促前压测时表现非常诡异：接口TPS一上来，老年代占用就像坐了火箭，Full GC被频繁触发，每次Full GC之后老年代只下降一点点，然后又迅速涨满。整体表现就是“CPU飙高、接口超时、Zombie进程拖垮服务器”。

很多人的第一反应是“把堆调大，Full GC的频率就降下来了”。但这个思路在这里是错的，因为老年代上涨速度太快，就算堆从4GB调到8GB，也只是把“涨满”的时间从10分钟拖到20分钟，治标不治本。

6.2 工具链：按顺序出牌，别一上来就瞎猜

我定位这个问题的顺序很有代表性，分享给大家：

第一步是jps -l，列出当前机器上的Java进程，拿到目标服务的PID。不要用ps命令去猜哪个是Java进程，jps会直接列出JVM进程，包括主类名或jar包名。

第二步是jstat -gcutil <pid> 1000，每秒打印一次GC统计，观察Eden、Survivor、老年代的使用率和Full GC次数。我当时的输出显示full GC次数增长极快，而且Full GC之后老年代的占用率只回落了几个百分点，说明老年代里堆了大量无法回收的对象。

第三步是jmap -heap <pid>，看堆的配置和当前分区使用情况，确认不是启动参数配错。确认堆大小合理后，进入第四步：抓堆转储。

第四步是jmap -dump:format=b,file=heap.hprof <pid>，生成堆转储文件。注意，如果进程堆很大，这个操作本身会暂停应用一会儿，生产环境建议在业务低峰期做，或者用Arthas的heapdump命令，更灵活。

第五步用MAT（Memory Analyzer Tool）或VisualVM分析hprof文件。MAT的“Leak Suspects”报告能直接给出可疑对象。我当时看到的是一个ConcurrentHashMap里堆积了海量byte[]，每一个都有几百KB。

最后再用jstack看一下线程状态，确认同时有没有大量线程阻塞在同一个锁上。thread dump的分析要点：找WAITING和BLOCKED状态的线程，看它们在等什么锁。

6.3 根因与修复：问题最后出在代码上

MAT分析发现那个ConcurrentHashMap根本问题是缓存没有淘汰策略。业务代码每次查询都会把一个庞大的历史数据集合全量塞进缓存，但没有任何基于容量或时间的淘汰机制。数据量一旦涨到某个量级，老年代就会被这些缓存对象塞满。

修复也很简单直接：给缓存加上容量上限和过期策略；大字段改成按需加载，不再一次性全量缓存。上线后我再用jstat观察，Full GC从每分钟几十次直接降到几近于零，接口RT恢复正常。

这个案例能说明一个道理：调优的目的不是改参数，而是找到那个真正不合理的代码或设计。GC参数和堆大小只是最后的兜底手段。

6.4 用混沌注入验证监控和预案

问题修复之后，我一般会再做一步验证：用混沌工程工具主动制造故障，看监控和告警是否真的能第一时间发现。阿里开源的ChaosBlade支持JVM故障注入，比如模拟方法延迟、异常抛出，甚至直接触发Full GC：

# 模拟方法调用延时 blade create jvm --delay 300 --classname com.example.OrderService --methodname queryOrder # 模拟CPU满载 blade create jvm cpu --fullload --cpu-count 2 # 在测试环境模拟OOM blade create jvm oom --mode heap --area heap --size 512M

这类操作我用的时候有两条铁律：第一，只能在测试环境或预发环境做；第二，必须事先和团队约定演练时间段，否则容易误判为真实故障。混沌注入的价值在于，它能验证“当GC真的出问题、CPU真的飙高时，你的监控告警链路、人工排查SOP是否经得起考验”。能模拟故障，才能真正把“万一发生”变成“已经演练过”。

6.5 开发环境的JVM内存设置：别让IDEA成为OOM重灾区

热搜词里有一条“设置idea的jvm的运行内存的大小，防止开发测试时出现oom”，线下开发环境确实也值得说两句。IDEA本身运行在JVM上，项目越做越大，默认内存不够就会出现卡顿、直接卡死或者编译OOM。

在IDEA里，通过Help -> Edit Custom VM Options打开idea64.exe.vmoptions（Windows）或idea.vmoptions（macOS/Linux），我常用的配置：

-Xms1024m -Xmx4096m -XX:ReservedCodeCacheSize=512m -XX:MaxMetaspaceSize=1g -XX:+UseG1GC

如果使用Maven构建时出现java.lang.OutOfMemoryError: Java heap space，可以在MAVEN_OPTS环境变量里加大堆：

export MAVEN_OPTS="-Xms512m -Xmx2g"

Gradle用户则是在gradle.properties里配置：

org.gradle.jvmargs=-Xms512m -Xmx4g -XX:MaxMetaspaceSize=1g

这里要提醒一句：开发机内存设置不要贪大。你给IDEA分配8GB，自己电脑只有16GB，那操作系统、浏览器、数据库客户端都会被挤到交换分区去，反而更卡。根据机器物理内存，给IDEA分配总内存的四分之一到三分之一比较合理。

7. 线程池与JVM：最大线程数到底怎么定

7.1 线程不是“免费的”

每个Java线程默认都有独立栈空间，-Xss默认在Linux x64下约1MB。虽然这是虚拟内存，但线程多了，首先面临的是线程切换和内核管理开销，其次才受限于物理内存。一个并发1000线程的应用，光线程栈就可能在真实内存中占用几百MB甚至更多。

很多人有一个错误直觉：线程越多，处理越快。实际上当线程数超过CPU核心数，多出来的线程就是在排队等CPU。每条线程从运行态切换到等待态，再从等待态切换回运行态，都有上下文切换开销。线上系统出现“线程数很高、CPU很忙、但业务吞吐很低”时，往往不是因为线程不够，而是线程太多导致大量时间耗在切换上。

7.2 计算线程池大小：CPU密集和IO密集分开算

线程池核心参数不用背，但要会估算。业界有两个常用的经验公式：

• CPU密集型任务：线程数 = CPU核数 + 1。加1是为了在某个线程因为缺页中断等偶然因素被卡住时，还有一个额外线程保证CPU不闲。
• IO密集型任务：线程数 = CPU核数 * (1 + 等待时间 / 计算时间)。如果“等待时间 / 计算时间”不好估，经验值抄2倍到3倍CPU核数通常都不会太离谱。

比如你的接口要做一次本地计算，然后远程调一次RPC，RPC耗时100ms，本地计算10ms，等待和计算比是10比1，那线程数可以按CPU核数 * (1 + 10)来估。如果机器是8核，那大约88个线程。这个数量不是精确值，但比“往大了配”要靠谱得多。

7.3 “JVM剩余可用线程”这个说法的问题

热搜词里有一条“线程池设置最大线程数是JVM剩余可用线程”，我特意说一下，这个说法很有迷惑性，但它忽略了一个本质问题：线程池能创建多少线程，并不等于“应该创建多少线程”。JVM有足够的资源创建1000个线程，不代表你用1000个线程跑业务就是对的。

线程池设计要综合考虑四个变量：核心线程数、最大线程数、阻塞队列、拒绝策略。

• corePoolSize是“正常情况下同时工作的线程数”。
• maximumPoolSize是“队列满了之后最多能扩到的线程数”。
• workQueue决定了任务积压时怎么排队。
• RejectedExecutionHandler决定了队列和线程都满时，任务被怎么处理。

一个常见的生产错误是：核心线程设得很大，队列也设得很大，结果高峰期任务大量堆积在队列里，任务的等待时间越来越长，接口RT飙升，但线程池又一直出于“能处理”的假象而不触发拒绝策略。正确的做法是队列设一个合理上限，满了以后尽快触发拒绝策略，而不是无限堆积。比如用CallerRunsPolicy，让提交任务的线程自己执行被拒绝的任务，天然实现背压。

有条件的话，最好把线程池的指标（活跃线程数、队列长度、拒绝次数）接入监控，配合jstack才能回答“线程池是不是瓶颈”这个问题。

8. 面试与常见误区：考官想听的是思路，不是背诵

8.1 高频面试题串讲

JVM相关的面试题来来回回就那么几类，核心是这几组：

• 内存结构相关：运行时数据区分几块？哪些线程共享？哪些会OOM？对象在堆里如何布局。
• 类加载相关：双亲委派是什么？为什么要这样设计？怎么打破？有哪些常见异常。
• GC相关：GC Roots有哪些？对象什么时候进老年代？CMS和G1的区别？如何选择回收器。
• OOM实战：线上OOM怎么排查？堆转储文件怎么分析？怎么看GC日志。
• 调优相关：你的服务JVM参数怎么配的？为什么这样配？有没有实际调优案例。

面试官通常不会只问一个孤立问题，而是顺着你的回答不断追问。比如你答“G1把堆划分成Region”，他可能接着问“那G1怎么处理大对象？”。这类追问背后考察的是“你是在背还是真懂”。

8.2 一个值得学习的回答方式

如果你被问“JVM内存模型”，可以这么回答：

“您指的是运行时数据区还是Java内存模型JMM？这俩名字常被混用。如果是运行时数据区，JVM将内存划分为程序计数器、虚拟机栈、本地方法栈、堆、方法区，其中前三块线程私有，后两块线程共享。如果是JMM，那讲的是多线程下的可见性问题，核心是volatile和happens-before规则。”

这种回答有结构、有区分、有边界，比张口就背“程序计数器是当前线程执行的字节码行号”要强太多。面试官真正想听的，是你面对模糊问题时的梳理能力，而不是能否复述教科书。

8.3 我见过最多的四个误区

第一，OOM就加内存。这是最大的误区。很多时候OOM的根因是内存泄漏或者数据无限增长，不解决代码问题，加多少内存都是延迟爆炸时间。第二，-Xmx设得越大越好。堆越大，Full GC时停顿时间越长，经历过一次10GB堆Full GC的人应该都懂。第三，生产环境不加GC日志。没有日志等于没有证据，出问题只能重启，重启完一切线索都没了。第四，以为JMM就是内存结构。这个前面说过，概念混淆会导致你答非所问。

8.4 如果想深入，可以看哪些资料

如果你想系统深入，周志明写的《深入理解Java虚拟机：JVM高级特性与最佳实践（第3版）》是最经典的选择，很多面试官自己也看过这本书。但我的建议是：把这篇文章里的链路先跑通，动手抓一次线上或本地的堆转储，用MAT分析一次，再看书时会事半功倍。纸上谈兵永远是效率最低的学习方式。

我的个人体会是，JVM相关知识最怕“背结论”。背下所有默认参数不如理解一个对象从创建到回收的完整旅程；背下所有回收器的名字不如亲手抓一次dump分析出问题对象。真正吃透JVM的人，不是书背得多，而是线上问题遇到得多，并且每次都坚持把问题排查到根因。希望这篇文章能帮你在“排查到根因”的路上，少走几步弯路。