私は、ネットワークを介して何百ものデバイスとやり取りするアプリケーションに取り組んでいます。コミットされる作業のタイプには、多くの同時スレッドが必要です (主に、それぞれがネットワークの対話を必要とし、個別に行うためですが、他の理由もあります)。現時点では、対話するデバイスごとに約 20 ～ 30 のスレッドが必要な領域にあります。
簡単に計算すると、これは数千スレッド、最大 10,000 スレッドにもなります。スレッド切り替えなどの CPU ペナルティを別にすると、CentOS 64 ビットで実行されている Java 5 はいくつのスレッドを処理できるでしょうか? これは単に RAM の問題ですか、それとも他に考慮すべきことはありますか?
ありがとう！
このような状況では、常にスレッド プーリングを使用することをお勧めします。
スレッド プールは、2 つの異なる問題に対処します。通常、タスクごとの呼び出しオーバーヘッドが削減されるため、多数の非同期タスクを実行する際のパフォーマンスが向上します。タスク。各 ThreadPoolExecutor は、完了したタスクの数など、いくつかの基本的な統計も維持します。
ThreadPoolExecutor は、使用する必要があるクラスです。
http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml
Java では最大 65k のスレッドで問題ないと思います。考慮する必要があるのはスタック領域だけです。Linux はデフォルトでスレッド/プロセスごとに 48k をスタック領域として割り当てますが、これは Java にとって無駄です (スタック割り当てオブジェクトを持たない)。 、したがって使用するスタックスペースがはるかに少なくなります)。これにより、10k スレッドで 500 MB が簡単に使用されます。
他の人が示唆しているように、NIO を使用する必要があります。多くの (ただし計画よりもはるかに少ない) スレッド (たとえば 1,000 ) を使用するアプリがあり、それはすでに非常に非効率的でした。それほど多くのスレッドを使用する必要がある場合は、間違いなく NIO の使用を検討する時期です。
ネットワークについては、アプリが HTTP を使用している場合、非常に簡単なツールの 1 つは、この分野で非常に有名な 2 人の著者による Async-HTTP-clientです。
別のプロトコルを使用する場合は、Async-HTTP-client ( netty ) の基になる実装を使用することをお勧めします。
これが本当に絶対的な要件である場合は、erlang など、このレベルの同時スレッドを処理するために特別に構築された言語を見たくないかもしれません。