Warum BufferedInputStream ein Feld auf eine lokale Variable kopieren, anstatt das Feld verwenden, um direkt

Question

Wenn ich den Quellcode von java.io.BufferedInputStream.getInIfOpen() lesen, ich bin verwirrt darüber, warum es Code wie folgt geschrieben:

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

Warum ist es mit die Alias ​​stattdessen die Feldvariable der Verwendung in wie unten direkt:

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

Kann jemand eine vernünftige Erklärung geben?

Answer 1

Wenn Sie diesen Code aus dem Zusammenhang betrachten, gibt es keine gute Erklärung für diesen "Alias". Es ist einfach redundanter Code oder schlechter Code-Stil.

Aber der Kontext ist, dass BufferedInputStream ist eine Klasse, die unterklassifiziert werden kann, und dass es in einem Multi-Thread-Kontext arbeiten muss.

Der Hinweis ist, dass in in FilterInputStream ist protected volatile deklariert ist. Das bedeutet, dass die Möglichkeit besteht, dass eine Unterklasse den Wert null bis in erreichen kann. In Anbetracht dieser Möglichkeit ist der "Alias" tatsächlich da, um eine Wettlaufsituation zu verhindern.

Betrachten Sie den Code ohne "alias"

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

1. Thread A getInIfOpen()
2. Thread A wertet ruft in == null und sieht, dass in nicht null ist.
3. Gewinde B weist null zu in zu.
4. Thread A führt return in aus. Was null zurückgibt, weil a ein volatile ist.

Der "Alias" verhindert dies. Jetzt wird in nur einmal nach Thread A gelesen. Wenn Thread B null zuweist, nachdem Thread A in hat, spielt es keine Rolle. Thread A wird entweder eine Ausnahme auslösen oder einen (garantierten) Nicht-Null-Wert zurückgeben.

Answer 2

Dies liegt daran, dass die Klasse BufferedInputStream für die Verwendung mit mehreren Threads ausgelegt ist.

Hier sehen Sie die Deklaration von in, die in der übergeordneten Klasse FilterInputStream platziert wird:

protected volatile InputStream in; 

Da es protected ist, kann ihr Wert durch eine Unterklasse von FilterInputStream geändert werden, einschließlich BufferedInputStream und ihren Unterklassen . Außerdem wird volatile deklariert, was bedeutet, dass, wenn ein Thread den Wert der Variablen ändert, diese Änderung sofort in allen anderen Threads widergespiegelt wird. Diese Kombination ist schlecht, da es bedeutet, dass die Klasse BufferedInputStream keine Möglichkeit hat, zu steuern oder zu wissen, wenn in geändert wird. Daher kann der Wert sogar zwischen der Überprüfung auf Null und der Rückgabeanweisung in BufferedInputStream::getInIfOpen geändert werden, wodurch die Überprüfung auf Null praktisch unbrauchbar wird.Wenn Sie den Wert in nur einmal lesen, um ihn in der lokalen Variablen input zwischenzuspeichern, ist die Methode BufferedInputStream::getInIfOpen sicher gegen Änderungen von anderen Threads, da lokale Variablen immer im Besitz eines einzelnen Threads sind.

Es ist ein Beispiel, in BufferedInputStream::close, die in auf null setzt:

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 Wenn von einem anderen Thread aufgerufen wird, während BufferedInputStream::getInIfOpen ausgeführt wird, würde dies in der Race-Bedingung oben beschrieben führen.

Answer 3

Dies ist ein so kurzer Code, aber theoretisch in einer Umgebung mit mehreren Threads, kann in direkt nach dem Vergleich ändern, so dass die Methode etwas zurückgeben konnte es nicht überprüfen hat (es könnte null zurückkehren, damit die tut genau, was es verhindern sollte).

Answer 4

Ich glaube, die Erfassung der Klassenvariable in auf die lokale Variable input ist inkonsistentes Verhalten zu verhindern, wenn in Wechsel von einem anderen Thread ist während getInIfOpen() läuft.

Beachten Sie, dass der Besitzer von in die Elternklasse ist und nicht als final markiert.

Dieses Muster wird in anderen Teilen der Klasse repliziert und scheint eine vernünftige defensive Codierung zu sein.