热点方法java_java – 为什么这个方法成为热点？

我正在写一个(简单！)线性代数库.在

matrix multiplication的实现中,

VisualVM性能样本告诉我,当乘以大矩阵(5k x 120k)时,算法花费85％的时间(特别是“自身时间”)以下方法：

public double next() {

double result;

if(hasNext())

result = vis[i++].next();

else

throw new IllegalStateException("No next value");

return result;

}

没有太多细节(抱歉,我不能共享更多代码),这个方法是矩阵的“迭代器”的next()方法. (您可以将此方法所在的类视为由单个列迭代器组成的行迭代器,这些迭代器存储在vis中.)我很惊讶这个方法被调用了很多,因为它是一个迭代器,但我很惊讶该程序花了很多时间在这个方法上.这种方法做得不多,为什么要花时间在这里呢？

以下是我要问的具体问题：

>我正在打击VisualVM的某些“陷阱”吗？例如,JIT是否会以某种方式混淆VisualVM,导致VisualVM将时间归因于错误的方法？

>为什么该计划会花时间在这里？该方法并没有做太多.特别是,我不认为缓存效应可以解释这个问题,因为vis数组远小于乘以矩阵的数据.

如果它有用,这里是我上面粘贴的方法的jad反汇编：

public double next()

{

double result;

if(hasNext())

//* 0 0:aload_0

//* 1 1:invokevirtual #88

//* 2 4:ifeq 32

result = vis[i++].next();

// 3 7:aload_0

// 4 8:getfield #42

// 5 11:aload_0

// 6 12:dup

// 7 13:getfield #28

// 8 16:dup_x1

// 9 17:iconst_1

// 10 18:iadd

// 11 19:putfield #28

// 12 22:aaload

// 13 23:invokeinterface #72

// 14 28:dstore_1

else

//* 15 29:goto 42

throw new IllegalStateException("No next value");

// 16 32:new #89

// 17 35:dup

// 18 36:ldc1 #91

// 19 38:invokespecial #93

// 20 41:athrow

return result;

// 21 42:dload_1

// 22 43:dreturn

}

在此先感谢您的帮助！