Java: Viele Threads mit kurzer Lebensdauer

[Shink]

Wollte fragen, welche Nachteile es hat, wenn man in Java sehr oft neue Threads erzeugt, die aber nicht lange leben.

Klar ist natürlich: Durch Pooling ist das vermeidbar. (Außer man erstellt immer wieder einen neuen Timer, den man "cancled").
Klar ist auch: Die Erstellung eines Threads dauert eventuell einige Zeit.
Die Frage ist: Laufen einem in einer 24/7-Anwendung auf einem embedded Device (Busybox-Linux-Terminal) irgendwann die Ressourcen aus? Bekomm ich Speicherleichen oder ist der Zähler irgendwann am Ende (wenn ich mir den Threadname ausgeben lasse, wird immer eine höhere Zahl ausgegeben).

Performance ist nicht wirklich wichtig, wichtig wäre Zuverlässigkeit.

[Monger]

Gegenfrage: Wozu brauchst du viele Threads auf einem embedded System?


Bin kein Thread-Spezialist, aber afaik hat Java die Threadverwaltung ausserordentlich gut im Griff. Weder werden dir die Nummern ausgehen (der fängt einfach wieder bei Null an), noch wird der Speicher zugemüllt (dafür ist der Garbage Collector zu gut).

Wenn du nicht ständig hart an der physikalischen Speichergrenze arbeitest (was aber natürlich nicht nur für mehrere Threads problematisch wäre), solltest du dir darüber keine Gedanken machen.

[Shink]

Gegenfrage: Wozu brauchst du viele Threads auf einem embedded System?

- Mehrere Eingänge/Ausgänge, die gleichzeitig benutzt werden können.
- Damit ganz sicher nichts blockt, auch nicht wenn Teile der angeschlossenen Devices ausfallen und nichts zurückliefern.


Wenn du nicht ständig hart an der physikalischen Speichergrenze arbeitest (was aber natürlich nicht nur für mehrere Threads problematisch wäre), solltest du dir darüber keine Gedanken machen.
OK, das wollte ich hören.

[HellHorse]

Hängt von der Threadimplementation der JVM des embedded device ab.
Auf den Desktop VMs ist es kein Problem. So erstellt z.B. Azureus über die Zeit tausende kurzlebiger Threads.

[Monger]

- Mehrere Eingänge/Ausgänge, die gleichzeitig benutzt werden können.
- Damit ganz sicher nichts blockt, auch nicht wenn Teile der angeschlossenen Devices ausfallen und nichts zurückliefern.



Naja, dann bewegst du dich aber trotzdem noch in der Größenordnung von einigen dutzend bis wenigen hundert Threads, oder?

Naja, aber wie ja HellHorse bestätigt hat: mit einer vernünftigen VM sollte es gehen! :)

[Shink]

Naja, dann bewegst du dich aber trotzdem noch in der Größenordnung von einigen dutzend bis wenigen hundert Threads, oder?

Einige dutzend Threads gleichzeitig, aber bei unseren Belastungstests waren es dann schon mal 10.000 neue pro Tag. Zu einer OutOfMemoryException oder ähnlichen Runtime Errors ist es noch nicht gekommen, aber wenn z.B. die maximale Threadanzahl, die ein Prozess insgesamt erstellen darf, 2^32 ist, dann muss ich mir etwas einfallen lassen.

Klar könnte man die Threads eigentlich wiederverwenden, aber da ich sie in der normalen Ausführung bereits interrupt()e, will ich sie nicht nach ihrer Verwendung schlafen legen und bei Bedarf wieder interrupt()en, wenn es nicht sein muss. (Wer weiß, zu welchen Konstellationen es dann eventuell kommen kann).

Naja, aber wie ja HellHorse bestätigt hat: mit einer vernünftigen VM sollte es gehen! :)

Klar, ist die normale 1.4 JRE, nur dass einige Klassen, die ich nicht verwende, fehlen. Nur das Device ist eben ein "System-on-a-chip" mit dementsprechend wenigen Ressourcen.

[Mad-Marty]

Würde einen Worker Pool vorschlagen, so eine art universalthreads sofern möglich. Ist auch wesentlich Ressourcenschonender.

Wenn du 2^32 threads in absehbarer zeit denkst zu brauchen, ist dein konzept schrott. :biggrin:

Achja, wenns rein um netzwerksachen geht, ist evtl unblocking sockets / select's die lösung, weiss jetzt aber nicht genau wie das in J aussieht.

Die Besten optimierungen kommen nicht von der sprache oder dem compiler ... methoden und algorhythmen überdenken bringt meist am meisten.