Ich kann mir vorstellen, dass einige Aufgaben sehr lange dauern und ScheduledThreadPoolExecutor würde zusätzliche Threads für die anderen Aufgaben erstellen, die ausgeführt werden müssen, bis eine maximale Anzahl von Threads erreicht ist.Warum akzeptiert ScheduledThreadPoolExecutor nur eine feste Anzahl von Threads?
Aber scheint, dass ich nur eine feste Anzahl von Threads für den Pool angeben kann, warum ist das so?
Als das warum, weiß ich auch nicht. Aber ich kann es mir vorstellen.
Die Anzahl der Ressourcen eines Computers ist begrenzt. Nicht alle Ressourcen können gleichzeitig behandelt werden.
Wenn mehrere Prozesse gleichzeitig Dateien laden, werden sie langsamer geladen, als wenn sie sequenziell geladen werden (zumindest auf einer Festplatte).
Ein Prozessor hat auch eingeschränkte Unterstützung für die gleichzeitige Verarbeitung mehrerer Threads. Irgendwann wird das OS oder die JVM mehr Zeit damit verbringen, Threads zu wechseln, als Threads die Ausführung ihres Codes verbringen.
Das ist ein guter Grund für die ScheduledThreadPoolExecutor entworfen werden, wie es ist. Sie können eine beliebige Anzahl von Jobs in die Warteschlange stellen, es werden jedoch nie mehr Jobs zur gleichen Zeit ausgeführt als effizient ausgeführt werden können. Es liegt an Ihnen, das natürlich auszugleichen.
Wenn Ihre Aufgaben IO gebunden sind, würde ich die Poolgröße klein und wenn sie CPU-gebunden sind, ein bisschen größer (32 oder so). Sie können auch mehrere ScheduledThreadPoolExecutor s, eine für E/A-gebundene Aufgaben und eine für CPU-gebundene Aufgaben machen.
Während weiter über SchecduledThreadPoolExecutor Graben Ich fand diese link, Dieser Link erklärt ScheduledThreadPoolExecutor löst viele Probleme der Timer-Klasse. Und auch der Grund für die Einführung von ScheduledThreadPoolExecutor war, den Timer zu ersetzen (wegen verschiedener Probleme mit Timer). Ich denke, Grund für die feste Anzahl von Threads an ScheduledThreadPoolExecutor übergeben ist in einem der Probleme, die diese Klasse löst. d. h.
Die Timer-Klasse startet nur einen Thread. Während es effizienter ist als einen Thread pro Aufgabe zu erstellen, ist es keine optimale Lösung. Die optimale Lösung kann eine Anzahl von Threads zwischen einem Thread für alle Aufgaben und einem Thread pro Aufgabe sein. In Effekt ist die beste Lösung, die Aufgaben in einem Pool von Threads zu platzieren. Die Anzahl der Threads im Pool sollte während der Erstellung zu zuweisbar sein, damit das Programm die optimale Anzahl der Threads im Pool ermitteln kann.
Also meiner Meinung nach ist dies, wo Use Case für SchecduledThreadPoolExecutor kommt aus. In Ihrem Fall sollten Sie in der Lage sein, den optimalen Wert zu bestimmen, abhängig von den Aufgaben, die Sie einplanen möchten, und dem Zeitpunkt, an dem diese Aufgaben erledigt werden müssen. Wenn ich 4 lange laufende Aufgaben habe, die für dieselbe Zeit geplant sind, würde ich bevorzugen, dass meine Poolgröße größer als 4 ist, wenn andere Aufgaben während derselben Zeit ausgeführt werden sollen. Ich würde es auch vorziehen, lange laufende Aufgaben in verschiedenen Ausführern zu trennen, wie in früheren Antworten angegeben.
this helps :)
Nach Java Concurrency In Practice gibt es folgende Nachteile der unbegrenzten Thread-Erzeugung:
Thema lifecyle Kopf
Thema Schöpfung und Abrüsten sind nicht frei. Die Erstellung von Threads benötigt Zeit und erfordert einige Verarbeitungsaktivitäten von JVM und Betriebssystem.
Ressourcenverbrauch
Aktive Threads verbrauchen Systemressourcen, vor allem Speicher. Wenn es mehr ausführbare Threads als verfügbare Prozessoren gibt, sitzen Threads im Leerlauf. Viele ungenutzte Threads können viel Arbeitsspeicher binden, was den Garbage Collector unter Druck setzt und viele Threads, die um die CPUs konkurrieren, können auch andere Leistungskosten verursachen. Wenn Sie genug Threads haben, um alle CPUs beschäftigt zu halten, hilft das Erstellen von mehr Threads nicht und kann sogar weh tun.
Stabilität
Es gibt eine Grenze, wie viele Threads erstellt werden. Das Limit variiert je nach Plattform und wird von Faktoren wie JVM-Aufrufparametern, der angeforderten Stapelgröße im Thread-Konstruktor und den Beschränkungen für Threads, die vom zugrunde liegenden Betriebssystem platziert werden, beeinflusst. Wenn Sie htis limit erreichen, ist das wahrscheinlichste Ergebnis ein OutOfMemoryError. Der Versuch, sich von einem solchen Fehler zu erholen, ist sehr riskant. Es ist viel einfacher, Ihr Programm so zu strukturieren, dass Sie dieses Limit nicht überschreiten.
Bis zu einem gewissen Punkt können mehrere Threads den Durchsatz verbessern, aber über diesen Punkt hinaus mehr Threads zu schaffen verlangsamt nur auf Ihre Anwendung und das Erstellen von einem Thread zu viele können Ihre gesamte Anwendung verursachen schrecklich zum Absturz bringen. Die Art und Weise, sich aus der Gefahrenzone herauszuhalten, besteht darin, die Anzahl der von Ihrer Anwendung erstellten Threads festzulegen und die Anwendung gründlich zu testen, um sicherzustellen, dass selbst wenn diese Grenze erreicht wird, die Ressourcen nicht erschöpft sind.
Unbegrenzte Thread-Erstellung scheint beim Prototyping und der Entwicklung einwandfrei zu funktionieren. Probleme treten nur auf, wenn die Anwendung bereitgestellt und unter hoher Last ausgeführt wird.