เหตุใด BufferedInputStream จึงคัดลอกฟิลด์ไปยังตัวแปรโลคัลแทนที่จะใช้ฟิลด์โดยตรง

เมื่อฉันอ่านซอร์สโค้ดจากjava.io.BufferedInputStream.getInIfOpen()ฉันก็งงว่าทำไมมันถึงเขียนโค้ดแบบนี้:

/**
 * 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;
}

เหตุใดจึงใช้นามแฝงแทนการใช้ตัวแปรฟิลด์inโดยตรงเช่นด้านล่าง:

/**
 * 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;
}

มีใครสามารถให้คำอธิบายที่สมเหตุสมผลได้หรือไม่?

หากคุณดูโค้ดนี้จากบริบทไม่มีคำอธิบายที่ดีสำหรับ "นามแฝง" นั้น เป็นเพียงรหัสซ้ำซ้อนหรือรูปแบบรหัสที่ไม่ดี

แต่บริบทนั้นBufferedInputStreamเป็นคลาสที่สามารถแบ่งเป็นคลาสย่อยได้และจำเป็นต้องทำงานในบริบทที่มีหลายเธรด

เบาะแสคือการที่inจะมีการประกาศในมีFilterInputStream protected volatileนั่นหมายความว่ามีโอกาสที่คลาสย่อยสามารถเข้าถึงและมอบหมายnullให้inได้ ด้วยความเป็นไปได้ดังกล่าวจึงมี "นามแฝง" อยู่เพื่อป้องกันสภาพการแข่งขัน

พิจารณารหัสที่ไม่มี "นามแฝง"

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

1. เธรดการโทร getInIfOpen()
2. ด้ายประเมินin == nullและเห็นว่าไม่innull
3. ด้ายกำหนด B ไปnullin
4. return inด้ายรัน ซึ่งผลตอบแทนnullเพราะaเป็นกvolatile.

"นามแฝง" ป้องกันสิ่งนี้ ตอนนี้inอ่านเพียงครั้งเดียวโดยเธรด A หากเธรด B กำหนดnullหลังเธรด A inก็ไม่สำคัญ เธรด A จะโยนข้อยกเว้นหรือส่งคืนค่าที่ไม่ใช่ค่าว่าง (รับประกัน)

เนื่องจากคลาสBufferedInputStreamนี้ออกแบบมาสำหรับการใช้งานแบบมัลติเธรด

ที่นี่คุณจะเห็นการประกาศinซึ่งวางอยู่ในคลาสพาเรนต์FilterInputStream:

protected volatile InputStream in;

เนื่องจากเป็นprotectedเช่นนั้นค่าของมันสามารถเปลี่ยนแปลงได้โดยคลาสย่อยใด ๆ ของFilterInputStreamรวมถึงBufferedInputStreamและคลาสย่อยของมัน นอกจากนี้ยังมีการประกาศvolatileซึ่งหมายความว่าหากเธรดใด ๆ เปลี่ยนแปลงค่าของตัวแปรการเปลี่ยนแปลงนี้จะปรากฏในเธรดอื่น ๆ ทั้งหมดทันที ชุดค่าผสมนี้ไม่ดีเนื่องจากหมายความว่าชั้นเรียนBufferedInputStreamไม่มีทางควบคุมหรือรู้ว่าเมื่อใดinมีการเปลี่ยนแปลง ดังนั้นค่ายังสามารถเปลี่ยนแปลงได้ระหว่างการตรวจสอบค่าว่างและคำสั่งส่งคืนในBufferedInputStream::getInIfOpenซึ่งทำให้การตรวจสอบค่าว่างเปล่าอย่างมีประสิทธิภาพ การอ่านค่าinเพียงครั้งเดียวเพื่อแคชในตัวแปรโลคัลinputเมธอดBufferedInputStream::getInIfOpenนี้ปลอดภัยต่อการเปลี่ยนแปลงจากเธรดอื่นเนื่องจากตัวแปรโลคัลจะเป็นของเธรดเดียวเสมอ

มีตัวอย่างBufferedInputStream::closeซึ่งตั้งinค่าเป็นโมฆะ:

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

หากBufferedInputStream::closeถูกเรียกโดยเธรดอื่นในขณะที่BufferedInputStream::getInIfOpenดำเนินการสิ่งนี้จะส่งผลให้เกิดสภาวะการแข่งขันที่อธิบายไว้ข้างต้น

นี่เป็นรหัสสั้น ๆ แต่ในทางทฤษฎีในสภาพแวดล้อมแบบมัลติเธรดinอาจเปลี่ยนแปลงทันทีหลังจากการเปรียบเทียบดังนั้นวิธีการสามารถส่งคืนสิ่งที่ไม่ได้ตรวจสอบ (สามารถคืนค่าnullได้ดังนั้นจึงทำสิ่งที่แน่นอนตามที่ตั้งใจไว้ ป้องกัน).

ฉันเชื่อว่าการจับตัวแปรคลาสinไปยังตัวแปรโลคัลinputคือการป้องกันพฤติกรรมที่ไม่สอดคล้องกันหากinเธรดอื่นเปลี่ยนแปลงในขณะที่getInIfOpen()กำลังทำงาน

ขอให้สังเกตว่าเจ้าของเป็นระดับผู้ปกครองและไม่ได้ทำเครื่องหมายว่าinfinal

รูปแบบนี้จำลองแบบในส่วนอื่น ๆ ของคลาสและดูเหมือนว่าจะเป็นการเข้ารหัสเชิงป้องกันที่สมเหตุสมผล