なぜグリーンスレッドではないのですか？

私はこれに関する質問がすでにカバーされていることを知っていますが（例えばhttps://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads）、満足のいく答えが得られたとは感じません。

問題は、なぜJVMがグリーンスレッドをサポートしないのかということです。

コードスタイルのJava FAQでこれを言っています：

緑のスレッドは、すべてのコードが単一のオペレーティングシステムスレッドで実行されるJava仮想マシン（JVM）の動作モードを指します。

そして、これはjava.sun.com上で：

欠点は、グリーンスレッドを使用すると、Linuxのシステムスレッドが利用されないため、CPUを追加してもJava仮想マシンがスケーラブルではないことです。

JVMには、コアの数に等しいシステムプロセスのプールがあり、その上でグリーンスレッドを実行できるように思えます。頻繁にブロックする非常に多くのスレッドがある場合、これはいくつかの大きな利点を提供します（主に現在のJVMがスレッド数を制限するため）。

考え？

JVMがグリーンスレッドを放棄し、ネイティブスレッドに移行したことを覚えています。これは2つの単純な理由によるものです。グリーンスレッドは率直に言ってごみであり、Sunで利用できる開発者の努力は限られていますが、マルチコアプロセッサをサポートする必要がありました。

これは残念なことでした-緑のスレッドはより優れた抽象化を提供し、並行性を障害物ではなく有用なツールにすることができます。しかし、いくつかのハードルを克服できない場合、緑色のスレッドは役に立ちません。

• 利用可能なすべてのCPUコアを使用する必要があります

• コンテキスト切り替えは安価でなければなりません

• I / Oは、いずれかのスレッドがそれに従事しますが、ブロックすることがありませんいくつかの初期の実装ではそうであった他のすべてのスレッドを、他のスレッドが確かではありません。

Javaでマルチスレッド化がなぜ難しいのかとよく疑問に思っていましたが、今では明らかになっています。最終的にはネイティブスレッドへの切り替えに関係していました。

• すべてのCPUコアの使用が得意

• 独立したI / Oなどを提供する、真の並行性が得意

• コンテキストの切り替えが遅い（最適なグリーンスレッドの実装と比較して）

• 恐ろしくメモリに貪欲であるため、それらの最大使用可能数を制限します

• 現実の世界を表現するためのあらゆる基盤に対する貧弱な抽象化であり、もちろん非常に同時的です。

最近では、プログラマーの多くの時間は、ノンブロッキングI / Oや先物などのコーディングに費やされています。これは、より優れた抽象化レベルを持たない大きな恥です。

比較のために、Erlangのほかに、新しいGo言語は非常に大きな並行性を発揮します。それらの祖父はすべてOccamのままであり、まだ進行中の研究プロジェクトです。

複数のスレッドを偽装する単一のプロセスには、多くの問題があります。その1つは、偽のスレッドがすべてページフォールトで停止することです。

提案するプロセスプールの選択肢には、いくつかの利点と欠点があります。最大の利点である「スレッド」の分離は、実際にはここではあまり得られません。大きな不利な点、実装の極端な難しさと同期の効率の悪さは、ここでの取り決めです。

ただし、スレッドのプールのように使用できるプロセスのプール（Java以外）が存在する（ただし、より分離されている）アプリケーションが存在するのは素晴らしいことです。スレッドはほとんどすべてを共有します。プロセスを使用すると、共有するものを具体的に選択できます。私の知る限り、誰もまだそれを実装する努力をしていません。

平均的なJavaコードにはまったくメリットはありません。JavaはErlangではなく、JavaプログラマーはErlangプログラマーと同じ考え方ではありません。この言語をこのように使用することは意図されていませんでした。

真の軽量プロセスが必要な場合-Erlangを使用して、メッセージを介して通信する数千のスレッドを作成します。Javaでは、ミューテックスとセマフォと共通のメモリを共有する多数のスレッドがあります。これは、さまざまな問題に対応するために設計された単なるプログラミングモデルです。