1
2
3

事前预防 → 事中自动采集 → 事后分析
   ↓            ↓            ↓
合理配置    JVM参数自动导出  专业工具分析

1
2
3
4
5
6

问题现象 → 数据选择 → 分析工具 → 定位根因

CPU 100%      → 线程快照 + JFR → FastThread/JMC → 找出占用 CPU 的线程栈
内存持续增长  → 堆转储        → MAT           → 分析大对象和引用链
应用频繁停顿  → GC 日志 + JFR → GCViewer/JMC  → 分析 GC 停顿时间和频率
接口响应变慢  → JFR           → JMC           → 分析锁竞争、IO 等待、线程调度

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

#!/bin/bash
JAVA_OPTS="-Xms4g -Xmx4g \

  # ========== 垃圾回收配置 ==========
  -XX:+UseG1GC \                    # 启用 G1 回收器（JDK 8 默认是 Parallel GC）
  -XX:MaxGCPauseMillis=200 \        # 目标最大 GC 停顿时间（毫秒），G1 会尽力达成
  -XX:G1HeapRegionSize=16m \        # G1 区域大小（可选，默认自动计算）
  -XX:InitiatingHeapOccupancyPercent=45 \  # 触发并发标记的堆占用百分比（默认 45）
  -XX:G1ReservePercent=10 \          # 预留空间百分比，防止晋升失败（默认 10）
  
  # ========== 容器感知（JDK 8u191+）==========
  -XX:+UseContainerSupport \         # 启用容器支持，识别 Docker cgroup 限制
  -XX:MaxRAMFraction=2 \             # 最大堆内存占容器内存的 1/2（对应 50%）
  # 说明：-XX:MaxRAMFraction=n 表示堆内存 = 容器内存 / n
  # 推荐值：n=2（50%）适合大多数应用，n=1（100%）可能过大
  # JDK 8 不支持 -XX:MaxRAMPercentage，需用此参数
  
  # ========== GC 日志（JDK 8 旧版语法）==========
  -Xloggc:/data/logs/gc.log \        # GC 日志输出路径
  -XX:+PrintGCDetails \              # 打印 GC 详细细节
  -XX:+PrintGCDateStamps \           # 打印日期时间戳（格式：YYYY-MM-DDTHH:MM:SS.SSS）
  -XX:+PrintGCTimeStamps \           # 打印 JVM 启动后的时间戳（毫秒）
  -XX:+PrintGCApplicationStoppedTime \  # 打印应用暂停时间
  -XX:+PrintPromotionFailure \       # 打印晋升失败信息（有助于定位 Full GC 原因）
  -XX:+PrintTenuringDistribution \   # 打印年龄分布（分析对象晋升）
  
  # ========== OOM 自动堆转储 ==========
  -XX:+HeapDumpOnOutOfMemoryError \  # 发生 OOM 时自动导出堆转储
  -XX:HeapDumpPath=/data/logs/ \     # 堆转储路径，生成文件名为 java_pid<pid>.hprof
  # 注意：JDK 8 不支持 %p 占位符，文件名固定为 java_pid<pid>.hprof
  # 如需指定完整路径：-XX:HeapDumpPath=/data/logs/heapdump.hprof（单文件覆盖）
  
  # ========== JFR 配置 ==========
  -XX:+FlightRecorder \              # 启用 Flight Recorder（JDK 8 需显式开启）
  -XX:StartFlightRecording=filename=/data/logs/recording.jfr,maxsize=500M,maxage=7d,settings=default \
  # 参数详解：
  #   filename      : 输出文件路径，支持 %p（进程 ID）占位符
  #   maxsize       : 单个文件最大大小，超过自动轮转（支持 K/M/G）
  #   maxage        : 文件保留时间（s=秒,m=分,h=时,d=天）
  #   settings      : 录制模板（default=低开销<1%，profile=详细约2%）
  #   delay         : 延迟启动时间（如 30s）
  #   duration      : 录制时长（不设置则持续录制）
  
  # ========== JMX 指标暴露 ==========
  -Dcom.sun.management.jmxremote \   # 启用 JMX 远程管理
  -Dcom.sun.management.jmxremote.port=9010 \  # JMX 服务端口
  -Dcom.sun.management.jmxremote.authenticate=false \  # 关闭认证（内网环境）
  -Dcom.sun.management.jmxremote.ssl=false \          # 关闭 SSL（内网环境）
  # 注意：不要同时设置 local.only=true，否则远程无法连接
  # 如需限制本地访问：-Dcom.sun.management.jmxremote.local.only=true
  
  # ========== 辅助诊断参数 ==========
  -XX:+PrintCommandLineFlags \       # 启动时打印显式设置的 JVM 参数
  -XX:+PrintFlagsFinal \             # 打印所有最终生效的 JVM 参数（启动后输出）
  -XX:+HeapDumpBeforeFullGC \        # Full GC 前导出堆转储（可选，谨慎使用）
  -XX:+HeapDumpAfterFullGC \         # Full GC 后导出堆转储（可选）
  -XX:ErrorFile=/data/logs/hs_err_%p.log \  # JVM 崩溃日志路径
  
  -jar your-application.jar"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

