Oh gott dallas.. du hast echt keine Ahnung oder?
Da du deine tollen Zitate scheinbar in keinster Weise verstehst ein ganz kurzer Crashkurs:
Ein "Thread" ist ein Abarbeitungsstrang innerhalb eines Prozesses. Das bedeutet, dass innerhalb eine sog. "Prozesses" eine Vielzahl unterschiedlicher Threads laufen.
Diese Threads werden auf Multicore Prozessoren tatsächlich parallel abgearbeitet. Das bedeutet aber nicht, dass man auf einem Quadcore nur 4 Threads parallel laufen lassen kann. Auf einzelnen Cores werden auch mehrere Threads schein-parallel abgearbeitet. Das wird erreicht indem man die Prozessorzeit immer unterbricht und an einen anderen Thread weitergibt, während die restlichen Threads schlafen gelegt werden, bis man die aktuelle ausführung wieder unterbricht und einen anderen Thread weckt. Da das ganze mehrfach in einer Millisekunde passiert, werden die Threads scheinbar parallel abgearbeitet.
Was du da zitierst:
Quote:
|
A thread pool offers a solution to both the problem of thread life-cycle overhead and the problem of resource thrashing. By reusing threads for multiple tasks, the thread-creation overhead is spread over many tasks. As a bonus, because the thread already exists when a request arrives, the delay introduced by thread creation is eliminated. Thus, the request can be serviced immediately, rendering the application more responsive. Furthermore, by properly tuning the number of threads in the thread pool, you can prevent resource thrashing by forcing any requests in excess of a certain threshold to wait until a thread is available to process it.
|
hat nichts aber auch gar nichts damit zutun, dass die "Vorgänge die in einem ThredPool stecken fixe Werte haben müssen" ... das ist der wohl größte Dünnpfiff, den ich je gehört habe.
Bei ThreadPools geht es darum, dass dieser Mechanismus für das parallele Abarbeiten von Runnables oder auch Futures zu einem Performance - "overhead" führt. Damit man diesen "overhead" etwas umgeht, recycled man einfach alte Threads, und "schmeißt" neue Runnables oder Futures in den "Pool", damit sie von den alten Threads, die es noch gibt übernommen werden.
Der overhead zum initialisieren und schedulen neuer Threads wird damit ein stück weit auf viele Tasks aufgeteilt.
In den Emulatoren werden dazu beim Startup eine Konfigurierte Anzahl Threads "hochgefahren", wobei die Anzahl sich nicht nur an der Config orientiert, sondern auch an der verbauten Anzahl Cores...
Und dallas, tu uns einfach allen mal einen Gefallen und mach nicht immer einen auf dicke Hose, denn es mag ja sein, dass die Leute, die keine Ahnung haben, dir das in irgendeiner Weise abkaufen, aber jeder der auch nur etwas vom Java Programming versteht, macht sich über deine Aussagen lustig.
