2016-05-28 13 views
-1

Ich verstehe, warum Thread-Pool-Größen an die Anzahl der CPU-Kerne gebunden sind, aber warum haben die Designer von ForkJoinThread standardmäßig # of cpu cores - 1 Threads verwendet? Warum die -1?Warum versucht der allgemeine ForkJoinPool nicht, alle Kerne zu verwenden?

Wenn ich den Aufbau meiner eigenen ForkJoinPool (nicht die gemeinsame Instanz verwendet wird), und die main Gewinde auf der Pool gesperrt wartet es einige Ergebnis zurückkehren, gibt es keinen Grund möchte ich würde weniger zuzuteilen als Runtime.getRuntime().availableProcessors() Fäden?

UPDATE: Bitte erläutern Sie, warum Sie abstimmen. Ansonsten kann ich die Frage nicht verbessern.

+0

Die JVM reserviert normalerweise eine bestimmte Anzahl von Cores für die Garbage Collection. Es hängt stark von der Architektur ab, auf der Sie arbeiten und welche GC-Implementierung gewählt wurde. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/toc.html –

+0

@AndrewRueckert Anstatt mit einem Kommentar zu downvotieren, warum nicht posten dies als eine Antwort? Es ist eine vernünftige Erklärung. – Gili

+0

Ich habe Sie nicht abgelehnt, aber ich dachte nicht, dass meine Antwort solide genug wäre, um als "Antwort" zu gelten. Stellt sich heraus, ich habe mich sowieso geirrt! :/ –

Antwort

1

Es gibt einen Kommentar in der Oracle JDK implementation. Darin heißt es

* When external threads submit to the common pool, they can 
* perform subtask processing (see externalHelpComplete and 
* related methods) upon joins. This caller-helps policy makes it 
* sensible to set common pool parallelism level to one (or more) 
* less than the total number of available cores, or even zero for 
* pure caller-runs. 

Mit anderen Worten, wenn eine externe (nicht Teil der FJP Threads) (können) helfen bei der Durchführung von Aufgaben, zusätzliche Threads sind nicht immer von Vorteil.

+0

Gut finden. Vielen Dank! – Gili