Tại sao dòng song song với lambda trong bộ khởi tạo tĩnh lại gây ra bế tắc?

Tôi đã gặp một tình huống kỳ lạ khi sử dụng một luồng song song với lambda trong trình khởi tạo tĩnh dường như vĩnh viễn mà không sử dụng CPU. Đây là mã:

class Deadlock {
    static {
        IntStream.range(0, 10000).parallel().map(i -> i).count();
        System.out.println("done");
    }
    public static void main(final String[] args) {}
}

Đây dường như là một trường hợp thử nghiệm tái tạo tối thiểu cho hành vi này. Nếu tôi:

• đặt khối trong phương thức chính thay vì một trình khởi tạo tĩnh,
• loại bỏ song song hóa, hoặc
• loại bỏ lambda,

mã hoàn thành ngay lập tức. Bất cứ ai có thể giải thích hành vi này? Nó là một lỗi hay là dự định này?

Tôi đang sử dụng OpenJDK phiên bản 1.8.0_66-nội bộ.

Tôi đã tìm thấy một báo cáo lỗi về một trường hợp rất tương tự ( JDK-8143380 ) bị Stuart Marks đóng là "Không phải sự cố":

Đây là một bế tắc khởi tạo lớp. Luồng chính của chương trình thử nghiệm thực thi trình khởi tạo tĩnh của lớp, thiết lập cờ đang trong quá trình khởi tạo cho lớp; cờ này vẫn được đặt cho đến khi trình khởi tạo tĩnh hoàn thành. Trình khởi tạo tĩnh thực thi một luồng song song, điều này khiến các biểu thức lambda được đánh giá trong các luồng khác. Các khối luồng đó đang đợi lớp hoàn thành khởi tạo. Tuy nhiên, luồng chính bị chặn khi chờ các tác vụ song song hoàn thành, dẫn đến bế tắc.

Chương trình kiểm tra nên được thay đổi để di chuyển logic dòng song song ra bên ngoài bộ khởi tạo tĩnh của lớp. Đóng cửa không phải là một vấn đề.

Tôi có thể tìm thấy một báo cáo lỗi khác về vấn đề đó ( JDK-8136753 ), cũng bị đóng là "Không phải sự cố" của Stuart Marks:

Đây là một bế tắc đang xảy ra vì trình khởi tạo tĩnh của Fruit enum đang tương tác không tốt với việc khởi tạo lớp.

Xem Đặc tả ngôn ngữ Java, phần 12.4.2 để biết chi tiết về khởi tạo lớp.

http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.2

Tóm lại, những gì đang xảy ra như sau.

1. Luồng chính tham chiếu đến lớp Fruit và bắt đầu quá trình khởi tạo. Điều này đặt cờ đang trong quá trình khởi tạo và chạy trình khởi tạo tĩnh trên luồng chính.
2. Trình khởi tạo tĩnh chạy một số mã trong một luồng khác và đợi nó kết thúc. Ví dụ này sử dụng các luồng song song, nhưng điều này không liên quan gì đến các luồng. Việc thực thi mã trong một luồng khác bằng bất kỳ phương tiện nào và đợi mã đó kết thúc, sẽ có tác dụng tương tự.
3. Mã trong luồng khác tham chiếu đến lớp Fruit, lớp này kiểm tra cờ đang khởi tạo. Điều này làm cho luồng khác bị chặn cho đến khi cờ bị xóa. (Xem bước 2 của JLS 12.4.2.)
4. Luồng chính bị chặn khi chờ luồng khác kết thúc, do đó, trình khởi tạo tĩnh không bao giờ hoàn thành. Vì cờ đang trong quá trình khởi tạo không được xóa cho đến khi trình khởi tạo tĩnh hoàn thành, các luồng bị khóa.

Để tránh vấn đề này, hãy đảm bảo rằng quá trình khởi tạo tĩnh của một lớp hoàn tất nhanh chóng, mà không khiến các luồng khác thực thi mã yêu cầu lớp này phải hoàn thành khởi tạo.

Đóng cửa không phải là một vấn đề.

Lưu ý rằng FindBugs có một vấn đề mở khi thêm cảnh báo cho tình huống này.

Đối với những người đang tự hỏi đâu là các luồng khác tham chiếu đến Deadlockchính lớp đó, các lambdas Java hoạt động như bạn đã viết sau:

public class Deadlock {
    public static int lambda1(int i) {
        return i;
    }
    static {
        IntStream.range(0, 10000).parallel().map(new IntUnaryOperator() {
            @Override
            public int applyAsInt(int operand) {
                return lambda1(operand);
            }
        }).count();
        System.out.println("done");
    }
    public static void main(final String[] args) {}
}

Với các lớp ẩn danh thông thường không có bế tắc:

public class Deadlock {
    static {
        IntStream.range(0, 10000).parallel().map(new IntUnaryOperator() {
            @Override
            public int applyAsInt(int operand) {
                return operand;
            }
        }).count();
        System.out.println("done");
    }
    public static void main(final String[] args) {}
}

Có một lời giải thích tuyệt vời về vấn đề này bởi Andrei Pangin , ngày 07 tháng 4 năm 2015. Nó có sẵn ở đây , nhưng nó được viết bằng tiếng Nga (tôi khuyên bạn nên xem lại các mẫu mã - chúng là quốc tế). Vấn đề chung là một khóa trong quá trình khởi tạo lớp.

Dưới đây là một số trích dẫn từ bài báo:

Theo JLS , mọi lớp đều có một khóa khởi tạo duy nhất được bắt trong quá trình khởi tạo. Khi luồng khác cố gắng truy cập lớp này trong quá trình khởi tạo, nó sẽ bị chặn trên khóa cho đến khi quá trình khởi tạo hoàn tất. Khi các lớp được khởi tạo đồng thời, có thể xảy ra tình trạng bế tắc.

Tôi đã viết một chương trình đơn giản tính tổng các số nguyên, nó sẽ in ra những gì?

public class StreamSum {
    static final int SUM = IntStream.range(0, 100).parallel().reduce((n, m) -> n + m).getAsInt();

    public static void main(String[] args) {
        System.out.println(SUM);
    }
} 

Bây giờ xóa parallel()hoặc thay thế lambda bằng Integer::sumlệnh gọi - điều gì sẽ thay đổi?

Ở đây chúng ta lại thấy deadlock [đã có một số ví dụ về deadlock trong trình khởi tạo lớp trước đây trong bài viết]. Do các parallel()hoạt động luồng chạy trong một nhóm luồng riêng biệt. Các luồng này cố gắng thực thi lambda body, được viết bằng bytecode như một private staticphương thức bên trong StreamSumlớp. Nhưng phương thức này không thể được thực thi trước khi hoàn thành trình khởi tạo tĩnh của lớp, phương thức này sẽ đợi kết quả hoàn thành luồng.

Suy nghĩ nhiều hơn là gì: mã này hoạt động khác nhau trong các môi trường khác nhau. Nó sẽ hoạt động chính xác trên một máy CPU và rất có thể sẽ bị treo trên máy nhiều CPU. Sự khác biệt này đến từ việc triển khai nhóm Fork-Join. Bạn có thể tự xác minh việc thay đổi thông số-Djava.util.concurrent.ForkJoinPool.common.parallelism=N