Дорого ли использовать блоки try-catch, даже если исключение не выдается?

Мы знаем, что ловить исключения дорого. Но стоит ли также использовать блок try-catch в Java, даже если исключение не выдается?

Я нашел вопрос / ответ о переполнении стека. Почему стоит попробовать блоки? , но это для .NET .

tryпочти не имеет расходов вообще. Вместо того, чтобы выполнять настройку tryво время выполнения, метаданные кода структурированы во время компиляции, так что, когда выдается исключение, он теперь выполняет относительно дорогую операцию обхода стека и проверки, существуют ли какие-либо tryблоки, которые бы перехватили это. исключение. С точки зрения непрофессионала, он также tryможет быть бесплатным. На самом деле это исключение, которое стоит вам - но если вы не выбросите сотни или тысячи исключений, вы все равно не заметите цену.

tryимеет некоторые незначительные расходы, связанные с этим. Java не может оптимизировать код в tryблоке, как в противном случае. Например, Java часто будет переставлять инструкции в методе, чтобы он работал быстрее, но Java также должна гарантировать, что, если выдается исключение, выполнение метода наблюдается так, как если бы его операторы, как написано в исходном коде, выполнялись по порядку до какой-то строки.

Потому что в tryблоке может быть сгенерировано исключение (в любой строке блока try! Некоторые исключения генерируются асинхронно, например, путем вызова stopпотока (что устарело), ​​и даже, кроме того, что OutOfMemoryError может произойти почти где угодно), и все же это может быть перехвачен, и код продолжит выполнение впоследствии в том же методе, более трудно рассуждать об оптимизации, которая может быть сделана, поэтому они менее вероятны. (Кто-то должен был бы запрограммировать компилятор, чтобы он делал это, рассуждал и гарантировал правильность и т. Д. Это было бы большой болью для чего-то, что должно было быть «исключительным») Но опять же, на практике вы не заметите таких вещей.

Давайте измерим это, не так ли?

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    abstract int run(int iterations) throws Throwable;

    private BigDecimal time() {
        try {
            int nextI = 1;
            int i;
            long duration;
            do {
                i = nextI;
                long start = System.nanoTime();
                run(i);
                duration = System.nanoTime() - start;
                nextI = (i << 1) | 1;
            } while (duration < 100000000 && nextI > 0);
            return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    public String toString() {
        return name + "\t" + time() + " ns";
    }

    public static void main(String[] args) throws Exception {
        Benchmark[] benchmarks = {
            new Benchmark("try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        try {
                            x += i;
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                    return x;
                }
            }, new Benchmark("no try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x += i;
                    }
                    return x;
                }
            }
        };
        for (Benchmark bm : benchmarks) {
            System.out.println(bm);
        }
    }
}

На моем компьютере это печатает что-то вроде:

try     0.598 ns
no try  0.601 ns

По крайней мере, в этом тривиальном примере оператор try не оказал заметного влияния на производительность. Не стесняйтесь измерять более сложные.

Вообще говоря, я рекомендую не беспокоиться о стоимости производительности языковых конструкций, пока в вашем коде не появится фактическая проблема производительности. Или , как Дональд Кнут поставил его: «преждевременная оптимизация есть корень всех зол».

try/ catchможет оказать некоторое влияние на производительность. Это потому, что это мешает JVM выполнять некоторые оптимизации. Джошуа Блох в «Эффективной Яве» сказал следующее:

• Помещение кода в блок try-catch препятствует определенным оптимизациям, которые иначе могли бы выполнить современные реализации JVM.

Да, как говорили другие, tryблок запрещает некоторые оптимизации для {}окружающих его персонажей. В частности, оптимизатор должен предполагать, что исключение может произойти в любой точке блока, поэтому нет гарантии, что операторы будут выполнены.

Например:

    try {
        int x = a + b * c * d;
        other stuff;
    }
    catch (something) {
        ....
    }
    int y = a + b * c * d;
    use y somehow;

Без этого tryзначение, рассчитанное для присваивания, xможет быть сохранено как «общее подвыражение» и использовано для присвоения y. Но из-за tryотсутствия уверенности в том, что первое выражение когда-либо оценивалось, поэтому выражение необходимо пересчитать. Обычно это не имеет большого значения в «прямолинейном» коде, но может иметь большое значение в цикле.

Следует отметить, однако, что это относится ТОЛЬКО к JITCed-коду. javac выполняет лишь незначительную оптимизацию, и интерпретатору байт-кода не требуется никаких затрат для входа / выхода из tryблока. (Нет байт-кодов, сгенерированных, чтобы отметить границы блока.)

И для бестссс:

public class TryFinally {
    public static void main(String[] argv) throws Throwable {
        try {
            throw new Throwable();
        }
        finally {
            System.out.println("Finally!");
        }
    }
}

Вывод:

C:\JavaTools>java TryFinally
Finally!
Exception in thread "main" java.lang.Throwable
        at TryFinally.main(TryFinally.java:4)

вывод javap:

C:\JavaTools>javap -c TryFinally.class
Compiled from "TryFinally.java"
public class TryFinally {
  public TryFinally();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Throwable;
    Code:
       0: new           #2                  // class java/lang/Throwable
       3: dup
       4: invokespecial #3                  // Method java/lang/Throwable."<init>":()V
       7: athrow
       8: astore_1
       9: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      12: ldc           #5                  // String Finally!
      14: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      17: aload_1
      18: athrow
    Exception table:
       from    to  target type
           0     9     8   any
}

Нет "GOTO".

Чтобы понять, почему оптимизация не может быть выполнена, полезно понять основные механизмы. Самый краткий пример, который я смог найти, был реализован в макросах C по адресу: http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html.

#include <stdio.h>
#include <setjmp.h>
#define TRY do{ jmp_buf ex_buf__; switch( setjmp(ex_buf__) ){ case 0: while(1){
#define CATCH(x) break; case x:
#define FINALLY break; } default:
#define ETRY } }while(0)
#define THROW(x) longjmp(ex_buf__, x)

Компиляторам часто трудно определить, можно ли локализовать переход на X, Y и Z, поэтому они пропускают оптимизации, которые не могут гарантировать безопасность, но сама реализация довольно легка.

Еще один микробенчмарк ( источник ).

Я создал тест, в котором я измеряю версию кода try-catch и no-try-catch на основе процента исключений. 10% процент означает, что 10% тестовых случаев имели деление на ноль. В одной ситуации он обрабатывается блоком try-catch, в другой - условным оператором. Вот моя таблица результатов:

OS: Windows 8 6.2 x64
JVM: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 23.25-b01

Процент | Результат (попробуйте / если, нс)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

Что говорит о том, что между этими случаями нет существенной разницы.

Я нашел ловлю NullPointException довольно дорого. Для операций 1.2k время составляло 200 мс и 12 мс, когда я обрабатывал его таким же образом, if(object==null)что было довольно хорошим для меня.