JVM prend en charge le nombre maximum de threads simples test

Récemment, si vous souhaitez tester le nombre maximum de conmises sous OpenFire, vous devez ouvrir un grand nombre de threads pour simuler le client. J'ai toujours été perplexe quant au nombre de threads qu'une instance JVM peut ouvrir, donc je prévois de le tester et de trouver les facteurs suivants qui affectent le nombre de threads:

Le programme de test est le suivant: Code Java:

 import java.util.concurrent.atomic.atomicInteger; classe publique TestThread étend 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) essayez {thread.sleep (Integer.max_value); } catch (InterruptedException e) {break; }}}

Environnement de test: Système: Ubuntu 10.04 Kernel Linux 2.6 (32 bits)
Mémoire: 2G
JDK: 1.7

Résultats des tests:
Ø Aucune limitation du système considérée

Lorsque le nombre de threads créés atteint 31 842, aucun thread ne peut être créé dans le système.

D'après les résultats des tests ci-dessus, on peut voir que l'augmentation de la mémoire de tas (-xms, -xmx) réduira le nombre de threads qui peuvent être créés, et l'augmentation de la mémoire de pile de threads (-XSS, la valeur minimale de ce paramètre dans les systèmes 32 bits est de 60k) réduira également le nombre de threads pouvant être créés.

Ø Combiné avec les limitations du système

La limite du nombre de threads 31842 est déterminée par le nombre maximal de threads que le système peut générer: / proc / sys / kernel / threads-max, mais sa valeur par défaut est 32080. Modifier sa valeur à 10000: Echo 10000> / proc / sys / kernel / threads-max, et les résultats du test modifié sont les suivants:

Dans ce cas, cela signifie-t-il que le plus de threads possible peut être configuré? Faire une autre modification: Echo 1000000> / Proc / Sys / Kernel / Threads-Max, les résultats du test modifié sont les suivants:

Il est constaté que le nombre de threads n'augmentera plus après avoir atteint 32279. Après la vérification, le nombre maximum de PID qui peut être créé par un système Linux 32 bits est 32678. Cette valeur peut être modifiée via / Proc / Sys / Kernel / PID_MAX (la méthode de modification est la même que les threads-max), mais dans le système 32, cette valeur ne peut être changée que pour plus petite et ne peut pas être plus grande. Lorsque Threads-Max est certain, les résultats du test pour modifier PID_MAX sont les suivants:

La situation sur les fenêtres doit être similaire, mais le nombre de threads pouvant être créés sur Windows peut être plus petit que Linux. Les serveurs basés sur le modèle de thread sont toujours limités par le nombre de threads.

Le nombre maximum qui peut être généré dans JVM est affecté par la taille de la mémoire du tas du JVM, la taille de la mémoire de la pile du thread et le nombre maximal de threads que le système peut créer (l'implémentation des threads Java est basé sur le mécanisme de threads du système sous-jacent, _beinthreadEx sous Windows, et pthread_crete sous Linux). La quantité spécifique peut être estimée en fonction de la mémoire maximale auquel le processus Java peut accéder (généralement 2G sur des systèmes 32 bits), la mémoire du tas et la mémoire de pile du thread.

séquence:

Testé sur le système Linux 64 bits (CentOS6, Mémoire 3G), j'ai constaté qu'il existe un autre paramètre qui limite le nombre de threads: MaxUserProcess (peut être visualisé via Ulimita, la valeur par défaut est 1024, et cette valeur peut être modifiée via Ulimitu). Cette valeur n'est pas limitée dans l'environnement de test Ubuntu ci-dessus 32 bits.

Modifier les threads-max, pid_max, maxuserProcess, les trois paramètres à 100000, -xms, -xmx aussi petits que possible (128m, 64m) et -xss aussi petits que possible (104k à 64 bits, la valeur peut être de 128k). Prédit à l'avance dans cet environnement de test, le nombre de threads ne sera limité qu'à la taille de la mémoire (3G) de l'environnement de test. Cependant, le résultat du test réel est que lorsque le nombre de threads atteint 32k (32768, le nombre maximum de créé est d'environ 33 000), le JVM jette un avertissement: la tentative de perfectionnement local a échoué, puis une OutofMemoryError ne peut pas créer le thread local. Après avoir vérifié la mémoire, j'ai constaté qu'il y avait encore beaucoup de temps libre, donc cela ne devrait pas être dû à la capacité de mémoire. L'avertissement de Google est infructueux. Je ne sais pas pourquoi et cela a besoin de recherches supplémentaires.

Étape 2:

J'ai découvert accidentellement l'article [7] aujourd'hui et je l'ai essayé immédiatement. Effectivement, ce facteur affectera le nombre de créations de threads. Selon la description de l'article, le nombre de / proc / sys / vm / max_map_count est doublé, de 65536 à 131072. Le nombre total de threads créés a atteint 65000+. L'ordinateur doit essentiellement être coincé (mémoire 3G) ... J'ai brièvement vérifié la fonction de ce paramètre, et la description dans [8] est la suivante:

«Ce fichier contient le nombre maximum de MemoryMapaReasprocessMayhave.MemoryMapaReAsAreUseudSaside-Effect CallingMalloc, directement bymapandmprotect, et aussi lors du chargement des bibliothèques partagées.

Bien que la plupart des applications soient nécessaires moins que celles des cartes, certains programmes, en particulier les MallocDebuggers, peuvent consommer le cul, par exemple, uptoonortwomapsperallocation.

ThedefaultValueis65536. "

OK, ce problème a finalement été résolu complètement. Enfin, les facteurs affectant le nombre de threads Java sont résumés:

Java Virtual Machine lui-même: -xms, -xmx, -xss;

Limites du système:

/ proc / sys / kernel / pid_max,

/ proc / sys / kernel / thread-max,

max_user_process (ulimit-u),

/ proc / sys / vm / max_map_count.

Résumer

Ce qui précède concerne le test simple de JVM prenant en charge le nombre maximal de threads. J'espère que ce sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à d'autres sujets connexes sur ce site. S'il y a des lacunes, veuillez laisser un message pour le signaler.