正确开启并导出 GC 日志需显式指定路径与滚动策略：JDK 8 用 -XX:+PrintGCDetails -Xloggc:/path/to/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M；JDK 9+ 改用 -Xlog:gc*:file=/path/to/gc.log:time,tags,level，禁用旧时间戳参数以防解析失败。
PrintGCDetails 日志怎么正确开启并导出到文件
不加 -Xloggc: 或重定向，-XX:+PrintGCDetails 输出默认走 stdout/stderr，容易被容器日志截断或丢失。必须显式指定日志路径，并配合时间戳和滚动策略避免单文件过大。
推荐启动参数组合：
-
-XX:+PrintGCDetails—— 必须启用，否则 GCViewer 无法解析详细事件 -
-Xloggc:/path/to/gc.log—— JDK 8 及以前用；JDK 9+ 改用-Xlog:gc*:file=/path/to/gc.log:time,tags,level -
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=10M—— 防止日志撑爆磁盘 - 避免混用
-XX:+PrintGCTimeStamps（旧版）和-Xlog（新版），否则时间格式错乱，GCViewer 解析失败
GCViewer 能不能直接读取 JDK 17 的 GC 日志
不能直接读 —— GCViewer 2.9.2（最新稳定版）原生只支持到 JDK 11 的 -Xlog 格式，对 JDK 17 默认的 tag 分组、多行事件（如 gc,heap,exit）解析会丢数据或报 Unknown log format 错误。
绕过方法只有两个：
- 启动 JDK 17 时强制降级日志格式：
-Xlog:gc*,gc+heap=debug,gc+metaspace=debug:file=/path/to/gc.log:time,uptime,level,tags，再用-XX:+PrintGCDetails -XX:+PrintGCDateStamps回退到类 JDK 8 格式（兼容 GCViewer） - 改用替代工具：如
GCEasy（在线）、Java Mission Control（本地 + JFR）、或用gceasy-cli命令行导出 CSV 后用 Grafana 绘图
吞吐量（Throughput）在 GCViewer 里对应哪个数值
GCViewer 不直接标“吞吐量”，它把吞吐量定义为 1 - (GC 总耗时 / 应用总运行时间)，而这个值藏在 Summary 标签页的 Overall throughput 行里 —— 注意不是 GC throughput（那是 GC 线程自身利用率）。
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
要画吞吐量随时间变化的曲线，得导出原始 GC 事件时间序列：
- 在 GCViewer 中点 File → Export → CSV，勾选
Timestamp,Duration,Type，导出每条 GC 事件的起始时间与耗时 - 用 Python/Pandas 按固定窗口（如 60 秒）聚合：窗口内
sum(Duration)/ 窗口长度 → 得到该窗口 GC 开销占比，再用1 - 占比就是吞吐量 - 别直接用 GCViewer 的 “Throughput over time” 图表 —— 它按 GC 次数分桶而非真实时间轴，斜率失真严重
为什么导出的吞吐量曲线看起来毛刺多、趋势难读
因为 GC 发生本身是非均匀的：一次 Full GC 可能占 2 秒，前后几分钟没 GC，吞吐量瞬间从 99% 掉到 0%，再跳回 100%。这种原始数据不适合直接画线图。
真正可用的吞吐量曲线需要平滑处理：
- 用滑动窗口（如 300 秒）计算滚动吞吐量，而不是单点瞬时值
- 排除 STW 时间极短（
- 如果应用有明显周期性（如定时批处理），需对齐业务周期切分窗口，否则平均值会被周期峰值拉偏
GC 日志里的时间戳精度依赖 JVM 启动时是否加了 -XX:+UseParallelGC 或 -XX:+UseG1GC —— G1 的 Start Time 字段在并发阶段可能缺失，导致窗口计算漏掉部分停顿。这点容易被忽略。
