Ich betreibe ein hochgradig paralleles Java-Programm.
Während viele Threads Tasks an einen Executor-Service senden, ruft der Hauptthread zu einem bestimmten Zeitpunkt ExecutorService.shutdownNow()
auf.
Nach dieser Aktion würde ich Folgendes erwarten:
Thread.currentThread().isInterrupted()
explizit überprüfen.
Da ich in einer Situation bin, wo:
ExecutorService.shutdownNow()
"heruntergefahren", aber nicht heruntergefahren, dh ExecutorService.awaitTermination(long, TimeUnit)
gibt niemals true
zurück
BlockingQueue.take()
warten.
ExecutorService.shutdownNow()
erneut aufrufe, sterben die ausstehenden Threads um InterruptedException
auf BlockingQueue.take()
Ich nehme an, dass die Unterbrechung von diesen Threads vor dem Aufruf von BlockingQueue.take()
empfangen wurde und die InterruptedException ignoriert wurde.
Ich habe mich auch gefragt, ob das ExecutorService.shutdownNow()
Thread-sicher ist, das heißt, es funktioniert auch dann richtig, wenn der Thread-Pool viele Eingaben erhält.
Alles in allem hätte ich zwei Fragen:
ExecutorService.shutdownNow()
nicht threadsicher ist? Gibt es ein alternatives Szenario, das meine Situation erklären würde?
In Ihrem Thread-Code muss etwas sein, das das unterbrochene Flag zurücksetzt oder ein InterruptedException
, das von einem anderen Methodenaufruf ausgelöst wurde, verschluckt.
Wenn das unterbrochene Flag gesetzt wird, bevor die Ausführung die Methode BlockingQueue.take()
erreicht, wirft diese Methode immer noch InterruptedException
und bricht ab. Dies wird im folgenden Code demonstriert, der sofort beendet und "Unterbrochen!" Ausgibt:
Ist es möglich, dass ExecutorService.shutdownNow () nicht threadsicher ist?
Siehe zum Beispiel: Ist ThreadPoolExecutor Thread sicher? . Laut dieser Antwort sind alle Standardimplementierungen von ExecutorService
threadsicher (auch wenn die Javadocs für dieses Thema nicht explizit sind).
Tags und Links java executorservice java.util.concurrent