Java 线上 JVM 调优前后的 GC 日志怎么对比-java教程-PHP中文网

调优对比需聚焦GC类型与频率、停顿时间分布、内存回收效果三类具体字段：重点分析GC Cause是否减少Full GC，停顿≥200ms次数及最长停顿变化，回收量、Old Used增长趋势和区域占比合理性，并严格对齐相同业务时段与采集方式。

java 线上 jvm 调优前后的 gc 日志怎么对比

直接对比调优前后的 GC 日志，关键不是“有没有变好”，而是“哪里变了、为什么变、是否符合预期”。重点看三类信息：GC 类型与频率、停顿时间分布、内存回收效果。跳过泛泛而谈的“整体变少”，盯住日志里可定位、可归因的具体字段。

看 GC 类型和触发原因是否改善

调优的核心目标之一是减少 Full GC，避免退化行为。对比时重点关注日志中的 GC Cause 字段：

调优前若高频出现 Full GC (Allocation Failure) 或 Full GC (Metadata GC Threshold)，说明老年代或元空间真的快满了，或是对象晋升失控；
调优后应看到更多 GC pause (G1Evacuation Pause) (young) 或 (mixed)，且 Full GC 消失或大幅减少；
如果仍出现 Full GC (System.gc())，要查代码或依赖库是否显式调用了 System.gc()，这不是参数能解决的问题。

比停顿时间的分布，不止看平均值

单次停顿超 500ms 就会影响 P99 响应，所以不能只记“平均停顿下降了”。从日志中提取每条 GC 记录的耗时（secs 后面的数字），做简单统计：

统计调优前后各 1 小时内，停顿 ≥200ms 的次数；
看最长单次停顿是否从 4s 降到 ≤800ms；
观察 Young GC 停顿是否更稳定——比如原来波动在 20~120ms，调优后收敛到 30~60ms，说明 Survivor 区配置或晋升阈值更合理。

核对内存回收效果是否匹配预期

每条 GC 日志都包含回收前后的内存变化，例如：
[GC pause (G1Evacuation Pause) (young) 4.2G->2.1G(8G), 0.150secs]

sc-java-to-ts-interface

将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。

下载

对比时关注三组数据：

回收量：4.2G→2.1G 表示这次回收了 2.1G，效率 50%；若调优后同样场景下回收量变小（如 4.2G→3.8G），说明对象存活率升高，可能 Survivor 区太小或晋升过早；
堆使用趋势：连续多条日志中 Old Used（OU）是否缓慢上升？调优后 OU 每分钟增长量应明显放缓，避免一小时就触达 InitiatingHeapOccupancyPercent；
区域占比合理性：Eden 区是否长期卡在 90%+ 才触发 YGC？说明 Eden 太小；Survivor 区是否频繁溢出、大量对象直奔老年代？说明 -XX:SurvivorRatio 或 -XX:MaxTenuringThreshold 需调整。