#!/bin/bash
JAVA_OPTS="-Xms4g -Xmx4g \

  # ========== 垃圾回收配置 ==========
  -XX:+UseG1GC \                    # 使用 G1 回收器（JDK 11+ 默认已是 G1，显式声明无妨）
  -XX:MaxGCPauseMillis=200 \        # 目标最大 GC 停顿时间
  -XX:G1HeapRegionSize=16m \        # G1 区域大小
  -XX:InitiatingHeapOccupancyPercent=45 \  # 并发标记触发阈值
  -XX:G1ReservePercent=10 \          # 预留空间百分比
  -XX:ConcGCThreads=2 \              # 并发 GC 线程数（默认根据 CPU 核数计算）
  
  # ========== 容器内存配置（JDK 10+ 支持 -XX:MaxRAMPercentage）==========
  -XX:MaxRAMPercentage=75.0 \        # 最大堆内存占容器内存的百分比（推荐 75%）
  -XX:InitialRAMPercentage=50.0 \    # 初始堆内存百分比
  -XX:MinRAMPercentage=50.0 \        # 小内存容器（<200MB）时的最小堆百分比
  # 说明：-XX:MaxRAMPercentage 比 -XX:MaxRAMFraction 更直观，推荐使用
  
  # ========== GC 日志（Unified JVM Logging）==========
  -Xlog:gc*:file=/data/logs/gc.log:time,uptime:filecount=10,filesize=100M \
  # 语法详解：-Xlog:<tag set>:<output>:<decorators>:<options>
  #   tag set       : gc* 表示所有 GC 相关标签（gc, gc+heap, gc+phases 等）
  #   output        : file= 指定文件路径
  #   decorators    : time=日期时间, uptime=JVM 启动时长, pid=进程ID, tid=线程ID
  #   options       : filecount=轮转文件数, filesize=单文件大小
  # 常用标签：
  #   gc            : 基本 GC 信息
  #   gc+heap       : 堆内存变化
  #   gc+phases     : GC 各阶段耗时
  #   gc+safepoint  : 安全点信息
  #   gc+metaspace  : 元空间信息
  
  # ========== OOM 自动堆转储 ==========
  -XX:+HeapDumpOnOutOfMemoryError \
  -XX:HeapDumpPath=/data/logs/heapdump_%p.hprof \
  # 说明：%p 占位符在 JDK 11+ 稳定支持，自动替换为进程 PID
  
  # ========== JFR 持续录制（JDK 11+ 无需解锁）==========
  -XX:StartFlightRecording=filename=/data/logs/recording.jfr,maxsize=500M,maxage=7d,settings=default \
  # 可选参数：
  #   disk=true/false     : 是否写入磁盘（默认 true）
  #   dumponexit=true/false: JVM 退出时是否转储（默认 true）
  #   maxchunksize=12M    : 单个 chunk 大小，影响轮转粒度
  
  # ========== JMX 指标暴露 ==========
  -Dcom.sun.management.jmxremote.port=9010 \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Dcom.sun.management.jmxremote.ssl=false \
  # 如需限制仅本地访问：-Dcom.sun.management.jmxremote.local.only=true
  
  # ========== 辅助诊断参数 ==========
  -XX:+PrintCommandLineFlags \
  -XX:+PrintFlagsFinal \
  -XX:ErrorFile=/data/logs/hs_err_%p.log \  # JVM 崩溃日志
  -XX:+ShowCodeDetailsInExceptionMessages \ # 异常信息中显示更多细节（JDK 14+）
  
  -jar your-application.jar"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 如需启用分代 ZGC（JDK 21 实验特性，需显式开启）
-XX:+UseZGC -XX:+ZGenerational

# ZGC 专用参数
-XX:ZCollectionInterval=120 \        # 最大 GC 间隔（秒），默认 0（无限制）
-XX:ZAllocationSpikeTolerance=2.0 \  # 分配峰值容忍度，默认 2.0
-XX:ZUncommitDelay=300 \             # 未使用内存回收延迟（秒）

# 注意：
# 1. 分代 ZGC 在 JDK 21 是实验特性，生产使用需充分评估
# 2. ZGC 适合大堆内存（>16G）、极低延迟（<1ms）场景
# 3. 普通应用默认 G1 仍是稳妥选择
# 4. 虚拟线程场景下，G1 仍是官方推荐搭配

