É caro usar blocos try-catch, mesmo que uma exceção nunca seja lançada?

Sabemos que é caro capturar exceções. Mas, também é caro usar um bloco try-catch em Java, mesmo que uma exceção nunca seja lançada?

Encontrei a pergunta / resposta do estouro de pilha Por que os blocos de tentativa são caros? , mas é para .NET .

tryquase não tem nenhuma despesa. Em vez de fazer o trabalho de configurar o trytempo de execução, os metadados do código são estruturados no tempo de compilação, de modo que, quando uma exceção é lançada, ele agora faz uma operação relativamente cara, subindo a pilha e ver se tryexistem blocos que capturariam isso. exceção. Do ponto de vista de um leigo, também trypode ser livre. Na verdade, está lançando a exceção que lhe custa - mas, a menos que você esteja lançando centenas ou milhares de exceções, você ainda não perceberá o custo.

trytem alguns custos menores associados a ele. Java não pode fazer algumas otimizações no código em um trybloco que faria de outra forma. Por exemplo, o Java geralmente reorganiza as instruções em um método para torná-lo mais rápido - mas o Java também precisa garantir que, se uma exceção for lançada, a execução do método seja observada como se suas instruções, como escritas no código-fonte, fossem executadas em ordem até alguma linha.

Como em um trybloco, uma exceção pode ser lançada (em qualquer linha do bloco try! Algumas exceções são lançadas de forma assíncrona, como chamar stopum Thread (que foi descontinuado) e, além disso, o OutOfMemoryError pode acontecer em quase qualquer lugar), e ainda assim pode ser capturado e o código continua sendo executado posteriormente no mesmo método, é mais difícil pensar em otimizações que podem ser feitas, portanto, é menos provável que isso aconteça. (Alguém precisaria programar o compilador para executá-los, argumentar e garantir a correção, etc. Seria uma grande dor para algo que deveria ser 'excepcional'). Mas, novamente, na prática, você não notará coisas assim.

Vamos medir, sim?

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);
        }
    }
}

No meu computador, isso imprime algo como:

try     0.598 ns
no try  0.601 ns

Pelo menos neste exemplo trivial, a instrução try não teve impacto mensurável no desempenho. Sinta-se livre para medir os mais complexos.

De um modo geral, recomendo não se preocupar com o custo de desempenho das construções de linguagem até que você tenha evidências de um problema real de desempenho em seu código. Ou, como Donald Knuth colocou : "a otimização prematura é a raiz de todo mal".

try/ catchpode ter algum impacto no desempenho. Isso ocorre porque impede que a JVM faça algumas otimizações. Joshua Bloch, em "Java Efetivo", disse o seguinte:

• A colocação do código dentro de um bloco try-catch inibe certas otimizações que as implementações modernas da JVM poderiam executar.

Sim, como os outros disseram, um trybloco inibe algumas otimizações entre os {}personagens que o cercam. Em particular, o otimizador deve assumir que uma exceção pode ocorrer em qualquer ponto do bloco, portanto, não há garantia de que as instruções sejam executadas.

Por exemplo:

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

Sem o try, o valor calculado para atribuir a xpode ser salvo como uma "subexpressão comum" e reutilizado para atribuir a y. Mas por causa dotry não há garantia de que a primeira expressão tenha sido avaliada, a expressão deve ser recalculada. Normalmente, isso não é um grande problema no código "linear", mas pode ser significativo em um loop.

Note-se, no entanto, que isso se aplica SOMENTE ao código JITCed. O javac faz apenas uma pequena quantidade de otimização e o custo do interpretador de bytecodes é zero para entrar / sair de um trybloco. (Não há bytecodes gerados para marcar os limites do bloco.)

E para bestsss:

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

Resultado:

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

saída 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
}

Não "GOTO".

Para entender por que as otimizações não podem ser executadas, é útil entender os mecanismos subjacentes. O exemplo mais sucinto que pude encontrar foi implementado nas macros C em: 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)

Os compiladores geralmente têm dificuldade em determinar se um salto pode ser localizado em X, Y e Z, para ignorar otimizações que não podem garantir a segurança, mas a implementação em si é bastante leve.

Mais uma marca de microbench ( fonte ).

Criei um teste no qual medi a versão do código try-catch e no-try-catch com base em uma porcentagem de exceção. A porcentagem de 10% significa que 10% dos casos de teste tiveram divisão por zero casos. Em uma situação, ele é tratado por um bloco try-catch, na outra por um operador condicional. Aqui está a minha tabela de resultados:

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

Porcentagem | Resultado (tente / se, ns)   
    0% 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

O que diz que não há diferença significativa entre nenhum desses casos.

Eu achei a captura do NullPointException bastante cara. Para operações de 1.2k, o tempo era de 200ms e 12ms quando eu o manipulava da mesma maneira com a if(object==null)qual foi bastante aprimorado para mim.