Вот микро тест, который сосет меньше.Используйте 1 или 2 в качестве параметров программы и -XX:+PrintCompilation -verbose:class -verbose:gc в качестве параметров JVM.
public class TryBlockBenchmark {
private static final int MEASUREMENTS = 100;
private static int dummy = 0;
public static void main(String[] args) {
boolean tryBlock = args[0].equals("1");
System.out.println(tryBlock ? "try block" : "no try block");
for (int i = 0; i < MEASUREMENTS; i++) {
long start = System.currentTimeMillis();
if (tryBlock) {
benchmarkTryBlock();
} else {
benchmarkNoTryBlock();
}
long end = System.currentTimeMillis();
System.out.println((end - start) + " ms");
}
System.out.println("(" + dummy + ")");
}
private static void benchmarkTryBlock() {
for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
try {
staticMethod();
} catch (Exception e) {
}
}
}
private static void benchmarkNoTryBlock() {
for (int i = Integer.MIN_VALUE; i < Integer.MAX_VALUE; i++) {
staticMethod();
}
}
private static void staticMethod() {
dummy++;
}
}
С 64-битной виртуальной машиной HotSpot Java 1.6.0_24 на C2Q6600 @ 3GHz после первой парыизмерения, время для обеих версий стабилизируется на 266 мс (+/- 1 мс).Время то же самое, когда staticMethod() вводится вручную, чего и следует ожидать от HotSpot.Удаление строки dummy++ сокращает время до 0 мс, когда HotSpot оптимизирует его.
Я также протестировал 32-битную версию Java 1.6.0_24, и с ней виртуальная машина сервера HotSpot показала те же результаты, ноКлиентская виртуальная машина HotSpot имела обе версии, выдающие результаты около 8660 мс (+/- 20 мс).
Таким образом, мы можем сделать вывод, что виртуальная машина сервера имеет лучшую оптимизацию, чем виртуальная машина клиента, и что попытка перехвата ничего не делаетлибо оптимизирован HotSpot, либо не влияет на производительность.Чтобы выяснить, что это такое, напечатайте код сборки , созданный HotSpot.
В целом, измерять вещи, которые ничего не делают, довольно бессмысленно.