Threads Java Chached Executors Service

[XHann3sX]

Hi,

ich wollte für ein Programm einige Aufgaben, die relativ lange dauern (encodieren und auf DB-speichern) auf Threads und Callable umsteigen, was auch gut funktioniert nun habe ich als ExecutorService einen chachedThreadPool, womit ich ja eigentlich eine unbestimmte Anzahl Threads ausführen kann, mit FixedThreadsPool gehen ja nur eine bestimmte Anzahl Threads, da ich aber nie weiß wie viele Threads gerade benötigt werden und diese auch etwas länger zum bearbeiten brauchen (1-2 Sekunden meine ich ca.) Dachte ich einfach mal das das am besten läuft.
Das Programm bzw die ganzen Anfragen klappen mit den Threads auch super, nur ist mir beim debuggen aufgefallen , das immer ein neuer Thread erstellt wird also z.b 1,2,3,4,5 und obwohl Thread 1 schon wieder fertig sein müsste wird trotzdem Thread 6 erstellt.
An sich ist es mir egal welche Zahl davorsteht nur wollte ich wissen ob diese "leeren" Threads Leistung im Sinne von Arbeitsspeicher oder Rechenleistung verbrauchen, weil ich schon mit ca 300-400 Threads am Tag rechne nicht, dass sich das nachher noch auf die Leistung auswirkt, oder würde es sich lohnen für jeden Aufruf einen neuen singleExecutor zu erstellen, da müsste der Speicher ja eigentlich nach Ablauf des Threads wieder freigegeben werden, den Excutor sollte der GC dann ja eigentlich finden oder ?

MFG
Hannes

 

[mrBrown]

Wenn der Executor immer neue Thread erstellt, läuft irgendwas falsch - um mehr zu sagen, müsste man aber Code sehen.

Generell ja; je mehr Threads, desto mehr CPU zeig wird "verschwendet" für Kontextwechsel und auch für RAM. Meistens allerdings nicht mit merkbaren Auswirkungen.

 

[JuKu]

Ein ExecutorService arbeitet mit Thread Pools.
Die maximale Anzahl an Threads, die dieser bekommen sollte, ist 2 * Anzahl der Cores.
Du solltest nur genau 1 ExecutorService für diesen UseCase verwenden und wenn du 4 Cores hat, dem maximal 8 Threasd zuweisen.

 

[mrBrown]

Die maximale Anzahl an Threads, die dieser bekommen sollte, ist 2 * Anzahl der Cores.
Du solltest nur genau 1 ExecutorService für diesen UseCase verwenden und wenn du 4 Cores hat, dem maximal 8 Threasd zuweisen.

Pauschal (und vermutlich auch in diesem Fall) ist das Unsinn - das hängt vom UseCase ab.

 

[XHann3sX]

ist 2 * Anzahl der Cores.
Du solltest nur genau 1 ExecutorService für diesen UseCase verwenden und wenn du 4 Cores hat, dem maximal 8 Threasd zuweisen.

Ich müsste jetzt erstmal die Wörter Cores und UseCase erfragen 😀
Sonst reden wir nachher aneinander vorbei

 

[XHann3sX]

Oke, habe mir die Bedeutungen nun selbst erschlossen, wie bin ich da nicht drauf gekommen :/
Wie wäre es denn , wenn ich einen Fixed Pool mit sagen wir mal 4 Threads erstelle und dann aber 5 Threads bearbeitet werden sollen , werden die dann einfach nacheinander abgearbeitet oder wie ?

 

[JuKu]

Pauschal (und vermutlich auch in diesem Fall) ist das Unsinn - das hängt vom UseCase ab.

Stimmt.
Ich meinte nur, dass eh nicht mehr parallel verarbeitet werden kann.
Jeder physische Intel Core hat 2 virtuelle Kerne --> 4 Cores --> 8 virtuelle Cores.
Demzufolge kann er maximal 8 Befehle gleichzeitig abarbeiten, alles andere wird vom Scheduler nach und nach abgearbeitet.
Wenn er jetzt aber für die Parallelisierung 16 Threads erstellt (bei 4 Cores), bringt ihm das ja recht wenig.

 

[XHann3sX]

Demzufolge kann er maximal 8 Befehle gleichzeitig abarbeiten, alles andere wird vom Scheduler nach und nach abgearbeitet.
Wenn er jetzt aber für die Parallelisierung 16 Threads erstellt (bei 4 Cores), bringt ihm das ja recht wenig.

Eigentlich bringt mich das in meinem Fall relativ weit, da der eigentliche Sinn nur darin besteht, diese rechenintensiven Aufgaben im Hintergrund abarbeiten soll. Damit diese das Hauptprogramm nicht blockieren sollen, das heißt würde ich einen Fixed Pool mit 4 Threads maximal nehmen und dann 5 Mal gleichzeitig diese Aufgabe abarbeiten will, werden dann erst die 4 ersten und dann der 5 wenn der erste von 4 durch ist ??

 

[mrBrown]

Ja, genau.

Im Zweifel würde ich es aber einfach mal mit mehr und mit weniger testen.
Datenbank ist uU recht IO-lastig, da können mehr Threads als (virtuelle) Kerne helfen

 

[JuKu]

Wichtig:
Falls ein Runnable auf I/O o.ä. wartet, merkt das der Executor Service nicht, d.h. dieser Slot / Runnable blockiert dann eben den ganzen Thread.
Den Rest hat mrBrown schon gesagt.

 

[mrBrown]

Falls ein Runnable auf I/O o.ä. wartet, merkt das der Executor Service nicht, d.h. dieser Slot / Runnable blockiert dann eben den ganzen Thread.

Das ist jetzt keine Eigenheit des Executor Services, sondern ganz normal - beim Executor Service kann man aber mit der Wahl eines passenden dagegensteuern und das abfangen,

 

[JuKu]

Interessant!
Welcher Executor Service beachtet dies denn?

 

[mrBrown]

Alle, die keine feste Anzahl an Threads haben? Ist keine verfügbar, wird halt ein neuer gestartet.

Dürfte sich aber auch erweitern lassen, dass erst nach n Sekunden Wartezeit ein neuer erstellt wird, gibts bestimmt schon in irgendeiner Lib.


Ich würde aber generell IO und CPU-lastige Aufgaben auf verschiedene Executors aufteilen