我试图确保某些(免费)java cpu性能分析工具的准确性,例如sjk,visualvm。
这是一个执行cpu敏感任务的示例程序:
RandomStringUtils.java
:
import java.util.Random;
public class RandomStringUtils {
public String generate() {
int leftLimit = 97; // letter 'a'
int rightLimit = 122; // letter 'z'
int targetStringLength = 10;
Random random = new Random();
StringBuilder buffer = new StringBuilder(targetStringLength);
for (int i = 0; i < targetStringLength; i++) {
int randomLimitedInt = leftLimit + (int)
(random.nextFloat() * (rightLimit - leftLimit + 1));
buffer.append((char) randomLimitedInt);
}
return buffer.toString();
}
}
MainClass.java
:
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
public class MainClass {
public String crypt(String str) {
if (str == null || str.length() == 0) {
throw new IllegalArgumentException("String to encript cannot be null or zero length");
}
StringBuilder hexString = new StringBuilder();
try {
MessageDigest md = MessageDigest.getInstance("MD5");
md.update(str.getBytes());
byte[] hash = md.digest();
for (byte aHash : hash) {
if ((0xff & aHash) < 0x10) {
hexString.append("0" + Integer.toHexString((0xFF & aHash)));
} else {
hexString.append(Integer.toHexString(0xFF & aHash));
}
}
} catch (NoSuchAlgorithmException e) {
e.printStackTrace();
}
return hexString.toString();
}
public static void main(String[] args) {
long N = 1000 * 100;
if (args.length > 0) {
N = Long.parseLong(args[0], 10);
}
MainClass main = new MainClass();
RandomStringUtils randomStringUtils = new RandomStringUtils();
for (long i = 0; i < N; i++) {
main.crypt(randomStringUtils.generate());
}
}
}
例如,我使用sjk对cpu进行采样:
java -jar sjk-plus-0.11.jar stcap -p 3113 -f main -i 5ms -t 30s -o dump.std
java -jar sjk-plus-0.11.jar flame -f dump.std -o report.html
我的问题是,main()
的自我时间为何如此之大?并且它仅执行循环。 encrypt()
和generate()
不会占据整个CPU吗?
visualvm显示类似的结果。
sjk是否考虑自己的时间和整个时间?如何在命令行报告BTW中显示它们?
答案 0 :(得分:2)
这是安全点偏差的一个非常明显的例子。
下面3个火焰图表示代码的略微修改版本(see on github)。
SJK正在使用线程转储采样方法,因此结果会因safepoint偏差而产生偏差。
JFR在采样时不受安全点偏差的影响,但是默认情况下,JIT编译器生成的符号图仅限于安全点检查。这对重建堆栈跟踪有负面影响。
虽然结果比线程转储采样更好,但是您可以看到异常。例如。 Integer.toHexString
时间肯定被夸大了。
使用Java Flight Recorder和其他JVM选项
-XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints
对JVM启动选项的调整图片变得更加准确和详细。 -XX:+DebugNonSafepoints
强制JIT编译器生成详细的符号映射。
从这个例子来看,您可以得出Java Flight Recorder普遍更好的结论。
Here,您可以找到对此现象的详细说明。