Какая часть создания исключения является дорогой?

В Java использование throw / catch как части логики, когда на самом деле нет ошибки, как правило, является плохой идеей (частично), потому что выбрасывать и перехватывать исключение дорого, и делать это много раз в цикле обычно гораздо медленнее, чем другие. управляющие структуры, которые не включают в себя исключения.

Мой вопрос заключается в том, являются ли затраты, понесенные в самом броске / захвате, или при создании объекта Exception (поскольку он получает много информации времени выполнения, включая стек выполнения)?

Другими словами, если я делаю

Exception e = new Exception();

но не бросайте его, это большая часть стоимости броска, или обработка броска + улова стоит дорого?

Я не спрашиваю, добавляет ли код в блок try / catch стоимость выполнения этого кода, я спрашиваю, является ли перехват Exception дорогой частью или создает (вызывает конструктор) Exception - дорогую часть ,

Еще один способ задать вопрос: если я сделал один экземпляр Exception, а затем бросил и поймал его снова и снова, это было бы значительно быстрее, чем создание нового исключения каждый раз, когда я выбрасывал?

Создание объекта исключения не дороже, чем создание других обычных объектов. Основная стоимость скрыта в нативном fillInStackTraceметоде, который проходит через стек вызовов и собирает всю необходимую информацию для построения трассировки стека: классы, имена методов, номера строк и т. Д.

Миф о высокой стоимости исключений проистекает из того факта, что большинство Throwableконструкторов неявно вызывают fillInStackTrace. Однако есть один конструктор для создания Throwableбез трассировки стека. Это позволяет создавать броски, которые очень быстро создаются. Другой способ создать легкие исключения - переопределить fillInStackTrace.

Теперь насчет бросать исключение?
На самом деле, это зависит от того, где заброшенного исключения поймано .

Если он перехватывается одним и тем же методом (или, точнее, в одном и том же контексте, поскольку контекст может включать несколько методов из-за встраивания), он throwбудет таким же быстрым и простым, как goto(конечно, после JIT-компиляции).

Однако, если catchблок находится где-то глубже в стеке, JVM необходимо развернуть кадры стека, а это может занять значительно больше времени. Это занимает еще больше времени, если synchronizedзадействованы блоки или методы, потому что разматывание подразумевает освобождение мониторов, принадлежащих удаленным кадрам стека.

Я мог бы подтвердить вышеприведенные утверждения с помощью надлежащих тестов, но, к счастью, мне не нужно этого делать, поскольку все аспекты уже отлично освещены в посте инженера по производительности HotSpot Алексея Шипилева: Исключительная производительность из Lil 'Exception .

Первой операцией в большинстве Throwableконструкторов является заполнение трассировки стека, в которой находится большая часть расходов.

Тем не менее, существует защищенный конструктор с флагом для отключения трассировки стека. Этот конструктор доступен и при расширении Exception. Если вы создаете пользовательский тип исключения, вы можете избежать создания трассировки стека и повысить производительность за счет меньшего количества информации.

Если вы создаете отдельное исключение любого типа обычными средствами, вы можете перебрасывать его много раз без дополнительных затрат на заполнение трассировки стека. Тем не менее, его трассировка стека будет отражать, где он был создан, а не где он был брошен в конкретном случае.

Текущие версии Java делают некоторые попытки оптимизировать создание трассировки стека. Нативный код вызывается для заполнения трассировки стека, которая записывает трассу в более легкой, нативной структуре. Соответствующие Java StackTraceElementобъекты лениво создается из этой записи только тогда , когда getStackTrace(), printStackTrace()или другие методы , которые предписывают след называются.

Если вы исключите генерацию трассировки стека, другой основной ценой будет раскручивание стека между броском и уловом. Чем меньше промежуточных кадров будет найдено до того, как будет обнаружено исключение, тем быстрее это будет.

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

Theres хорошая запись об исключениях здесь.

http://shipilev.net/blog/2014/exceptional-performance/

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

Ниже приведены сроки только для создания объекта. Я добавил Stringсюда, чтобы вы могли видеть, что без написания стека практически нет разницы в создании JavaExceptionObject и a String. С включенной записью стека разница значительна, т.е. как минимум на порядок медленнее.

Time to create million String objects: 41.41 (ms)
Time to create million JavaException objects with    stack: 608.89 (ms)
Time to create million JavaException objects without stack: 43.50 (ms)

Ниже показано, сколько времени понадобилось, чтобы вернуться из броска на определенную глубину миллион раз.

