Có tốn kém khi sử dụng các khối thử bắt ngay cả khi một ngoại lệ không bao giờ được ném không?

Chúng tôi biết rằng nó là đắt tiền để bắt ngoại lệ. Nhưng, có tốn kém không khi sử dụng khối thử bắt trong Java ngay cả khi một ngoại lệ không bao giờ được ném?

Tôi tìm thấy câu hỏi / câu trả lời Stack Overflow Tại sao các khối thử đắt tiền? , nhưng nó là dành cho .NET .

tryhầu như không có chi phí nào cả. Thay vì thực hiện công việc thiết lập trythời gian chạy, siêu dữ liệu của mã được cấu trúc vào thời gian biên dịch sao cho khi một ngoại lệ được ném ra, giờ đây nó thực hiện một thao tác tương đối tốn kém khi đi lên ngăn xếp và xem liệu có trykhối nào tồn tại sẽ bắt được điều này không ngoại lệ. Từ quan điểm của một giáo dân, trycũng có thể là miễn phí. Nó thực sự ném ngoại lệ khiến bạn phải trả giá - nhưng trừ khi bạn ném hàng trăm hoặc hàng nghìn ngoại lệ, bạn vẫn sẽ không nhận thấy chi phí.

trycó một số chi phí nhỏ liên quan đến nó. Java không thể thực hiện một số tối ưu hóa mã trong một trykhối mà nó sẽ làm. Ví dụ, Java thường sẽ sắp xếp lại các hướng dẫn trong một phương thức để làm cho nó chạy nhanh hơn - nhưng Java cũng cần đảm bảo rằng nếu một ngoại lệ được ném ra, việc thực thi phương thức được quan sát như thể các câu lệnh của nó, như được viết trong mã nguồn, được thực thi để lên đến một số dòng.

Bởi vì trong một trykhối, một ngoại lệ có thể được ném ra (tại bất kỳ dòng nào trong khối thử! Một số trường hợp ngoại lệ được ném không đồng bộ, chẳng hạn như bằng cách gọi stopvào một Chủ đề (không được chấp nhận), và thậm chí ngoài OutOfMemoryError có thể xảy ra ở hầu hết mọi nơi) có thể bị bắt và mã tiếp tục thực thi sau đó trong cùng một phương thức, khó khăn hơn để lý giải về việc tối ưu hóa có thể được thực hiện, vì vậy chúng ít có khả năng xảy ra. (Ai đó sẽ phải lập trình trình biên dịch để thực hiện chúng, lý do và đảm bảo tính chính xác, v.v. Nó sẽ là một nỗi đau lớn đối với một thứ gì đó có nghĩa là 'đặc biệt')

Chúng ta hãy đo nó, phải không?

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

Trên máy tính của tôi, cái này in ra một cái gì đó như:

try     0.598 ns
no try  0.601 ns

Ít nhất trong ví dụ tầm thường này, tuyên bố thử không có tác động có thể đo lường được đối với hiệu suất. Hãy đo những cái phức tạp hơn.

Nói chung, tôi khuyên bạn không nên lo lắng về chi phí hiệu năng của các cấu trúc ngôn ngữ cho đến khi bạn có bằng chứng về vấn đề hiệu suất thực tế trong mã của mình. Hay như Donald Knuth nói : "tối ưu hóa sớm là gốc rễ của mọi tội lỗi".

try/ catchcó thể có một số tác động đến hiệu suất. Điều này là do nó ngăn JVM thực hiện một số tối ưu hóa. Joshua Bloch, trong "Java hiệu quả", đã nói như sau:

• Việc đặt mã bên trong khối thử bắt sẽ ức chế một số tối ưu hóa nhất định mà các triển khai JVM hiện đại có thể thực hiện.

Đúng, như những người khác đã nói, một trykhối ức chế một số tối ưu hóa trên các {}nhân vật xung quanh nó. Cụ thể, trình tối ưu hóa phải cho rằng một ngoại lệ có thể xảy ra tại bất kỳ điểm nào trong khối, vì vậy không có gì đảm bảo rằng các câu lệnh được thực thi.

Ví dụ:

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

Nếu không có try, giá trị được tính để gán cho xcó thể được lưu dưới dạng "biểu thức con chung" và được sử dụng lại để gán cho y. Nhưng do trykhông có gì đảm bảo rằng biểu thức đầu tiên đã được đánh giá, nên biểu thức phải được tính toán lại. Đây thường không phải là một vấn đề lớn trong mã "đường thẳng", nhưng có thể có ý nghĩa trong một vòng lặp.

Tuy nhiên, cần lưu ý rằng điều này chỉ áp dụng cho mã JITCed. javac chỉ thực hiện một lượng tối ưu hóa nhỏ và không có chi phí nào cho trình thông dịch mã byte để nhập / rời một trykhối. (Không có mã byte được tạo để đánh dấu các ranh giới khối.)

Và cho bestsss:

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

Đầu ra:

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

đầu ra 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
}

Không có "GOTO".

Để hiểu tại sao tối ưu hóa không thể được thực hiện, rất hữu ích để hiểu các cơ chế cơ bản. Ví dụ ngắn gọn nhất mà tôi có thể tìm thấy đã được triển khai trong các macro C tại: 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)

Trình biên dịch thường gặp khó khăn trong việc xác định xem một bước nhảy có thể được định vị thành X, Y và Z hay không để họ bỏ qua các tối ưu hóa mà họ không thể đảm bảo an toàn, nhưng bản thân việc triển khai khá nhẹ.

Một microbenchmark khác ( nguồn ).

Tôi đã tạo một thử nghiệm trong đó tôi đo phiên bản mã thử bắt và không thử bắt dựa trên tỷ lệ phần trăm ngoại lệ. 10% phần trăm có nghĩa là 10% các trường hợp thử nghiệm được chia cho các trường hợp bằng không. Trong một tình huống, nó được xử lý bởi một khối thử bắt, trong trường hợp khác bởi một toán tử có điều kiện. Đây là bảng kết quả của tôi:

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

Tỷ lệ phần trăm | Kết quả (thử / nếu, ns)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

Mà nói rằng không có sự khác biệt đáng kể giữa bất kỳ trường hợp nào.

Tôi thấy việc bắt NullPointException khá tốn kém. Đối với các hoạt động 1,2 nghìn, thời gian là 200ms và 12ms khi tôi xử lý nó theo cùng một cách với if(object==null)đó là sự cải thiện khá lớn đối với tôi.