Tại sao BufferedInputStream sao chép một trường vào một biến cục bộ thay vì sử dụng trường trực tiếp

Khi tôi đọc mã nguồn từ java.io.BufferedInputStream.getInIfOpen(), tôi bối rối không hiểu tại sao nó lại viết mã như thế này:

/**
 * Check to make sure that underlying input stream has not been
 * nulled out due to close; if not return it;
 */
private InputStream getInIfOpen() throws IOException {
    InputStream input = in;
    if (input == null)
        throw new IOException("Stream closed");
    return input;
}

Tại sao nó lại sử dụng bí danh thay vì sử dụng intrực tiếp biến trường như bên dưới:

/**
 * Check to make sure that underlying input stream has not been
 * nulled out due to close; if not return it;
 */
private InputStream getInIfOpen() throws IOException {
    if (in == null)
        throw new IOException("Stream closed");
    return in;
}

Ai đó có thể đưa ra một lời giải thích hợp lý?

Nếu bạn nhìn mã này ngoài ngữ cảnh thì không có lời giải thích tốt nào cho "bí danh" đó. Nó chỉ đơn giản là mã thừa hoặc kiểu mã kém.

Nhưng ngữ cảnh là BufferedInputStreammột lớp có thể được phân lớp và nó cần hoạt động trong bối cảnh đa luồng.

Đầu mối là inđược khai báo trong FilterInputStreamlà protected volatile. Điều đó có nghĩa là có khả năng một lớp con có thể tiếp cận và gán nullcho in. Với khả năng đó, "bí danh" thực sự ở đó để ngăn chặn tình trạng chủng tộc.

Hãy xem xét mã không có "bí danh"

private InputStream getInIfOpen() throws IOException {
    if (in == null)
        throw new IOException("Stream closed");
    return in;
}

1. Chuỗi cuộc gọi A getInIfOpen()
2. Thread A đánh giá in == nullvà thấy rằng inkhông phải null.
3. Chủ đề B gán nullcho in.
4. Luồng A thực thi return in. Mà trả về nullvì alà a volatile.

"Bí danh" ngăn chặn điều này. Bây giờ chỉ inđược đọc một lần bởi luồng A. Nếu luồng B chỉ định nullsau khi luồng A có inthì không thành vấn đề. Luồng A sẽ ném một ngoại lệ hoặc trả về một giá trị không null (được đảm bảo).

Điều này là do lớp BufferedInputStreamđược thiết kế để sử dụng đa luồng.

Tại đây, bạn thấy phần khai báo của in , được đặt trong lớp cha FilterInputStream:

protected volatile InputStream in;

Vì nó là như vậy protected, giá trị của nó có thể được thay đổi bởi bất kỳ lớp con nào của FilterInputStream, bao gồm BufferedInputStreamvà các lớp con của nó. Ngoài ra, nó được khai báo volatile, có nghĩa là nếu bất kỳ luồng nào thay đổi giá trị của biến, thay đổi này ngay lập tức sẽ được phản ánh trong tất cả các luồng khác. Sự kết hợp này là không tốt, vì nó có nghĩa là lớp BufferedInputStreamkhông có cách nào để kiểm soát hoặc biết khi nào inđược thay đổi. Do đó, giá trị thậm chí có thể được thay đổi giữa việc kiểm tra null và câu lệnh trả về BufferedInputStream::getInIfOpen, điều này làm cho việc kiểm tra null trở nên vô dụng. Bằng cách đọc giá trị inchỉ một lần để lưu vào bộ nhớ cache trong biến cục bộ input, phương pháp BufferedInputStream::getInIfOpennày an toàn trước những thay đổi từ các luồng khác, vì các biến cục bộ luôn thuộc sở hữu của một luồng duy nhất.

Có một ví dụ trong BufferedInputStream::close đó đặt inthành null:

public void close() throws IOException {
    byte[] buffer;
    while ( (buffer = buf) != null) {
        if (bufUpdater.compareAndSet(this, buffer, null)) {
            InputStream input = in;
            in = null;
            if (input != null)
                input.close();
            return;
        }
        // Else retry in case a new buf was CASed in fill()
    }
}

Nếu BufferedInputStream::closeđược gọi bởi một luồng khác trong khi BufferedInputStream::getInIfOpenđược thực thi, điều này sẽ dẫn đến điều kiện chủng tộc được mô tả ở trên.

Đây là một đoạn mã ngắn như vậy, nhưng về mặt lý thuyết, trong môi trường đa luồng, incó thể thay đổi ngay sau khi so sánh, vì vậy phương thức có thể trả về một thứ gì đó mà nó không kiểm tra (nó có thể trả về null, do đó làm đúng như ý muốn của nó ngăn chặn).

Tôi tin rằng việc nắm bắt biến lớp thành biến incục bộ inputlà để ngăn chặn hành vi không nhất quán nếu inbị thay đổi bởi một luồng khác trong khigetInIfOpen() đang chạy.

Lưu ý rằng chủ sở hữu của inlà lớp cha và không đánh dấu nó làfinal .

Mô hình này được nhân rộng trong các phần khác của lớp và có vẻ là mã hóa phòng thủ hợp lý.