Da es in der Regel sehr wenig Overhead in Bezug auf Speicherbedarf und Setup/Abbaukosten einer Go-Routine ist. Ist es sogar relevant, einen Thread-Arbeitspool (go routine) zu implementieren? Wann würden Sie einen Thread-Pool verwenden, anstatt eine Go-Routine pro Anfrage zu erstellen?Ist das Thread-Pooling für Go relevant?
Das Laichen und Halten von vielen Goroutines in Golang ist billig, aber es ist nicht kostenlos.
Auch Sie sollten sich daran erinnern, dass Gorotine selbst sehr billig sein kann, aber gleichzeitig viel Speicher innerhalb von Goroutine-Code zugewiesen werden kann. Sie möchten vielleicht die Anzahl der gleichzeitig laufenden Gatorutins beschränken.
Sie können Semaphore verwenden, um Ressourcen zu begrenzen. Ein anderer Ansatz (eher idiomatisch für go) ist die Verwendung von Ausführungspipelines mit Worker-Pools. Dieses Muster ist sehr gut in golang blog beschrieben.
Ja, es ist relevant. db/sql verwendet einen Pool von Verbindungen zur Datenbank, da für die Herstellung einer neuen Verbindung Zeit benötigt wird.
Dies ist ein wenig off topic - Pooling Datenbankverbindungen ist nicht ganz dasselbe wie Thread-Pooling. –
Wenn Sie blockierende IO verwenden, sollten Sie Thread-Pool statt Goroutine verwenden. – ymonad
@ymonad, was meinst du mit IO blockieren? In Go blockiert alles IO, das ist irgendwie der ganze Punkt seines Nebenläufigkeitsmodells. Wenn Sie Datei-IO meinen, die sich intern stark von Netzwerk-IO unterscheidet, dann handelt es sich überhaupt nicht um ein Problem. Es geht um tatsächliche Betriebssystem-Threads, die darauf warten, dass Systemaufrufe zurückgegeben werden. – creker
@crecker Was ich beabsichtigte war, dass so weit wie go's Netzwerk-Bibliothek, die nicht blockierend ist, nutzen Sie den Vorteil von M: N-Thread-Modell von Goroutine, wenn Sie jedoch Systemaufruf verwenden, die IO blockiert, den Go-Scheduler erstellt einen Thread pro Goroutine, daher kann die Verwendung des Thread-Pools eine Option sein. https://groups.google.com/forum/#!topic/golang-nuts/Luje-okL4jI – ymonad