如何在VisualVM中诊断方法Self Time过高的问题

排查操作步骤 #

• 优先使用CPU采样模式而非探测模式：VisualVM的Profiler标签页采用方法植入探测点的方式统计耗时，会给高频短调用方法带来额外统计开销，误差较大。切换到Sampler标签页使用栈采样模式，性能开销更低，Self Time统计结果准确度更高。
• 开启行级耗时统计：VisualVM 2.0及以上版本支持在CPU采样设置中开启行级耗时统计，开启后可以直接定位到算法方法内部具体哪一行代码占用的Self Time最高，无需逐行核对逻辑差异。
• 过滤无关统计项：在采样结果的过滤器中仅保留自定义算法类、用到的JDK数据结构类，排除JVM后台线程、第三方依赖的耗时干扰，确保统计的Self Time完全对应算法方法本身的执行消耗。
• 对比内存分配与GC情况：切换到Sampler的内存统计标签页，对比两种数据结构实现下的内存分配速率、Young GC次数/耗时。如果某一实现频繁生成临时对象触发GC，GC停顿的耗时会被统计到当前正在执行的算法方法的Self Time中，这是Self Time虚高最常见的诱因。

Self Time与数据结构调用耗时倒挂的常见原因 #

• JVM intrinsic方法的统计偏差：部分基础数据结构的核心操作（比如数组的随机访问、基础类型运算）属于JVM intrinsic方法，会被JVM直接映射为底层机器指令执行，不会被统计到数据结构的方法调用耗时中，这部分开销会直接计入调用它的算法方法的Self Time，出现数据结构调用耗时低、算法Self Time高的情况。
• CPU缓存命中率差异：不同数据结构的内存布局差异极大，比如连续存储的数组类结构缓存命中率远高于离散存储的链表类结构，CPU访问缓存比访问主存快2~3个数量级，这部分硬件层面的访问开销不会被统计到数据结构的方法耗时中，会直接叠加到算法的Self Time上。
• 隐式操作的开销归属：如果两种数据结构分别适配基础类型和包装类型，调用点隐式执行的装箱、拆箱操作发生在算法方法内部，不会被统计到数据结构的调用耗时中，也会直接拉高算法的Self Time。

内容的提问来源于stack exchange，提问作者Ymi