È costoso utilizzare i blocchi try-catch anche se non viene mai generata un'eccezione?

Sappiamo che è costoso catturare eccezioni. Ma è anche costoso utilizzare un blocco try-catch in Java anche se non viene mai generata un'eccezione?

Ho trovato la domanda / risposta Stack Overflow Perché i blocchi try sono costosi? , ma è per .NET .

trynon ha quasi nessuna spesa. Invece di fare il lavoro di impostazione tryin fase di esecuzione, i metadati del codice sono strutturati in fase di compilazione in modo tale che quando viene generata un'eccezione, ora esegue un'operazione relativamente costosa di camminare nello stack e vedere se tryesistono blocchi che catturerebbero questo eccezione. Dal punto di vista di un laico, trypuò anche essere libero. In realtà sta generando l'eccezione che ti costa, ma a meno che tu non stia generando centinaia o migliaia di eccezioni, non noterai ancora il costo.

tryha alcuni costi minori associati. Java non può fare alcune ottimizzazioni sul codice in un tryblocco che altrimenti farebbe. Ad esempio, Java riorganizza spesso le istruzioni in un metodo per renderlo più veloce, ma Java deve anche garantire che se viene generata un'eccezione, l'esecuzione del metodo viene osservata come se le sue istruzioni, come scritte nel codice sorgente, fossero eseguite in ordine fino a qualche riga.

Perché in un tryblocco può essere generata un'eccezione (in qualsiasi riga del blocco try! Alcune eccezioni vengono generate in modo asincrono, ad esempio chiamando stopun thread (che è deprecato) e persino oltre che OutOfMemoryError può accadere quasi ovunque) e tuttavia può essere catturato e il codice continua a essere eseguito successivamente nello stesso metodo, è più difficile ragionare sulle ottimizzazioni che possono essere fatte, quindi hanno meno probabilità di accadere. (Qualcuno dovrebbe programmare il compilatore per eseguirli, ragionare e garantire la correttezza, ecc. Sarebbe un grande dolore per qualcosa che dovrebbe essere "eccezionale") Ma, di nuovo, in pratica non noterai cose come questa.

Misuriamolo, vero?

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

Sul mio computer, questo stampa qualcosa di simile:

try     0.598 ns
no try  0.601 ns

Almeno in questo banale esempio, la dichiarazione try non ha avuto alcun impatto misurabile sulle prestazioni. Sentiti libero di misurare quelli più complessi.

In generale, ti consiglio di non preoccuparti del costo prestazionale dei costrutti linguistici fino a quando non avrai prove di un reale problema prestazionale nel tuo codice. O come diceva Donald Knuth : "l'ottimizzazione prematura è la radice di tutti i mali".

try/ catchpotrebbe avere un impatto sulle prestazioni. Questo perché impedisce a JVM di eseguire alcune ottimizzazioni. Joshua Bloch, in "Effective Java", ha dichiarato quanto segue:

• L'inserimento di codice all'interno di un blocco try-catch inibisce alcune ottimizzazioni che potrebbero altrimenti eseguire le moderne implementazioni JVM.

Sì, come hanno detto gli altri, un tryblocco inibisce alcune ottimizzazioni tra i {}personaggi che lo circondano. In particolare, l'ottimizzatore deve presumere che un'eccezione possa verificarsi in qualsiasi punto all'interno del blocco, quindi non vi è alcuna garanzia che le istruzioni vengano eseguite.

Per esempio:

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

Senza il try, il valore calcolato da assegnare a xpotrebbe essere salvato come "sottoespressione comune" e riutilizzato per assegnare a y. Ma a causa del trynon vi è alcuna garanzia che la prima espressione sia mai stata valutata, quindi l'espressione deve essere ricalcolata. Questo di solito non è un grosso problema nel codice "straight-line", ma può essere significativo in un ciclo.

Va notato, tuttavia, che ciò si applica SOLO al codice JITC. javac ha solo una quantità di ottimizzazione e ha un costo zero per l'interprete bytecode per entrare / uscire da un tryblocco. (Non ci sono bytecode generati per contrassegnare i confini del blocco.)

E per i migliori:

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

Produzione:

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

uscita 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
}

Nessun "GOTO".

Per capire perché non è possibile eseguire le ottimizzazioni, è utile comprendere i meccanismi sottostanti. L'esempio più conciso che ho trovato è stato implementato nelle macro C su: 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)

I compilatori hanno spesso difficoltà a determinare se un salto può essere localizzato in X, Y e Z, quindi saltano le ottimizzazioni che non possono garantire di essere sicure, ma l'implementazione stessa è piuttosto leggera.

Ennesimo microbenchmark ( fonte ).

Ho creato un test in cui misuro la versione del codice try-catch e no-try-catch in base a una percentuale di eccezione. Una percentuale del 10% indica che il 10% dei casi di test era diviso per zero casi. In una situazione è gestito da un blocco try-catch, nell'altra da un operatore condizionale. Ecco la mia tabella dei risultati:

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

Percentuale | Risultato (prova / if, ns)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

Il che afferma che non esiste alcuna differenza significativa tra nessuno di questi casi.

Ho trovato NullPointException piuttosto costoso. Per le operazioni da 1,2k il tempo era di 200 ms e 12 ms quando l'ho gestito allo stesso modo con il if(object==null)quale è stato piuttosto un miglioramento per me.