ExecutorService Frage (concurrent Threads)

[Sekundentakt]

Hallo Gemeinde,

ich habe ein paar Fragen zum ExecutorService.

Hier mal ein paar Code-Beispiele:

while(someCondition)
   executorService.execute(new MyRunnable(mapToWorkOn)); //Hier erhalte ich irgendwann eine Exception, dass die maximale Anzahl an Threads erreicht ist.

MyRunnable t = new MyRunnable(mapToWorkOnQueue);
while(someCondition)
   executorService.execute(t);

Im ersten Beispiel laufe ich irgendwann in eine Exception, die mir sagt, dass zuviele native Threads erzeugt wurden.
Im zweiten Beispiel passiert das nicht. Ich vermute, dass das daran liegt, dass ich keine neuen MyRunnable-Objekte erzeuge, sondern immer das Selbe Objekt übergebe.
Mich würde jetzt interessieren, ob der executorService im zweiten Beispiel trotzdem jeden MyRunnable parallel ausführen lässt, oder nicht.
Der Unterschied zwischen beiden Versionen ist, dass der MyRunnable im zweiten Fall seine Daten aus einer Queue bezieht, diese also nicht immer neu via Konstruktor übergeben werden brauchen.

Das beabsichtigte Verhalten wäre, dass so viele MyRunnable-Instanzen wie nur möglich parallel Daten aus der Queue verarbeiten.

Welches der beiden Codebeispiele wäre hier der richtige Ansatz?
Oder gibt es da noch andere?
Referenzen zu BestPractices oder Ähnlichem sind immer gerne gesehen.

Beste Grüße
- Sekundentakt

 

[Frank1975]

Der 1. Ansatz ist der einzige "gute" Ansatz.

fraglich ist nur, warum Du so viele Threads nebeneinander machen musst. Je nachdem
was in dem Thread passiert verbraucht der einzelne Thread eine menge Speicher,
der irgendwann nicht mehr allokiert werden kann.

Ich habe mal eine Volltextindizierung gemacht und bin auf knappe 100 Threads gekommen.
Mehr hätten es zwar sein können jedoch ließ ab einer bestimmtenb Grenze die CPU Power dann nach,
so dass es fast so schnell war wie 10 Threads.

Ich würde eine Grenze setzen. Array und den mit x Threads füllen.

lass doch mal in Deiner Schleife einen Counter zählen und ausgeben wie viele Threads Du
generiert hast und dann siehst Du auch wann er aussteigt.

 

[Marco13]

Ähm ... *räusper*.... entweder ich habe bei ExecutorService etwas falsch verstanden, oder du, oder oder Name "MyThread" ist schrecklich unpassend, aber ... eigentlich dachte ich, dass man einem Executor ein Runnable übergibt - und nicht einen eigenen Thread. Die Threads verwaltet der Executor nämlich intern selbst, und man kann z.B. mit Executors (Java 2 Platform SE 5.0) einen erstellen, dem man von vornherein sagt, wie viele Threads er haben soll, oder Executors (Java 2 Platform SE 5.0) verwenden, wenn man die Anzahl vorher nicht kennt. Aber einen Thread statt eines Runnable übergeben sollte man da mit Sicherheit nicht...

 

[Marco13]

Ach ja, das grundsätzliche Ziel ...dass so viele MyThread-Instanzen wie nur möglich parallel Daten aus der Queue verarbeiten ist SEHR fragwürdig. Das bringt nichts als Ärger und verschwendete Resourcen. Mach' bestenfalls so viele Threads wie du Prozessoren/Kerne hast, vielleicht ein paar mehr, aber nicht so viele wie möglich :autsch:
Schau dazu auch mal hier [JavaSpecialists 149] - The Law of the Overstocked Haberdashery

 

[Sekundentakt]

Hallo,

danke für euer Feedback!

@Marco: Na klar, es geht um Runnables. myThread ist wirklich ein scheußlicher Name. Ich änder das mal.

@ Frank1975: Danke für den Hinweis. Ich werde das mal gleich umsetzen.

Ich habe jetzt einen FixedThreadPool mit einer Anzahl von 10 eingestellt, das spart den Counter und macht nach Deinen Ausführungen mehr Sinn .
Btw: Meine Aufgabe widmet sich ebenfalls der Textverarbeitung.
Allerdings habe ich im Moment eine Lösung, die vom Code her eine Mischung der beiden Beispiele ist:

mapToWorkOnQueue.put(data);
while(someCondition)
   executorService.execute(new MyRunnable(mapToWorkOnQueue)); //Hier erhalte ich irgendwann eine Exception, dass die maximale Anzahl an Threads erreicht ist.

Die Queue ist eine LinkedBlockingQueue und bietet mir den Vorteil, dass der Producer warten muss, bis die Consumer die Queue etwas geleert haben.
Ich bin gerade am Überlegen, ob ich statt eines put() lieber ein offer() mit TimeOut verwenden sollte.
Pro: Der Producer muss nicht nur warten bis Platz in der Queue ist, sondern etwas länger, sodass den Consumern mehr Arbeitszeit zugeteilt werden kann.
Kontra: Ist das nicht ein Nullsummenspiel? Und wenn nicht, sollte ich die Kapazität der Queue auf die Anzahl der Threads beschränken, die maximal ausgeführt werden können oder etwas darüber liegen?

Ich spiele da mal ein bisschen herum. Falls es zu solchen Szenarien Erfahrungen gibt, kann man sich im Nachhinein über die Ansätze austauschen.