2017-01-24 7 views
0

Ich habe ein unerwartetes Problem. In meinem Projekt verwende ich Objekt vom Typ java.io.bufferedReader, um einige Daten zu lesen. Es enthält die readLine() -Methode, die die nächste Textzeile aus der Quelle liest.java.io.InputStreamReader.ready() blockiert die Ausführung

aber das Problem mit dieser Methode ist, dass wenn Source nicht bereit ist blockiert es die Ausführung des Threads, die diese Methode aufgerufen, bis die Quelle etwas zu lesen hat.

Glücklicherweise hat bufferedReader bereit() -Methode, die mir Wetterquelle ist bereit oder nicht, so kann ich es einmal und eine Weile zu sehen, Wetter gibt es etwas aus der Quelle zu lesen, und wenn nicht weiter zu tun Arbeitsplätze. es funktioniert meistens gut, aber heute habe ich etwas seltsames bemerkt.

in einigen seltenen Fällen, wenn ich rufe ready() Methode bereit Methode selbst blockiert die Ausführung.

so bin ich überrascht, da ready() -Methode ist nur wahr, wenn es absolut sicher ist, dass read * -Methode nicht blockieren würde.

Wie von "erwin" unten erwähnt, ist das eigentliche Problem nicht in java.io.BufferedReader, sondern im zugrunde liegenden Reader.

konstruierten gepufferten Leser ich benutze java.io.InputStreamReader.

auch wenn ich nicht BufferedReader erstellen, aber nur InputStreamReader direkt verwenden, wenn ich ready() -Methode aufrufen, um diese Methode Blöcke aufrufen.

also, wie möglich ist, dass ready() -Methode blockiert, und wie man es vermeidet?

danke.

Antwort

2

Die ready() Methode in BufferedReader nie blockiert von selbst - Sie können dies leicht im Quellcode von BufferedReader überprüfen.

Der einzige Fall, in dem die ready() Verfahren von BufferedReader Blöcke ist, wenn die ready() Methode in den zugrunde liegenden Reader Blöcke (die, die Sie in den Konstruktor von BufferedReader bestanden). Daher sollte Ihre Frage in "[meine reale Leserklasse] geändert werden. Die read() -Methode blockiert die Ausführung".

Zum Beispiel, wenn die zugrunde liegenden Leser ein PipedReader sind, könnte es ein Problem sein, weil die ready() und die read() Methoden sowohl synchronized sind. Wenn ein Thread zum Lesen von einem PipedReader blockiert ist und ein anderer Thread PipedReader.ready() verwendet, um zu überprüfen, ob er lesen kann, blockiert der zweite Thread auch, bis der read() auf dem ersten Thread abgeschlossen ist.

+0

Hallo Erwin, und danke für Ihre Erklärung. Ich habe den zugrunde liegenden Reader vorher noch nicht überprüft, ich habe mich nie daran erinnert zu checken, bis du es mir gezeigt hast. sowieso zugrunde liegenden Leser ist Objekt des Typs "java.io.InputStreamReader", und es ist seine ready() -Methode, die tatsächlich blockiert, wenn sie aufgerufen wird. –

+1

@SYOBSYOT InputStreamReader liest (wieder) von einem zugrunde liegenden InputStream. Es hängt also davon ab, welche Art von InputStream. Ein FileInputStream blockiert normalerweise nicht, aber auf einem fest installierten Netzwerkdateisystem kann dies passieren. Ein PipedInputStream könnte aus demselben Grund wie ein PipedReader blockieren. –

+0

Hallo Erwin, und danke für Ihre Antwort. Nun, haha, in diesem Fall wäre es das Beste, wenn ich die ganze Zeile kopiere, die ich benutze, um mein Bufferead-Reader-Objekt zu erstellen. Also das ist der Code: 'BUFFERED_INPUT = new java.io.BufferedReader (neuer java.io.InputStreamReader (CLIENT.GET_SOCKET(). GetInputStream())); ' In diesem Code gibt die Methode" GET_SOCKET() "das Objekt vom Typ" java.net.Socket "und" getInputStream() "zurück. "Methode der Socket-Klasse gibt das Objekt vom Typ" java.io.InputStream "zurück, mit dem ich den InputStreamReader erzeuge, der dann zum Erstellen von BufferedReader verwendet wird. –

Verwandte Themen