JVMは、スレッドの最大数の簡単なテストをサポートしています

最近、OpenFireの下で最大同時数をテストする場合は、クライアントをシミュレートするために多数のスレッドを開く必要があります。 JVMインスタンスが開くことができるスレッドの数については常に困惑しているので、テストして、スレッドの数に影響する次の要因を見つける予定です。

テストプログラムは次のとおりです。Javaコード：

 java.util.concurrent.atomic.atomicintegerをインポートします。 public class testthread extends thread {private static final atomicinteger count = new AtomicInteger（）; public static void main（string [] args）{while（true）（new testthread（））。start（）; } @Override public void run（）{system.out.println（count.incrementAndget（））; while（true）try {thread.sleep（integer.max_value）; } catch（arternedexception e）{break; }}}

テスト環境：システム：ubuntu 10.04 Linuxカーネル2.6（32ビット）
メモリ：2g
JDK：1.7

テスト結果：
Øシステムの制限は考慮されていません

作成されたスレッドの数が31,842に達すると、システムにスレッドを作成できません。

上記のテスト結果から、ヒープメモリ（-XMS、-XMX）を増やすと、作成できるスレッドの数が減り、スレッドスタックメモリ（-XSS、32ビットシステムのこのパラメーターの最小値が60K）の増加が増加することがわかります。

Øシステムの制限と組み合わせた

スレッド数３１８４２の数の制限は、システムが生成できるスレッドの最大数で決定されます：/croc/sys/kernel/swreps-maxですが、そのデフォルト値は32080になります。

この場合、できるだけ多くのスレッドを構成できることを意味しますか？別の変更を加える：Echo 1000000>/Proc/Sys/Kernel/Threads-Max、修正されたテスト結果は次のとおりです。

32279に達した後、スレッドの数はもはや増加しません。チェック後、32ビットLinuxシステムによって作成できるPIDの最大数は32678です。 Threads-Maxが確実な場合、PID_MAXを変更するためのテスト結果は次のとおりです。

Windowsの状況は似ているはずですが、Windowsで作成できるスレッドの数はLinuxよりも小さい場合があります。スレッドモデルに基づくサーバーは、常にスレッドの数によって制限されます。

JVMで生成できる最大数は、JVMのヒープメモリサイズ、スレッドのスタックメモリサイズ、およびシステムが作成できるスレッドの最大数の影響を受けます（Javaスレッドの実装は、基礎となるシステムのスレッドメカニズム、_beginthreadexの下の_beginthreadexに基づいています）。特定の量は、Javaプロセスがアクセスできる最大メモリ（通常、32ビットシステムで2G）、ヒープメモリ、およびスレッドのスタックメモリに基づいて推定できます。

順序：

64ビットLinuxシステム（CENTOS6、3Gメモリ）でテストされた、スレッドの数を制限する別のパラメーターがあることがわかりました：maxuserprocess（ulimitaを介して表示でき、デフォルト値は1024、この値はulimituを通じて変更できます）。この値は、上記の32ビットUbuntuテスト環境では限定されません。

Threads -Max、PID_MAX、MAXUSERProcess、3つのパラメーターすべて、100000、-XMS、-XMXはできるだけ小さい（128m、64m）、および-xssを可能な限り小さい（64ビットで104k）、値は128Kになります）。このテスト環境で事前に予測されると、スレッドの数は、テスト環境のメモリサイズ（3G）にのみ制限されます。ただし、実際のテスト結果は、スレッドの数が32Kに達すると（32768に達すると、作成の最大数は約33,000）、JVMは警告を投げます。メモリをチェックした後、私はまだ多くの自由時間があることを発見したので、それはメモリ容量が原因ではないはずです。 Googleの警告は実りがありません。理由はわかりませんが、さらなる研究が必要です。

ステップ2：

私は今日誤って記事[7]を発見し、すぐに試しました。案の定、この要因はスレッド作成の数に影響します。記事の説明によると、/proc/sys/vm/max_map_countの数は65536から131072に2倍になります。作成されたスレッドの総数は65000+に達しました。コンピューターは基本的に立ち往生する必要があります（3Gメモリ）...このパラメーターの機能を簡単に確認しましたが、[8]の説明は次のとおりです。

「このファイルには、MemoryMapareasProcessMayhave.MemoryMapareAsaReasasaside-Effect CallingMallocの最大数が含まれています。

ほとんどのアプリケーションはマップのアプリケーションよりも少ないですが、特定のプログラム、特にMallocdebuggersは、尻を消費する場合があります。

thedefaultValueis65536。」

OK、この問題はついに完全に解決されました。最後に、Javaスレッドの数に影響する要因が要約されています。

Java仮想マシン自体：-xms、-xmx、-xss;

システムの制限：

/proc/sys/kernel/pid_max、

/proc/sys/kernel/thread-max、

max_user_process（ulimit-u）、

/proc/sys/vm/max_map_count。

要約します

上記は、スレッドの最大数をサポートするJVMの簡単なテストに関するすべてです。私はそれが誰にでも役立つことを願っています。興味のある友人は、このサイトの他の関連トピックを引き続き参照できます。欠点がある場合は、それを指摘するためにメッセージを残してください。