Hiçbir zaman istisna atılmasa bile try-catch blokları kullanmak pahalı mıdır?

İstisnaları yakalamanın pahalı olduğunu biliyoruz. Ancak, bir istisna atılmasa bile Java'da bir try-catch bloğu kullanmak pahalı mıdır?

Stack Overflow soru / cevap buldum Neden denemek blok pahalı? , ancak .NET içindir .

tryneredeyse hiçbir masrafı yok. Çalışma tryzamanında kurulum işi yapmak yerine , kodun meta verileri derleme zamanında yapılandırılır, böylece bir istisna atıldığında, şimdi yığını yığmak ve trybunu yakalayacak herhangi bir blok olup olmadığını görmek nispeten pahalı bir işlem yapar istisna. Bir layman'ın bakış açısından, tryözgür de olabilir. Aslında size maliyeti olan istisnayı atıyor - ancak yüzlerce veya binlerce istisna atmadığınız sürece, maliyeti hala fark etmeyeceksiniz.

trybununla ilişkili bazı küçük maliyetleri vardır. Java, tryaksi takdirde yapacağı bir bloktaki kod üzerinde bazı optimizasyonlar yapamaz. Örneğin, Java genellikle daha hızlı çalışmasını sağlamak için bir yöntemdeki talimatları yeniden düzenler - ancak Java ayrıca bir istisna atılırsa, yöntemin yürütülmesinin, kaynak kodda yazıldığı gibi ifadelerine uyulduğunu da garanti etmelidir. bir sıraya kadar.

Çünkü bir tryblokta bir istisna atılabilir (try bloğunun herhangi bir satırında! Bir istisna stop(örneğin, kullanımdan kaldırılmış) çağırma ve hatta OutOfMemoryError hemen hemen her yerde olabilir) gibi bazı istisnalar eşzamansız olarak atılır ve yine de yakalanabilir ve daha sonra aynı yöntemde kod yürütülmeye devam ederse, yapılabilecek optimizasyonlar hakkında akıl yürütmek daha zordur, bu yüzden olma olasılığı daha düşüktür. (Birisi derleyiciyi bunları yapmak, doğrulamak ve doğruluğunu garanti etmek, vb. İçin programlamak zorunda kalacaktır. 'İstisnai' olması gereken bir şey için büyük bir acı olurdu) Ama yine, pratikte böyle şeyleri fark etmeyeceksiniz.

Ölçelim, olur mu?

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

Bilgisayarımda bu şöyle bir şey yazdırıyor:

try     0.598 ns
no try  0.601 ns

En azından bu önemsiz örnekte, try ifadesinin performans üzerinde ölçülebilir bir etkisi yoktu. Daha karmaşık olanları ölçmekten çekinmeyin.

Genel olarak konuşursak, kodunuzda gerçek bir performans sorunu olduğunuzu kanıtlayana kadar dil yapılarının performans maliyeti hakkında endişelenmemenizi öneririz. Veya Donald Knuth'un dediği gibi: "erken optimizasyon tüm kötülüklerin köküdür".

try/ catchPerformans üzerinde bazı etkileri olabilir. Bunun nedeni, JVM'nin bazı optimizasyonlar yapmasını engellemesidir. Joshua Bloch, "Etkili Java" da şunları söyledi:

• Kodu bir try-catch bloğu içine yerleştirmek, modern JVM uygulamalarının başka şekilde gerçekleştirebileceği bazı optimizasyonları engeller.

Evet, diğerlerinin söylediği gibi, bir tryblok {}onu çevreleyen karakterler arasında bazı optimizasyonları engeller . Özellikle, optimizer, blok içinde herhangi bir noktada bir istisnanın olabileceğini varsaymalıdır, bu nedenle ifadelerin yürütüldüğüne dair bir güvence yoktur.

Örneğin:

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

Öğesi olmadan, tryatamak için hesaplanan değer xbir "ortak alt ifade" olarak kaydedilebilir ve atamak için yeniden kullanılabilir y. Ancak tryilk ifadenin değerlendirildiğine dair bir güvence olmadığından, ifadenin yeniden hesaplanması gerekir. Bu genellikle "düz çizgi" kodunda çok önemli değildir, ancak bir döngüde önemli olabilir.

Ancak bunun SADECE JITCed kodu için geçerli olduğuna dikkat edilmelidir. Javac sadece bir miktar optimizasyon yapar ve bir tryblok girmek / bırakmak için bayt kodu yorumlayıcısının maliyeti sıfırdır . (Blok sınırlarını işaretlemek için oluşturulan bayt kodları yoktur.)

Ve bestsss için:

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

Çıktı:

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

javap çıkışı:

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" yok.

Optimizasyonların neden yapılamadığını anlamak için temel mekanizmaları anlamak faydalıdır. Bulabildiğim en kısa örnek C makrolarında şu adreste uygulandı: 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)

Derleyiciler genellikle bir sıçramanın X, Y ve Z'ye yerelleştirilip yerelleştirilemeyeceğini belirlemekte zorluk çekerler, bu nedenle güvenli olmayı garanti edemedikleri optimizasyonları atlarlar, ancak uygulamanın kendisi oldukça hafiftir.

Yine başka bir mikrobençmark ( kaynak ).

Bir istisna yüzdesine göre try-catch ve no-try-catch kodu sürümünü ölçtüğüm bir test oluşturdum. % 10, test vakalarının% 10'unun sıfır vakaya bölündüğü anlamına gelir. Bir durumda bir try-catch bloğu, diğerinde bir koşullu operatör tarafından ele alınır. İşte benim sonuçları tablosu:

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

Yüzde | Sonuç (try / if, ns)   
    % 0 | 88/90   
    % 1 | 89/87    
    % 10 | 86/97    
    % 90 | 85/83   

Bu, bu vakaların hiçbiri arasında önemli bir fark olmadığını söylüyor.

NullPointException'ı yakalamak oldukça pahalı buldum. 1.2k operasyonlar için zaman 200ms ve 12ms idi, aynı şekilde ele aldığımda benim için oldukça gelişti if(object==null).