Ich habe zwei Antworten auf SO gesehen, die behaupten, dass die von Java bereitgestellten Klassen PipedInputStream und PipedOutputStream fehlerhaft sind. Aber sie erklärten nicht, was mit ihnen los war. Sind sie wirklich fehlerhaft, und wenn ja, auf welche Weise? Ich schreibe gerade einen Code, der sie benutzt, also würde ich gerne wissen, ob ich falsch abgebogen bin.
Eine Antwort sagte:
Für mich scheint das weder bizarr noch kaputt zu sein. Vielleicht hat der Autor auch einige andere Fehler im Sinn?
PipedInputStreamundPipedOutputStreamsind gebrochen (in Bezug auf Threading). Sie gehen davon aus, dass jede Instanz an einen bestimmten Thread gebunden ist. Das ist bizarr.
Eine andere Antwort sagte:
In der Praxis werden sie am besten vermieden. Ich habe sie einmal in 13 Jahren benutzt und ich wünschte ich hätte es nicht.
Aber dieser Autor konnte sich nicht erinnern, was das Problem war.
Wie bei allen Klassen und insbesondere bei Klassen, die in mehreren Threads verwendet werden, haben Sie Probleme, wenn Sie sie missbrauchen. Ich denke also nicht an die unvorhersehbare "schreibe end dead" IOException Das PipedInputStream kann einen Fehler verursachen (fehlgeschlagen in close() Der verbundene PipedOutputStream ist ein Fehler; siehe den Artikel Was ist das? IOException: Schreiben Sie tot tot , von Daniel Ferbers, für weitere Informationen). Welche anderen behaupteten Mängel gibt es?
Sie sind nicht fehlerhaft.
Wie bei allen Klassen und insbesondere bei Klassen, die in mehreren Threads verwendet werden, haben Sie Probleme, wenn Sie sie missbrauchen. Das unberechenbare "Schreibende tot" IOException , das PipedInputStream werfen kann, ist kein Fehler (fehlgeschlagen in close() Der verbundene PipedOutputStream ist ein Fehler; siehe den Artikel Was ist das? IOException: Schreibe Ende tot , von Daniel Ferbers, für weitere Informationen ).
Ich habe sie gut in meinem Projekt verwendet und sie sind von unschätzbarem Wert, um Streams im laufenden Betrieb zu modifizieren und sie herumzugeben. Der einzige Nachteil schien zu sein, dass PipedInputStream einen kurzen Puffer hatte (ungefähr 1024) und mein Ausgangsstrom pumpte ungefähr 8KBs hinein.
Es gibt keinen Defekt damit und es funktioniert perfekt.
-------- Beispiel in groovy
%Vor%}
%Vor%}
Die Fehler, die ich bei der JDK-Implementierung sehe, sind:
1) Keine Timeouts, Leser oder Schreiber können unendlich blockieren.
2) Suboptimale Kontrolle darüber, wann Daten übertragen werden (sollte nur mit Flush erfolgen, oder wenn der Ringpuffer voll ist)
Also habe ich meine eigene erstellt, um das obige zu adressieren (Timeout-Wert über ein ThreadLocal):
Wie zu verwenden:
Ich hoffe, es hilft ...
Aus meiner Sicht gibt es einen Fehler. Genauer gesagt besteht ein hohes Risiko eines Deadlocks, wenn der Thread, der Daten in den PipedOutputStream pumpen soll, vorzeitig stirbt, bevor er tatsächlich ein einzelnes Byte in den Stream schreibt. Das Problem in einer solchen Situation ist, dass die Pipeline-Pipeline nicht in der Lage ist, das unterbrochene Rohr zu erkennen. Folglich wird das Thread-Lesen von PipedInputStream für immer (d. H. Deadlock) beim ersten Aufruf von read () warten.
Die Erkennung defekter Pipes beruht tatsächlich auf dem ersten Aufruf von write (), da die Implementierung den Thread auf der schreibenden Seite initialisiert und erst ab diesem Zeitpunkt funktioniert die Erkennung unterbrochener Pipes.
Der folgende Code reproduziert die Situation:
%Vor%Tags und Links java multithreading io