|Depth| WriteStack(ms)| !WriteStack(ms)| Diff(%)|
|   16|           1428|             243| 588 (%)|
|   15|           1763|             393| 449 (%)|
|   14|           1746|             390| 448 (%)|
|   13|           1703|             384| 443 (%)|
|   12|           1697|             391| 434 (%)|
|   11|           1707|             410| 416 (%)|
|   10|           1226|             197| 622 (%)|
|    9|           1242|             206| 603 (%)|
|    8|           1251|             207| 604 (%)|
|    7|           1213|             208| 583 (%)|
|    6|           1164|             206| 565 (%)|
|    5|           1134|             205| 553 (%)|
|    4|           1106|             203| 545 (%)|
|    3|           1043|             192| 543 (%)| 

Следующее почти наверняка является чрезмерным упрощением ...

Если мы берем глубину 16 с записью стека, то создание объекта занимает примерно ~ 40% времени, фактическая трассировка стека составляет подавляющее большинство этого. ~ 93% создания объекта JavaException происходит из-за выполняемой трассировки стека. Это означает, что раскрутка стека в этом случае занимает остальные 50% времени.

Когда мы отключаем создание объекта трассировки стека, приходится гораздо меньшая доля, т.е. 20%, а раскрутка стека теперь составляет 80% времени.

В обоих случаях разматывание стека занимает большую часть общего времени.

public class JavaException extends Exception {
  JavaException(String reason, int mode) {
    super(reason, null, false, false);
  }
  JavaException(String reason) {
    super(reason);
  }

  public static void main(String[] args) {
    int iterations = 1000000;
    long create_time_with    = 0;
    long create_time_without = 0;
    long create_string = 0;
    for (int i = 0; i < iterations; i++) {
      long start = System.nanoTime();
      JavaException jex = new JavaException("testing");
      long stop  =  System.nanoTime();
      create_time_with += stop - start;

      start = System.nanoTime();
      JavaException jex2 = new JavaException("testing", 1);
      stop = System.nanoTime();
      create_time_without += stop - start;

      start = System.nanoTime();
      String str = new String("testing");
      stop = System.nanoTime();
      create_string += stop - start;

    }
    double interval_with    = ((double)create_time_with)/1000000;
    double interval_without = ((double)create_time_without)/1000000;
    double interval_string  = ((double)create_string)/1000000;

    System.out.printf("Time to create %d String objects: %.2f (ms)\n", iterations, interval_string);
    System.out.printf("Time to create %d JavaException objects with    stack: %.2f (ms)\n", iterations, interval_with);
    System.out.printf("Time to create %d JavaException objects without stack: %.2f (ms)\n", iterations, interval_without);

    JavaException jex = new JavaException("testing");
    int depth = 14;
    int i = depth;
    double[] with_stack    = new double[20];
    double[] without_stack = new double[20];

    for(; i > 0 ; --i) {
      without_stack[i] = jex.timerLoop(i, iterations, 0)/1000000;
      with_stack[i]    = jex.timerLoop(i, iterations, 1)/1000000;
    }
    i = depth;
    System.out.printf("|Depth| WriteStack(ms)| !WriteStack(ms)| Diff(%%)|\n");
    for(; i > 0 ; --i) {
      double ratio = (with_stack[i] / (double) without_stack[i]) * 100;
      System.out.printf("|%5d| %14.0f| %15.0f| %2.0f (%%)| \n", i + 2, with_stack[i] , without_stack[i], ratio);
      //System.out.printf("%d\t%.2f (ms)\n", i, ratio);
    }
  }
 private int thrower(int i, int mode) throws JavaException {
    ExArg.time_start[i] = System.nanoTime();
    if(mode == 0) { throw new JavaException("without stack", 1); }
    throw new JavaException("with stack");
  }
  private int catcher1(int i, int mode) throws JavaException{
    return this.stack_of_calls(i, mode);
  }
  private long timerLoop(int depth, int iterations, int mode) {
    for (int i = 0; i < iterations; i++) {
      try {
        this.catcher1(depth, mode);
      } catch (JavaException e) {
        ExArg.time_accum[depth] += (System.nanoTime() - ExArg.time_start[depth]);
      }
    }
    //long stop = System.nanoTime();
    return ExArg.time_accum[depth];
  }

