Solaris/Linux でのスレッド化について説明しているさまざまなドキュメントがありますが、現在は Windows の実装について説明しています。私はこれに興味を持っています。これほど重要なことが (一見) 文書化されていないのは奇妙に思えます。
スレッド化は異なる OS で同じではありません' - 「Write Once, Run Anywhere」はスレッド化には当てはまりません。
http://java.sun.com/docs/hotspot/threads/threads.htmlを参照してください。
あなたの質問に最も直接的に答えるために、スレッドの実装方法に関する正確なセマンティクスは、JVM 仕様では意図的に定義されていません。
FWIW、「Java の公開されたスレッド モデルはすべてのプラットフォームで同じであり、Java 仕様で定義されています。Java アプリケーションにとって、基盤となる OS はスレッドに対しても完全に透過的である必要があります」という Sebastion の声明は不正確です。
待機/通知を使用したスレッド スタベーションに関して、Windows と Linux でのスレッド化の間に経験的に大きな違いがあることを発見しました。多くのスレッドが単一のロックをめぐって競合する場合、Linux は著しく枯渇しやすくなります。Windows では Linux よりも3桁も多くのスレッドをロードして、枯渇を引き起こす必要がありました。ロックの競合が激しい場合は、フェア修飾子を使用した Java 同時実行ロックが重要になります。
数値を説明すると、Linux では 1 つのロックが 31 のスレッドによって激しく競合するという問題がありました。Windows では、同じコードが 10,000 (そうです、10,000 です) のスレッドを必要とし、飢餓の問題を示し始めました。
さらに悪いことに、Linux には 3 つの異なるスレッド モデルがあり、それぞれに異なる特性があります。
ほとんどの場合、私の経験ではスレッド化は透過的でしたが、競合の問題については慎重に検討する必要があります。
It really depends on the specific JVM implementation. I assume you're wondering about Sun's Windows JVM, and I can tell you with certainty that the Sun JVM maps a Java thread to an OS thread.
You could try spawning up a couple of threads from Java code, open up Task Manager and see what happened.
問題のドキュメントでは、Solaris スレッド モデルと、VM がそれにどのようにマップされるかについて説明しています。これは Linux とは関係ありません。また、このドキュメントではパフォーマンスのみについて説明しています。何を選択しても、プログラムの全体的な動作は変わらないはずです。
Java の公開スレッド モデルはすべてのプラットフォームで同じであり、Java 仕様で定義されています。Java アプリケーションにとって、基盤となる OS は、スレッドに対しても完全に透過的でなければなりません。
ただし、知っておく必要がある場合は... Sun JVM は、そのスレッドを 1:1 で Windows スレッドにマップします。複数のプロセスやファイバーを使用しません。
そのドキュメントは、Java スレッド モデルよりも、Solaris スレッドに関するものです。すべての JVM は、作成対象の OS のネイティブ スレッド API を呼び出すため、OS スレッドには常に 1 つの Java スレッドが存在します。ドキュメントの図は、スレッドが変更されるのは OS 空間に入るまでではないことを示しています。各 OS は、Windows 固有のドキュメントのさまざまな方法でスレッドを処理できます。ここから始めるのが適切です: MSDN About Processes and Threads。
長い間、*nix のさまざまなフレーバーは、実際のスレッドではなくプロセスを使用してスレッドを実装してきました。Solaris の新しいスレッド モデルへの移行を容易にする特定のチューニング パラメータがあるようです。これにより、古いモデルとそれらの JVM オプションが廃止されました。
HotSpot JVM の JVM オプションのリストについては、HotSpot VM Optionsを参照してください。これらの多くは、長時間実行されるアプリケーションの調整に役立ちますが、それらが何をしているのか理解していないと、問題が発生する可能性もあります。また、JVM の各実装には、IBM の VM や BEA では見られないさまざまなオプション セットがあることにも注意してください。