Das JavaDoc für die Klasse InputStream sagt Folgendes:
Liest Bytes von Daten aus dem Eingangsstrom in ein Array von Bytes. Es wird versucht, so viele Bytes wie möglich, aber einen kleineren zu lesen Nummer kann gelesen werden. Die Anzahl der tatsächlich gelesenen Bytes wird als zurückgegeben eine ganze Zahl. Diese Methode blockiert bis zum Ende der Eingabedaten Datei wird erkannt oder eine Ausnahme wird ausgelöst.
Dies entspricht meiner Erfahrung auch. Siehe zum Beispiel den folgenden Beispielcode:
%Vor%Der erste Aufruf, Blöcke zu lesen (Puffer), bis Eingabedaten verfügbar sind. Die Methode kehrt jedoch zurück, nachdem zwei Bytes gelesen wurden, obwohl noch Platz im Byte-Puffer ist, was dem JavaDoc entspricht, der besagt, dass versucht wird, so viele Bytes wie möglich zu lesen, aber eine kleinere Anzahl lies '. Ist es jedoch garantiert, dass die Methode nicht blockiert, sobald mindestens ein Byte der Daten gelesen wird, wenn der Eingabestream von einem Socket kommt?
Der Grund, warum ich frage, ist, dass ich den folgenden Code auf dem kleinen Java-Web-Server NanoHTTPD gesehen habe, und ich habe mich gefragt Wenn eine HTTP-Anfrage, die kleiner als 8k Bytes ist (was die meisten Anfragen sind) potentiell den Block unbestimmt blockieren könnte, außer es gibt eine Garantie, dass sie nicht blockiert wird, sobald einige Daten gelesen wurden.
%Vor%Bearbeiten :
Lassen Sie mich noch einmal anhand eines relativ ähnlichen Codebeispiels veranschaulichen. EJP sagt, dass die Methode blockiert, bis entweder EOS signalisiert wird oder mindestens ein Datenbyte angekommen ist. In diesem Fall liest es so viele Datenbytes ein, ohne erneut zu blockieren, und gibt diese Zahl zurück. was der JavaDoc für die Methode read (byte [], int, int) in der Klasse InputStream. Wenn man sich jedoch den Quellcode ansieht, ist klar, dass die Methode tatsächlich blockiert, bis der Puffer voll ist. Ich habe es getestet, indem ich denselben Client wie oben verwendet habe und den InputStream-Code in eine statische Methode in meinem Server-Beispiel kopiert habe.
%Vor%Dieser Code wird ausgegeben:
%Vor%Jetzt sind nach fünf Sekunden eindeutig Daten verfügbar, die Methode blockiert jedoch immer noch den Versuch, den gesamten Puffer zu füllen. Dies scheint nicht der Fall zu sein, den Socket.getInputStream () zurückgibt, aber es ist garantiert , dass es niemals blockieren wird, sobald Daten verfügbar sind, wie das JavaDoc sagt, aber nicht wie das Quellcode zeigt?
Ist es jedoch garantiert, dass die Methode nicht blockiert, sobald mindestens ein Byte Daten gelesen wird, wenn der Eingabestrom von einem Socket kommt?
Ich glaube nicht, dass diese Frage irgendetwas bedeutet. Die Methode blockiert solange, bis entweder EOS signalisiert wird oder mindestens ein Datenbyte angekommen ist. In diesem Fall liest sie so viele Datenbytes ein, ohne erneut zu blockieren, und gibt diese Zahl zurück.
Ich sah den folgenden Code in dem kleinen Java-Webserver NanoHTTPD
Der Code ist falsch. Es macht die ungültige Annahme, dass der gesamte Header in der ersten Lesung geliefert wird. Ich würde erwarten, hier eine Schleife zu sehen, die so lange schleift, bis eine Leerzeile erkannt wird.
Ich habe mich gefragt, ob eine HTTP-Anfrage, die kleiner als 8k Bytes ist (was die meisten Anfragen sind) potentiell den Thread blockieren könnte, es sei denn, es gibt eine Garantie, dass sie nicht blockiert wird, sobald einige Daten gelesen wurden.
Wieder denke ich, dass das nichts bedeutet. Die Methode wird blockiert, bis mindestens ein Byte oder EOS angekommen ist. Zeitraum.
Tags und Links java io inputstream