Einstellbarer Threadpool und Warteschlange

Question

Ich plane, einen einstellbaren Thread-Pool mit einstellbarer Warteschlangengröße zu erstellen. Ich verwende unbegrenzte LinkedBlockingQueue mit einer externen Einstellung, die steuert, wie viele Nachrichten in die Warteschlange gestellt werden. Anfangs sind meine Kerngröße und die maximale Größe gleich. Wenn ich meine Threadpoolgröße zur Laufzeit aktualisieren möchte, setze ich Corespoolsize und Maxpoolsize über eine gemeinsame Einstellung auf einen anderen Wert. Ich würde gerne wissen, was Sie von diesem Ansatz halten.

Wenn maxpoolsize auf Integer.MAX_VALUE gesetzt ist, kann ich Corespoolize einfach anpassen, da meine Warteschlange unbegrenzt ist?

Ist es eine bessere Idee, SynchroneQueue mit CallerRunsPolicy anstelle von LinkedBlockingQueue mit externer Steuerung zu verwenden?

WICHTIG: Ich möchte auch wissen, was passiert, wenn ich meine Corethreadpoolgröße reduziere, werden die laufenden Aufgaben in der Mitte abgebrochen?

Answer 1

Ich habe ein paar Fragen. Aus welchem ​​Grund suchen Sie nach SynchronousQueue? SynchronousQueue kommt nicht mit irgendeiner Eigenschaft, selbst 1. Nach Dokumentation hier - how to modify ThreadPoolTaskExecutor at runtime through jmx

Eine blockierende Warteschlange, in der jeder Einfügevorgang für eine entsprechende Entfernungsoperation von einem anderen Thread warten muß, und vice versa. Eine synchrone Warteschlange hat keine interne Kapazität, nicht einmal eine Kapazität von eins.

Also meiner Meinung nach sollten wir es nicht verwenden, es sei denn, unser uscase würde uns dazu bringen, dasselbe zu verwenden. Ich werde also keine Kommentare abgeben können, wenn wir keine genaue Vorstellung von Ihrem Anwendungsfall haben.

Über den Threadpool, wie Sie erwähnt haben, führt CachedThreadPool genau die Funktionalität aus, die Sie benötigen, mit Ausnahme der Core-Poolgröße, daher sollten Sie das gleiche evaluieren. Durch das Reduzieren der Corepoolgröße werden laufende Threads nicht gestoppt, es sei denn, die zugrunde liegende Task ist beendet. Also brauchen Sie sich nicht um dasselbe Sorgen zu machen. how to modify ThreadPoolTaskExecutor at runtime through jmx