クライアントマシンにいくつかのファイルを抽出するJavaプログラムがあります。ファイルを抽出するために4つのスレッドを実装しました。ただし、スレッドの実装は抽出時間にほとんど影響しません。jvisualvmでスレッドの実行を確認しましたが、見た目は問題なく、スレッドは並列に実装されていると確信しています。これが私のシステム構成です...
Windows XP、Core2duo、3GBRAM。java-vm-args：-Xmx512M-Xss2M。実行中のJVMに使用可能なプロセッサを出力しました...Runtime.getRuntime（）。availableProcessors（）= 1（間違っていない場合は、2つの論理スレッドを実行する必要があります）。
私は何かが足りないのですか？スレッドがハードウェアレベルで並列に実行されていることをどのように保証できますか？
スレッドがハードウェア レベルで並列に実行されていることをどのように保証できますか?
これはほとんど無効な質問だと思います。Linux では、スレッドとその状態を確認できますが、ps -eLfl他の OS では機能しません。スレッド ダンプには、スレッドの状態が表示されます。jconsole の [Threads] タブに移動してスレッドをクリックすると、その状態も表示されます。
ただし、スレッドの実装は抽出時間にほとんど影響しません
他の人が述べたように、これはあなたのプログラムがIOバウンドであることを示す典型的な兆候です。すべてのスレッドが同じ IO リソースをめぐって競合しており、ほとんどの時間を待機キューで費やしています。
この理論をテストするには、アプリケーションをより高速なディスク システムに移動します。SSDはここでの爆弾です。最初にファイルをメモリにロードしてから、異なる数のスレッドで処理を実行すると、IO 帯域幅の問題も切り分けられます。メモリファイルシステムを使用することも同様です。
プロセスが IO バウンドの場合、IO 帯域幅を増やさずにプロセスを高速化する方法がない可能性があります。
見逃しているのは、抽出時間が CPU 時間だけでなく、HDD の読み取りと書き込みでも構成されていることです。これら 2 つは、CPU によって実行される ZIP アルゴリズムよりも数桁多く時間がかかります。
並列実行は、CPU がボトルネックになっている場合に役立ちます。あなたの場合、ボトルネックはおそらくCPUではなくI / Oです。また、ハイパースレッディングを備えた物理コアが 1 つあります。この場合、CPU がボトルネックであっても、並列実行はおそらく役に立ちません。さらに、場合によっては、シングルコアのハイパースレッディング CPU では、シングルスレッド アプリケーションよりも 2 スレッド アプリケーションの方が遅くなることがあります。ハイパースレッディングは主にマーケティングのトリックです。それに依存しないでください。
外部の手段以外でそれを確認する方法はないと思います。例えば
実行中の JVM に使用可能なプロセッサを出力しました。
Runtime.getRuntime().availableProcessors() = 1
つまり、JVM は、使用できるプロセッサが 1 つしかないと考えていることを意味します。実際に 2 つの物理コア (または HT 仮想コア) がある場合、オペレーティング システムは JVM にそのうちの 1 つだけを使用させます。
(コード内の何らかのボトルネックでは、availableProcessors()が返されることはありません1。)
スレッドがハードウェア レベルで並列に実行されていることをどのように保証できますか?
オペレーティング システムで JVM が複数のコアを使用できるようにする必要があります。