jdk 11 的 gc 日志格式默认采用结构化文本输出,不再使用早期版本中难以解析的固定列宽格式。要启用这种格式,需要在启动参数中添加 -xlog:gc* 标签,jvm 会自动根据日志级别和类别生成包含时间戳、gc 原因、内存区域状态及暂停时间的详细记录。这种格式不仅人类可读性更强,也便于通过脚本或工具进行自动化分析。

如何配置 JDK 11 的 GC 日志输出路径与级别
在 JDK 11 中,可以通过 -Xlog 选项指定日志输出的文件位置以及具体的日志级别。默认的日志级别为 info,这会输出常规的 GC 事件摘要。如果需要更详细的调试信息,可以调整为 debug 级别,或者针对特定区域如 G1 Young Generation 进行单独配置。日志文件通常会被写入到指定的路径,若未指定则可能输出到控制台或默认的文件位置。

java -Xlog:gc*:file=gc.log:time,uptime,level,tags -XX:+UseG1GC YourApplication
上述命令将 GC 日志输出到当前目录下的 gc.log 文件中。参数 time 表示添加绝对时间戳,uptime 表示添加 JVM 启动后的运行时间,level 和 tags 分别表示日志级别和标签。使用 -XX:+UseG1GC 显式指定 G1 垃圾回收器,因为它是 JDK 9 之后的默认回收器。运行该程序后,生成的日志文件将包含结构化的 GC 事件记录,每一行都对应一次 GC 活动。
立即学习“Java免费学习笔记(深入)”;
你是 TypeScript 项目架构专家,专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链(pnpm、Vite、Next.js)、类型
JDK 11 GC 日志的具体字段含义是什么
JDK 11 的结构化 GC 日志由多个部分组成,包括时间戳、线程 ID、日志级别、标签以及具体的消息内容。时间戳可以是绝对时间或相对 JVM 启动的时间。标签部分通常以方括号包裹,标识 GC 的类型和阶段,例如 [GC (Allocation Failure) 表示因分配失败触发的 GC。消息部分则详细描述了堆内存的变化,包括各内存区域的容量、已用空间以及 GC 前后的变化量。对于 G1 收集器,还会额外显示 Region 的数量和类型分布。

2023-10-27T10:00:00.000+0800: [GC (Allocation Failure) [G1Ergonomics (Concurrent Garbage Collection Started)] 2023-10-27T10:00:00.005+0800: [GC concurrent-root-region-scan-start 2023-10-27T10:00:00.010+0800: [GC concurrent-root-region-scan-end, 0.005 secs 2023-10-27T10:00:00.010+0800: [GC concurrent-mark-start 2023-10-27T10:00:00.020+0800: [GC concurrent-mark-end, 0.010 secs 2023-10-27T10:00:00.020+0800: [GC pause (G1 Evacuation Pause) [YG occupancy: 50 M] 2023-10-27T10:00:00.050+0800: [GC concurrent-refinement-start, 0.001 secs 2023-10-27T10:00:00.051+0800: [GC concurrent-refinement-end, 0.001 secs 2023-10-27T10:00:00.055+0800: [GC pause (G1 Evacuation Pause) [YG occupancy: 40 M] [rescanned objects: 1000] 2023-10-27T10:00:00.060+0800: [GC concurrent-mark-reset-start 2023-10-27T10:00:00.061+0800: [GC concurrent-mark-reset-end, 0.001 secs]
以上示例展示了 G1 收集器在一次完整 GC 周期中的日志片段。第一行显示了触发 GC 的原因是 Allocation Failure,并启动了并发垃圾收集。随后的几行记录了并发根区域扫描和并发标记的过程,这些阶段通常与用户线程并发执行,不会造成明显的停顿。接着是 G1 Evacuation Pause,这是主要的 STW(Stop-The-World)阶段,日志中显示了年轻代(YG)的占用量和扫描的对象数量。最后,并发 refinement 和 mark reset 阶段完成,准备进入下一个周期。通过这些字段,开发者可以清晰地了解 GC 的各个阶段及其耗时。
如何从 JDK 11 GC 日志中识别 Full GC 触发条件
在 JDK 11 中,Full GC 通常由元空间(Metaspace)溢出、老年代空间不足或显式调用 System.gc() 触发。在结构化日志中,Full GC 事件通常标记为 [Full GC (Metadata GC Threshold)] 或 [Full GC (Allocation Failure)]。与普通的 Young GC 不同,Full GC 会暂停所有应用线程,并回收整个堆内存,包括年轻代、老年代和元空间。通过分析日志中的 Heap Before GC 和 Heap After GC 数据,可以判断 GC 是否成功释放了足够的空间。如果 Full GC 频繁发生且回收效果不佳,可能需要调整堆大小或优化代码以减少对象创建。

















