【9.Tomcat底层剖析与性能优化】6.2.1 JVM优化

好的，我们来深入详细地探讨一下 Tomcat 性能优化中至关重要的一环——JVM 优化。

JVM 是 Tomcat 运行的基石，其配置直接影响 Tomcat 的吞吐量、延迟和稳定性。不当的 JVM 设置是导致性能问题（如频繁卡顿、响应慢、内存溢出）最常见的原因之一。

一、核心优化目标

JVM 调优的核心目标可以归结为三点，通常被称为“不可能三角”，我们需要根据应用特性做出权衡：

低延迟 (Low Latency)：尽可能减少垃圾回收（GC）导致的应用程序暂停时间（STW – Stop-The-World）。这对用户体验至关重要的应用（如实时交易、Web交互）是关键。高吞吐量 (High Throughput)：最大化应用程序在单位时间内处理业务逻辑的比率。GC 开销占比越小，吞吐量越高。适合后台运算、数据分析等场景。最小内存占用 (Small Footprint)：尽可能减少 JVM 进程占用的总内存量。

对于大多数 Web 应用，优化顺序通常是：首先保证稳定性（不发生 OOM），然后在延迟和吞吐量之间根据业务特点做权衡。

二、关键优化参数及配置

JVM 参数通常在 Tomcat 的启动脚本中设置。Linux 系统下是 bin/catalina.sh，Windows 是 bin/catalina.bat。推荐创建一个 setenv.sh（或 setenv.bat）文件来存放这些参数，便于管理。

1. 堆内存（Heap Memory）设置：最基础的优化

堆是 JVM 中最大的一块内存区域，几乎所有对象都在这里分配。它是 GC 发生的“主战场”。

参数：
-Xms：初始堆大小。-Xmx：最大堆大小。
优化建议：
-Xms 和 -Xmx 必须设置为相同的值。例如：-Xms4g -Xmx4g。为什么？ 防止 JVM 在运行时动态调整堆大小，这是一个昂贵的操作，会导致性能波动。设置相同值后，堆在启动时就被固定，消除了调整开销。设置多大？ 需要根据系统总内存和监控数据来定。一个经验法则是：设置为系统可用内存的 70%~80%，剩下的留给操作系统、线程栈、非堆内存（Metaspace）以及其它系统进程。例如，一台 8G 的机器，可以设置为 -Xms6g -Xmx6g。切勿设置得过大，否则会导致长时间的 GC 甚至 “Stop-The-World”。

2. 垃圾收集器（Garbage Collector）选择：权衡的核心

选择不同的 GC 器就是在直接权衡“延迟”和“吞吐量”。

JDK 8 及以前：

Parallel GC (吞吐量优先器)：

目标：最大化应用程序的吞吐量。特点：新生代和老年代都使用多线程进行垃圾回收，但会发生长时间的 STW 暂停。参数：-XX:+UseParallelGC (新生代) / -XX:+UseParallelOldGC (老年代，JDK8默认开启)适用场景：后台处理、科学计算，对延迟不敏感的应用。

CMS GC (低延迟优先器，已废弃)：

目标：减少 GC 暂停时间。特点：大部分回收过程与应用程序线程并发进行，减少了 STW 时间，但会产生碎片，且 CPU 敏感。参数：-XX:+UseConcMarkSweepGC注意：在 JDK 14 中被移除，不推荐在新项目中使用。

G1 GC (官方推荐的全能型选手)：

目标：在延迟和吞吐量之间取得良好平衡，是大堆（>4G）应用的默认首选。特点：将堆划分为多个 Region（区域），通过预测模型选择回收价值最大的区域优先收集（Garbage First）。能提供相对 predictable 的暂停时间。参数：-XX:+UseG1GC关键调优参数：
-XX:MaxGCPauseMillis=200：设置目标最大暂停时间（毫秒）。G1 会尽力达成这个目标（但不保证）。这是一个软目标，设置得太低（如50ms）会导致GC更频繁，反而降低吞吐量。200ms 是一个不错的起点。-XX:InitiatingHeapOccupancyPercent=45：触发 Mixed GC（混合回收）的堆占用阈值。默认45%，可以适当降低（如35%）来让GC更早启动，以防并发模式失败（Concurrent Mode Failure）。

JDK 11+：

ZGC 和 Shenandoah：超低暂停时间收集器，目标是将 STW 暂停控制在 10ms 以下，甚至亚毫秒级，且暂停时间不随堆大小增长而增加。参数：
ZGC: -XX:+UseZGCShenandoah: -XX:+UseShenandoahGC
适用场景：超大堆（数十GB乃至TB级别）、对延迟极其敏感的应用（如金融交易系统）。如果使用 JDK 11+，强烈建议评估这些新GC器。

建议：对于大多数 Tomcat Web 应用，从 -XX:+UseG1GC 开始。

3. 元空间（Metaspace）设置：防止内存缓慢泄漏

Metaspace 取代了 JDK 8 以前的 Permanent Generation（永久代），用于存储类的元数据。

