调优对比需聚焦GC类型与频率、停顿时间分布、内存回收效果三类具体字段：重点分析GC Cause是否减少Full GC，停顿≥200ms次数及最长停顿变化，回收量、Old Used增长趋势和区域占比合理性，并严格对齐相同业务时段与采集方式。
直接对比调优前后的 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、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
对比时关注三组数据：
- 回收量：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需调整。
用时间戳对齐业务场景再比
不能拿凌晨空闲期的日志和上午高峰的日志硬比。正确做法是：
- 固定同一业务时段（如工作日上午 10:00–11:00）；
- 确保两份日志来自相同监控采集方式（如都用
-Xloggc+-XX:+PrintGCDetails）； - 避开版本发布、流量突增、定时任务执行等干扰窗口，否则指标失真。
