Java NIO SocketChannel.read() mit Multithread

Question

Ich implementiere einen einfachen Dateiserver mit Java NIO mit einem auswählenden Thread und mehreren Worker-Threads (um echtes Lesen/Schreiben durchzuführen).

Der Hauptteil des Codes sieht wie folgt aus:

while (true) { 
    int num = selector.select(); 
    if (num > 0) { 
     Iterator<SelectionKey> keys = selector.selectedKeys().iterator(); 
     final SelectionKey key = keys.next(); 
     keys.remove(); 

     if (key.isValid()) { 
      if (key.isAcceptable()) { 
       accept(key); 
      } else if (key.isReadable()) { 
       performReadInWorkerThread (key); 
      } else if (key.isWritable()) { 
       performWriteInWorkerThread (key); 
      } 
     } 
    } 
} 

Wie man aus dem Code-Schnipsel sehen kann, wenn ein lesbarer/beschreibbares Kanal ausgewählt wird, abzuladen I die Lese-/Schreib von der Auswahl Gewinden zu einem Worker-Thread.

Jetzt ist das Problem, dass, wenn ein lesbarer Kanal an den Arbeiterthread übergeben wird, und bevor es aus dem Kanal liest/beginnt, der Auswahlfaden wiederholt wird und selector.select() den zuvor ausgewählten lesbaren Kanal auswählt (weil es immer noch gibt Eingabepuffer in dem Kanal, der noch nicht vollständig von dem zuvor zugewiesenen Worker-Thread belegt wurde), so dass der Kanal erneut an einen anderen Worker-Thread übergeben wird, was zu mehreren Worker-Threads führt, die den gleichen Kanal lesen.

Ich glaube, das ist ein Design-Problem. Meine Frage ist, wie kann ich sicherstellen, dass nur ein Thread gleichzeitig einen Kanal liest?

Answer 1

Warum? Der Lesevorgang wird nicht blockiert. Mach es im aktuellen Thread. Sie sind einfach für endlose Probleme auf diese Weise. Sie müssen OP_READ vor der Übergabe an den Lesethread abmelden, was einfach ist, aber der schwierige Teil ist, dass wenn der Lese-Thread den Lesevorgang beendet, er OP_READ erneut registrieren muss, was entweder (i) einen Selektor erfordert wakeup(), was bewirkt, dass der Auswahl-Thread ausgeführt wird, wenn möglicherweise nichts zu tun ist, was verschwenderisch ist, oder (ii) eine Warteschlange ausstehender Reregistrierungen verwendet, die den nächsten Lesevorgang auf diesem Kanal bis nach dem nächsten Mal verzögert wacht auf, was auch verschwenderisch ist, oder Sie müssen den Selektor sofort beim Hinzufügen zur Warteschlange aktivieren, was auch verschwenderisch ist, wenn nichts bereit ist. Ich habe nie eine überzeugende NIO-Architektur gesehen, die verschiedene Auswahl- und Lese-Threads verwendet hat.

Tun Sie dies nicht. Wenn Sie über Multithreading verfügen müssen, ordnen Sie Ihre Channels in Gruppen an, die jeweils über einen eigenen Selektor und einen eigenen Thread verfügen, und alle diese Threads führen ihre eigenen Lesevorgänge durch.

In ähnlicher Weise müssen Sie nicht in einen separaten Thread schreiben. Schreib einfach, wenn du etwas zu schreiben hast.

Answer 2

Überprüfen Sie die SelectionKey.cancel() Methode.

Answer 3

Für NIO, nur ein Prinzip im Kopf behalten: Lesen/schreiben in der Hauptauswahl Thread. Dieses Prinzip spiegelt die Hardware-Natur wider. Mach dir keine Sorgen, dass das Lesen in Hauptauswahl Thread nicht schnell ist. Im modernen Server ist die CPU immer schneller als die Netzwerkkarte. So ist das blockierungsfreie Lesen in einem Thread auch schneller als das Arbeiten mit Netzwerkkarten. Ein Thread ist bereits genug, um ein Paket zu lesen. Wir brauchen keine weiteren Threads.