ich vor kurzem über Quasar lesen, die „leichten“/Go-like „Benutzermodus“ Threads auf die JVM bietet (es hat auch eine Erlang inspiriert Schauspieler System wie Akka aber das ist nicht die Hauptfrage)Leichte Fäden in Akka
zum Beispiel:
package jmodern;
import co.paralleluniverse.fibers.Fiber;
import co.paralleluniverse.strands.Strand;
import co.paralleluniverse.strands.channels.Channel;
import co.paralleluniverse.strands.channels.Channels;
public class Main {
public static void main(String[] args) throws Exception {
final Channel<Integer> ch = Channels.newChannel(0);
new Fiber<Void>(() -> {
for (int i = 0; i < 10; i++) {
Strand.sleep(100);
ch.send(i);
}
ch.close();
}).start();
new Fiber<Void>(() -> {
Integer x;
while((x = ch.receive()) != null)
System.out.println("--> " + x);
}).start().join(); // join waits for this fiber to finish
}
}
Soweit ich den Code zu verstehen ist oben nicht laichen alle JVM/Kernel-Threads, wird alles getan, was in Benutzermodus Threads (oder so behaupten sie), die billiger sein soll (nur wie Go-Routinen, wenn ich richtig verstanden habe)
Meine Frage ist das - soweit ich das verstehe, in Akka basiert alles noch auf JVM Threads, die meistens auf native OS Kernel-Threads (z. Pthreads in POSIX-Systemen), z.B. Soweit ich weiß, gibt es keine Benutzermodus-Threads/gehe wie Co-Routinen/Lightweight-Threads in Akka, habe ich das richtig verstanden?
Wenn ja, dann wissen Sie, ob es eine Design-Wahl ist? Oder gibt es in Akka in Zukunft einen Plan für Leichtgewichte?
Mein Verständnis ist, dass, wenn Sie eine Million Actors haben, aber die meisten von ihnen blockieren, dann Akka mit viel weniger physikalischen Threads umgehen kann, aber wenn die meisten von ihnen nicht blockiert sind und Sie noch etwas Reaktionsfähigkeit vom System benötigen Service Millionen von kleinen Anfragen für das Streaming einiger Daten), dann kann ich die Vorteile einer Benutzermodus Threading-Implementierung sehen, die viel mehr "Threads" am Leben mit geringeren Kosten der Schaffung von Switching und Beendigung (natürlich der einzige Vorteil ist die Reaktionsfähigkeit für viele Kunden gleichmäßig zu teilen, aber Reaktionsfähigkeit ist immer noch wichtig)
Ist mein Verständnis mehr oder weniger korrekt? Bitte korrigieren Sie mich, falls ich falsch liege.
* Ich könnte Benutzer-Modus-Threads mit Go/Co-Routinen und Lightweight-Threads völlig verwirren, die obige Frage beruht auf meinem schlechten Verständnis, dass sie alle einer der gleichen sind.
Das ist, was ich aus meiner Erfahrung mit Python erinnere. Und es ist keine direkte Antwort, aber es könnte nützlich sein. Sowohl Benutzer/Lightweight-Threads als auch tatsächliche Systemthreads haben ihre Verwendung. Es läuft darauf hinaus, beide bieten Nebenläufigkeit, aber nur Systemthreads bieten Parallelität. Wenn Sie also schwere Berechnungen durchführen, werden Sie durch die Verwendung von Benutzer-Threads keinen Boost bekommen, aber Sie werden von System-Threads profitieren. In einer anderen Situation, in der Sie nur einen CPU-Kern haben und einen Server benötigen, ist die Verwendung von Benutzer-Threads die einzige Lösung. – Andrey
Ja, das verstehe ich auch, z. Benutzer-Threads sind nur gut zum Bereitstellen einer "guten Nutzung" der CPU, z. Das Umschalten zwischen 2 Benutzer-Threads, die manchmal IO blockieren, ist billiger als die Verwendung von Full-blast-Threads. Sie nicht Parallelität, aber Sie tun eine bessere Auslastung der CPU, wenn ich das richtig verstanden –
einen Blick auf meine Antwort haben Sie, kann es hilfreich sein: http://stackoverflow.com/questions/29680718/relinquish-the-thread -cpu-bis-async-call-complete-in-akka-and-java/29748613 # 29748613 – circlespainter