  private int bad_method14(int i, int mode) throws JavaException  {
    if(i > 0) { this.thrower(i, mode); }
    return i;
  }
  private int bad_method13(int i, int mode) throws JavaException  {
    if(i == 13) { this.thrower(i, mode); }
    return bad_method14(i,mode);
  }
  private int bad_method12(int i, int mode) throws JavaException{
    if(i == 12) { this.thrower(i, mode); }
    return bad_method13(i,mode);
  }
  private int bad_method11(int i, int mode) throws JavaException{
    if(i == 11) { this.thrower(i, mode); }
    return bad_method12(i,mode);
  }
  private int bad_method10(int i, int mode) throws JavaException{
    if(i == 10) { this.thrower(i, mode); }
    return bad_method11(i,mode);
  }
  private int bad_method9(int i, int mode) throws JavaException{
    if(i == 9) { this.thrower(i, mode); }
    return bad_method10(i,mode);
  }
  private int bad_method8(int i, int mode) throws JavaException{
    if(i == 8) { this.thrower(i, mode); }
    return bad_method9(i,mode);
  }
  private int bad_method7(int i, int mode) throws JavaException{
    if(i == 7) { this.thrower(i, mode); }
    return bad_method8(i,mode);
  }
  private int bad_method6(int i, int mode) throws JavaException{
    if(i == 6) { this.thrower(i, mode); }
    return bad_method7(i,mode);
  }
  private int bad_method5(int i, int mode) throws JavaException{
    if(i == 5) { this.thrower(i, mode); }
    return bad_method6(i,mode);
  }
  private int bad_method4(int i, int mode) throws JavaException{
    if(i == 4) { this.thrower(i, mode); }
    return bad_method5(i,mode);
  }
  protected int bad_method3(int i, int mode) throws JavaException{
    if(i == 3) { this.thrower(i, mode); }
    return bad_method4(i,mode);
  }
  private int bad_method2(int i, int mode) throws JavaException{
    if(i == 2) { this.thrower(i, mode); }
    return bad_method3(i,mode);
  }
  private int bad_method1(int i, int mode) throws JavaException{
    if(i == 1) { this.thrower(i, mode); }
    return bad_method2(i,mode);
  }
  private int stack_of_calls(int i, int mode) throws JavaException{
    if(i == 0) { this.thrower(i, mode); }
    return bad_method1(i,mode);
  }
}

class ExArg {
  public static long[] time_start;
  public static long[] time_accum;
  static {
     time_start = new long[20];
     time_accum = new long[20];
  };
}

Кадры стека в этом примере крошечные по сравнению с тем, что вы обычно найдете.

Вы можете посмотреть на байт-код, используя javap

javap -c -v -constants JavaException.class

то есть это для метода 4 ...

   protected int bad_method3(int, int) throws JavaException;
flags: ACC_PROTECTED
Code:
  stack=3, locals=3, args_size=3
     0: iload_1       
     1: iconst_3      
     2: if_icmpne     12
     5: aload_0       
     6: iload_1       
     7: iload_2       
     8: invokespecial #6                  // Method thrower:(II)I
    11: pop           
    12: aload_0       
    13: iload_1       
    14: iload_2       
    15: invokespecial #17                 // Method bad_method4:(II)I
    18: ireturn       
  LineNumberTable:
    line 63: 0
    line 64: 12
  StackMapTable: number_of_entries = 1
       frame_type = 12 /* same */

Exceptions:
  throws JavaException

Создание трассировки Exceptionсо nullстеком занимает примерно столько же времени, сколько throwи try-catchблок вместе. Однако заполнение трассировки стека занимает в среднем в 5 раз больше времени .

Я создал следующий тест, чтобы продемонстрировать влияние на производительность. Я добавил в -Djava.compiler=NONERun Configuration, чтобы отключить оптимизацию компилятора. Чтобы измерить влияние построения трассировки стека, я расширил Exceptionкласс, чтобы воспользоваться конструктором без стека:

class NoStackException extends Exception{
    public NoStackException() {
        super("",null,false,false);
    }
}

Контрольный код выглядит следующим образом:

public class ExceptionBenchmark {

    private static final int NUM_TRIES = 100000;

    public static void main(String[] args) {

        long throwCatchTime = 0, newExceptionTime = 0, newObjectTime = 0, noStackExceptionTime = 0;

        for (int i = 0; i < 30; i++) {
            throwCatchTime += throwCatchLoop();
            newExceptionTime += newExceptionLoop();
            newObjectTime += newObjectLoop();
            noStackExceptionTime += newNoStackExceptionLoop();
        }

        System.out.println("throwCatchTime = " + throwCatchTime / 30);
        System.out.println("newExceptionTime = " + newExceptionTime / 30);
        System.out.println("newStringTime = " + newObjectTime / 30);
        System.out.println("noStackExceptionTime = " + noStackExceptionTime / 30);

    }