1
2

# 每日凌晨 2 点执行清理
0 2 * * * /opt/scripts/cleanup_diagnostic_logs.sh

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#!/bin/bash
LOG_DIR="/data/logs"

# 清理 7 天前的 GC 日志
find $LOG_DIR -name "gc.log*" -mtime +7 -delete

# 清理 7 天前的 JFR 文件
find $LOG_DIR -name "*.jfr" -mtime +7 -delete

# 清理 30 天前的堆转储（OOM 可能不频繁，保留更久）
find $LOG_DIR -name "*.hprof" -mtime +30 -delete

# 清理 30 天前的崩溃日志
find $LOG_DIR -name "hs_err_*.log" -mtime +30 -delete

# 记录清理结果
echo "$(date): Cleaned up diagnostic logs older than retention period" >> /var/log/jvm_cleanup.log

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

应用告警（CPU/内存/响应时间）
        ↓
1. 登录可观测性平台
        ↓
2. 查看 JVM 指标大盘
   ├── GC 次数是否异常？（YGC/FGC 频次）
   ├── GC 停顿时间是否过高？（超过 MaxGCPauseMillis）
   ├── 堆内存占用是否持续增长？
   └── 老年代占用是否接近 100%？
        ↓
3. 进入 Kibana 检索 GC 日志
   ├── 查看具体 GC 事件类型（Young GC / Mixed GC / Full GC）
   ├── 分析 GC 前后堆内存变化
   └── 查看 GC 停顿时间分布
        ↓
4. 如有 OOM 记录 → 下载堆转储
   ├── 用 MAT 打开
   ├── 查看 Leak Suspects 报告
   └── 分析 Dominator Tree 定位大对象
        ↓
5. 如需深度分析 → 下载 JFR 文件
   ├── 用 JDK Mission Control 打开
   ├── 查看 Overview：整体 JVM 行为
   ├── 查看 Memory：GC 事件、堆变化
   ├── 查看 Threads：锁竞争、线程阻塞
   └── 查看 CPU：热点方法、调用栈
        ↓
6. 输出分析报告
   ├── 问题现象描述
   ├── 根因定位（代码/配置/环境）
   ├── 影响范围
   └── 修复建议与验证方案

1

-XX:StartFlightRecording=filename=/data/logs/recording.jfr,maxsize=500M,maxage=7d,settings=default

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 查看文件摘要信息
jfr summary recording.jfr

# 查看所有事件类型
jfr metadata recording.jfr

# 导出为文本格式（按事件类型）
jfr print recording.jfr > output.txt

# 导出为 JSON 格式（便于程序处理）
jfr print --json recording.jfr > events.json

# 按事件类型过滤
jfr print --events jdk.GarbageCollection recording.jfr

# 按类别过滤
jfr print --categories GC recording.jfr

# 按时间范围过滤
jfr print --start 10s --end 20s recording.jfr

1
2

S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
0.00  98.23  45.67  72.34  88.12  82.45   125    2.345     2    0.123   2.468

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. 找到 Java 进程 PID
jps -l

# 2. 找到 CPU 最高的线程 ID（十进制）
top -Hp 12345 -n 1

# 3. 将线程 ID 转换为十六进制
printf "%x\n" 12346

# 4. 导出线程快照，搜索该十六进制 ID
jstack 12345 | grep -A 20 "0x303a"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 4294967296 (4096.0MB)  # 最大堆
   NewSize                  = 142606336 (136.0MB)    # 年轻代初始大小
   MaxNewSize               = 1431830528 (1365.5MB)  # 年轻代最大大小
   OldSize                  = 286261248 (273.0MB)    # 老年代大小

Heap Usage:
G1 Heap:
   regions = 4096
   capacity = 4294967296 (4096.0MB)
   used     = 3221225472 (3072.0MB)    # 已使用堆
   free     = 1073741824 (1024.0MB)    # 剩余堆

1

./as.sh <pid>

1

ls -lh /data/logs/*.hprof

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. 找到 Java 进程 PID
jps -l

# 2. 查看进程中线程 CPU 占用
top -Hp 12345 -n 1

# 3. 记录 CPU 最高的线程 ID（十进制），转为十六进制
printf "%x\n" 12346

# 4. 导出线程快照，查找该线程的堆栈
jstack 12345 | grep -A 30 "0x303a"

1

jmap -dump:live,format=b,file=heap.hprof 12345

1

jstack 12345 > thread.log

1

grep "deadlock" thread.log -A 20

1
2
3
4
5
6
7
8

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00007f8c2c005e00 (object 0x00000007e2a8b5c0, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00007f8c2c006c00 (object 0x00000007e2a8b5d0, a java.lang.Object),
  which is held by "Thread-1"