ref proc耗时需通过-xx:+printgcdetails和-xx:+printreferencegc参数定位，其中ref proc为引用处理总耗时，ref enq为入队耗时，二者均属stw；添加printreferencegc后可细分各引用类型耗时，如phantomreference异常高表明虚引用滥用。

在 JVM GC 日志中，Reference 处理耗时（尤其是 Ref Proc 阶段）需要结合详细日志格式和特定 JVM 参数才能准确识别和量化。

看 Ref Proc 耗时：定位日志中的关键字段

启用 -XX:+PrintGCDetails 后，G1 或 Parallel 等收集器的日志中会出现类似这样的结构：

[Ref Proc: 4.4 ms]
[Ref Enq: 0.1 ms]

其中：

• Ref Proc 表示引用处理阶段总耗时（软/弱/虚/终结器/JNI 引用的发现、清理与入队）
• Ref Enq 表示将已清除的引用对象加入 ReferenceQueue 的耗时
• 这两个值都属于 STW 时间的一部分，直接拖长 real time（业务感知的卡顿）

区分是哪种引用在拖慢 GC

默认日志只显示合计耗时，无法知道是 PhantomReference、WeakReference 还是 SoftReference 导致的瓶颈。必须添加参数：

java后端编程

专用于 Java Spring Boot 后端开发的专业技能。当用户提出以下需求时，应调用此技能：构建 REST API、创建 Spring Boot 项目、编写 Java 后端服务、配置数据库访问（JPA / MyBatis）、处理认证与授权（Spring Security / JWT）、实现微服务架构（Spring Cloud）、排查 Spring Boot 相关错误、审查 Java 代码质量，或执行任何与 Spring Boot / Java 后端相关的任务。

下载

-XX:+PrintReferenceGC

加上后，GC 日志中会多出类似：

[SoftReference, 0.2 ms][WeakReference, 0.3 ms][PhantomReference, 977.3 ms]

这样就能一眼锁定问题类型——比如案例中虚引用（PhantomReference）占了 977.3ms，说明大量虚引用对象正在被遍历和清理。

注意 Ref Proc 耗时异常的典型信号

• 单次 Young GC 中 Ref Proc > 10ms 就值得警惕；超过 100ms 通常表明引用管理失控
• Ref Proc 占整个 GC real time 比例过高（如 >50%），说明业务代码创建了大量需显式清理的引用对象
• 即使没有 Full GC，但 Ref Proc 频繁拉高 YGC 耗时（如从 20ms 涨到 1000ms），接口 TP99 就可能突破超时阈值

配合工具验证更直观

GC 日志文本量大，人工筛查低效。推荐用 gcviewer 或 GCEasy 导入日志，它们会自动提取并图表化 Ref Proc 时间趋势，还能按引用类型做柱状对比。若发现 PhantomReference 耗时曲线与告警次数强相关，基本可确认是虚引用滥用所致。