    private static long throwCatchLoop() {
        Exception ex = new Exception(); //Instantiated here
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            try {
                throw ex; //repeatedly thrown
            } catch (Exception e) {

                // do nothing
            }
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

    private static long newExceptionLoop() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            Exception e = new Exception();
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

    private static long newObjectLoop() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            Object o = new Object();
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

    private static long newNoStackExceptionLoop() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            NoStackException e = new NoStackException();
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

}

Вывод:

throwCatchTime = 19
newExceptionTime = 77
newObjectTime = 3
noStackExceptionTime = 15

Это подразумевает, что создание a NoStackExceptionпримерно так же дорого, как и повторение одного и того же Exception. Это также показывает, что создание Exceptionи заполнение его трассировки стека занимает примерно в 4 раза больше времени.

Эта часть вопроса ...

Еще один способ задать вопрос: если я сделал один экземпляр Exception, а затем бросил и поймал его снова и снова, это было бы значительно быстрее, чем создание нового исключения каждый раз, когда я выбрасывал?

Кажется, спрашивается, улучшает ли производительность создание исключения и его кэширование где-нибудь. Да, это так. Это то же самое, что отключить запись стека при создании объекта, потому что это уже сделано.

Это время, которое я получил, пожалуйста, прочитайте предостережение после этого ...

|Depth| WriteStack(ms)| !WriteStack(ms)| Diff(%)|
|   16|            193|             251| 77 (%)| 
|   15|            390|             406| 96 (%)| 
|   14|            394|             401| 98 (%)| 
|   13|            381|             385| 99 (%)| 
|   12|            387|             370| 105 (%)| 
|   11|            368|             376| 98 (%)| 
|   10|            188|             192| 98 (%)| 
|    9|            193|             195| 99 (%)| 
|    8|            200|             188| 106 (%)| 
|    7|            187|             184| 102 (%)| 
|    6|            196|             200| 98 (%)| 
|    5|            197|             193| 102 (%)| 
|    4|            198|             190| 104 (%)| 
|    3|            193|             183| 105 (%)| 

Конечно, проблема в том, что ваша трассировка стека теперь указывает на то, где вы создали экземпляр объекта, а не на тот, откуда он был брошен.

Используя ответ @ AustinD в качестве отправной точки, я сделал несколько настроек. Код внизу.

Помимо добавления случая, когда один экземпляр Exception генерируется неоднократно, я также отключил оптимизацию компилятора, чтобы мы могли получить точные результаты производительности. Я добавил -Djava.compiler=NONEк аргументам VM согласно этому ответу . (В eclipse отредактируйте Run Configuration → Arguments, чтобы установить этот аргумент VM)

Результаты:

new Exception + throw/catch = 643.5
new Exception only          = 510.7
throw/catch only            = 115.2
new String (benchmark)      = 669.8

Поэтому создание исключения стоит примерно в 5 раз дороже, чем его выбрасывание + отлов. Предполагая, что компилятор не оптимизирует большую часть затрат.

Для сравнения, вот тот же тестовый прогон без отключения оптимизации:

new Exception + throw/catch = 382.6
new Exception only          = 379.5
throw/catch only            = 0.3
new String (benchmark)      = 15.6

Код:

public class ExceptionPerformanceTest {

    private static final int NUM_TRIES = 1000000;

    public static void main(String[] args) {

        double numIterations = 10;

        long exceptionPlusCatchTime = 0, excepTime = 0, strTime = 0, throwTime = 0;

        for (int i = 0; i < numIterations; i++) {
            exceptionPlusCatchTime += exceptionPlusCatchBlock();
            excepTime += createException();
            throwTime += catchBlock();
            strTime += createString();
        }

        System.out.println("new Exception + throw/catch = " + exceptionPlusCatchTime / numIterations);
        System.out.println("new Exception only          = " + excepTime / numIterations);
        System.out.println("throw/catch only            = " + throwTime / numIterations);
        System.out.println("new String (benchmark)      = " + strTime / numIterations);

    }

    private static long exceptionPlusCatchBlock() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            try {
                throw new Exception();
            } catch (Exception e) {
                // do nothing
            }
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

    private static long createException() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            Exception e = new Exception();
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

    private static long createString() {
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            Object o = new String("" + i);
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }

    private static long catchBlock() {
        Exception ex = new Exception(); //Instantiated here
        long start = System.currentTimeMillis();
        for (int i = 0; i < NUM_TRIES; i++) {
            try {
                throw ex; //repeatedly thrown
            } catch (Exception e) {
                // do nothing
            }
        }
        long stop = System.currentTimeMillis();
        return stop - start;
    }
}