参数：
-XX:MetaspaceSize：初始大小。-XX:MaxMetaspaceSize：最大大小。
优化建议：
必须设置 -XX:MaxMetaspaceSize，例如 -XX:MaxMetaspaceSize=256m。如果不设置，Metaspace 会一直增长直到耗尽系统内存。如果应用动态生成大量类（如使用 Spring、Hibernate 等框架或动态代理），需要适当调大这个值。频繁的 Full GC 如果是由 Metaspace 不足引起的，就需要增加这个设置。

4. 线程栈大小（Thread Stack Size）

每个线程都会占用一定的栈内存用于存储调用栈帧、局部变量等。

参数：-Xss优化建议：
默认值在 Linux/x64 上是 1MB。对于线程数较多的应用（Tomcat 线程池maxThreads=200，就会创建200个线程），总线程栈内存开销是 200 * 1MB = 200MB，这可能会挤占堆内存。在保证不出现 StackOverflowError 的前提下，可以适当减小线程栈大小。例如：-Xss256k。这对减少总内存占用很有帮助。

5. 垃圾回收日志（GC Logging）：优化的“眼睛”

没有GC日志，优化就是盲人摸象。必须开启GC日志来分析GC行为。

参数 (JDK 8/9+ 风格)：
JDK 8及以前:


-Xloggc:/opt/tomcat/logs/gc.log      # GC日志文件路径
-XX:+PrintGCDetails                  # 打印详细GC信息
-XX:+PrintGCDateStamps               # 打印日期时间戳
-XX:+PrintGCTimeStamps               # 打印相对于JVM启动的时间戳

JDK 9+ (推荐使用统一日志框架):


-Xlog:gc*:file=/opt/tomcat/logs/gc.log:time:filecount=5,filesize=10M
# gc*：记录所有GC相关的信息
# file：输出到文件
# time：添加时间戳
# filecount=5,filesize=10M：轮转5个文件，每个最大10M

优化建议：
务必开启。通过工具（如 GCViewer, gceasy.io）分析日志，你可以清楚地看到：
GC 频率（Frequency）GC 暂停时间（Pause Time）GC 前后堆的使用情况是否发生了 Full GC 及其原因

6. 内存溢出快照（OOM Dump）：问题诊断的“黑匣子”

当发生 OOM 时，自动生成堆转储文件，这是定位内存泄漏的终极武器。

参数：


-XX:+HeapDumpOnOutOfMemoryError          # 在OOM时自动生成堆转储
-XX:HeapDumpPath=/opt/tomcat/logs/heapdump.hprof  # 指定转储文件路径

优化建议：
务必开启。生成的文件可以使用 Eclipse MAT (Memory Analyzer Tool) 或 JVisualVM 进行分析，快速定位到是哪个对象占用了大量内存以及谁在引用它。

三、一个完整的 JVM 优化配置示例

假设我们有一台 8核CPU，16GB内存的服务器，部署了一个典型的 Spring Boot Web 应用，使用 JDK 11。

在 $CATALINA_HOME/bin/setenv.sh 中写入：


#!/bin/sh
# JVM 优化配置 for Tomcat

# 1. 堆内存：设置为系统内存的~50%（预留空间给Metaspace、栈、系统等）
JAVA_OPTS="$JAVA_OPTS -Xms8g -Xmx8g"

# 2. 垃圾收集器：使用 G1
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
# 设置最大GC暂停时间目标为200ms
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"
# 更积极地启动并发周期，避免Full GC
JAVA_OPTS="$JAVA_OPTS -XX:InitiatingHeapOccupancyPercent=35"

# 3. 元空间：限制大小，防止无限增长
JAVA_OPTS="$JAVA_OPTS -XX:MaxMetaspaceSize=512m"

# 4. 线程栈：减少默认栈大小，节省内存
JAVA_OPTS="$JAVA_OPTS -Xss256k"

# 5. GC 日志 (JDK 9+ 统一日志格式)
JAVA_OPTS="$JAVA_OPTS -Xlog:gc*=info:file=$CATALINA_BASE/logs/gc.log:time:filecount=5,filesize=10M"

# 6. OOM 时生成堆转储
JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError"
JAVA_OPTS="$JAVA_OPTS -XX:HeapDumpPath=$CATALINA_BASE/logs/"

# 7. 其他建议配置
JAVA_OPTS="$JAVA_OPTS -XX:+DisableExplicitGC"           # 禁止代码中System.gc()调用的影响
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true"         # 强制无头模式，避免图形资源开销

export JAVA_OPTS

四、优化流程与监控

基准测试：在优化前，使用性能测试工具（如 JMeter）获取当前的吞吐量、响应时间等基准数据。应用配置：将上述参数应用到测试环境。施加负载：使用同样的测试脚本对配置后的环境进行压测。监控分析：
使用 jstat -gc <pid> 1s 实时查看 GC 情况。使用 top, htop 监控系统CPU和内存。压测结束后，分析 GC 日志（上传到 gceasy.io 这类网站可以生成可视化报告）。
迭代调整：
如果发现 Young GC 频繁，说明新生代太小，可以适当增加总堆大小（或者调整G1的 -XX:G1NewSizePercent）。如果发现 Mixed GC 或 Full GC 频繁，说明老年代回收跟不上对象晋升速度，可以尝试降低 -XX:InitiatingHeapOccupancyPercent。如果暂停时间远超目标，可以尝试稍微增加 -XX:MaxGCPauseMillis 或换用 ZGC。