ThreadPoolExecutor mit erzwingender Warteschlange

Question

Der traditionelle ThreadPoolExecutor verwendet eine gelieferte BlockingQueue, um Elemente nur dann in die Warteschlange zu stellen, wenn für die eingehenden Aufgaben keine leeren Kernthreads verfügbar sind. Wenn es leere Kern-Threads gibt, versucht der Executor, die Threads den eingehenden Aufgaben direkt zuzuweisen.

Ich möchte ein etwas anderes Verhalten. Ich möchte, dass alle Aufgaben an die BlockingQueue und den Executor-Service übergeben werden, um nur Aufgaben aus der Warteschlange abzufragen.

Ich habe meine eigene Implementierung der BlockingQueue, die Elemente in Poll() basierend auf einer Überprüfung liefern (überprüfen Sie die Geschäftslogik für die Verarbeitung der Aufgaben), wenn die Prüfung fehlschlägt werden die Elemente nicht in der Umfrage (). Ich glaube, ThreadPoolExecutor ist bereits mit der Annahme implementiert, dass poll(), das null zurückgibt, nicht unbedingt bedeutet, dass die Warteschlange leer ist.

Mir ist ein Problem mit diesem Modell bekannt. Die Kern-Threads im traditionellen ThreadPoolExecutor werden nur erstellt, wenn Tasks über die execute() -Methode an den Executor übergeben werden. Wenn ich die Methode execute() überschreibe, um Aufgaben direkt in die BlockingQueue einzuordnen, werden die Kernthreads möglicherweise nicht erstellt. Ich kann dieses Problem umgehen, indem ich die Core-Threads vorstelle und sie nicht auf Timeout setze, damit die Kern-Threads immer am Leben sind. Ich muss auch überprüfen, dass die Anzahl der Kern Threads nicht mit 0 konfiguriert ist.

Wird dieses Modell funktionieren? Fehle ich, um mit einem Fall umzugehen? Ihre Gedanken.

Answer 1

Wenn ich Sie richtig verstanden habe, werden Sie Aufgaben an einige ThreadPool übergeben, aber Sie wollen wählen, ob Sie diese Aufgaben wirklich in Abhängigkeit von einer Logik verarbeiten werden? In diesem Fall:

1. Warum überprüfen Sie nicht, ob die Aufgabe für die Verarbeitung geeignet ist, bevor Sie sie an den Executor senden?
2. Sie können immer die Überprüfung innerhalb der Aufgabe als erste Anweisungen - wenn Prüfung fehlschlagen dann nur return von der Aufgabe - dies wird Ihnen Multithreading für die Prüflogik.
3. Ich sehe keinen Grund, darauf zu bestehen, es auf die harte und unordentliche Weise mit dem Überschreiben des Executor, BlockingQueue, Vorinstantiierung von Threads und möglicherweise anderen Hacks zu tun.
4. Es ist nicht die Verantwortung von ThreadPoolExecutor zu entscheiden, ob eine übermittelte Aufgabe ausgeführt werden soll oder nicht - es liegt in der Verantwortung des Task-Übermittlers, oder die Aufgabe selbst könnte solche Logik enthalten, um früh ohne viel Verarbeitung zu beenden.