JVM admite el número máximo de hilos prueba simple

Recientemente, si desea probar el número máximo de concurrencias bajo OpenFire, debe abrir una gran cantidad de hilos para simular el cliente. Siempre me han desconcertado cuántos hilos puede abrir una instancia de JVM, por lo que planeo probarlo y encontrar los siguientes factores que afectan el número de hilos:

El programa de prueba es el siguiente: Código Java:

 import java.util.concurrent.atomic.atomicinteger; Public Class TestThread extiende el hilo {private static final AtomicInteger Count = new AtomicInteger (); public static void main (string [] args) {while (true) (nuevo testThread ()). start (); } @Override public void run () {system.out.println (count.incrementandget ()); while (true) intente {thread.sleep (integer.max_value); } capt (interruptedException e) {break; }}}

Entorno de prueba: Sistema: Ubuntu 10.04 Linux Kernel 2.6 (32 bits)
Memoria: 2G
JDK: 1.7

Resultados de la prueba:
Ø No se consideran limitaciones del sistema

Cuando el número de subprocesos creados alcanza 31,842, no se pueden crear hilos en el sistema.

De los resultados de la prueba anterior, se puede ver que el aumento de la memoria de montón (-xms, -xmx) reducirá el número de subprocesos que se pueden crear, y el aumento de la memoria de pila de subprocesos (-xss, el valor mínimo de este parámetro en sistemas de 32 bits es de 60k) también reducirá el número de subprocesos que se pueden crear.

Ø Combinado con limitaciones del sistema

El límite del número de subprocesos 31842 está determinado por el número máximo de subprocesos que el sistema puede generar:/proc/sys/kernel/threads-max, pero su valor predeterminado es 32080. Modifica su valor a 10000: echo 10000>/proc/sys/kernel/hilts-max, y los resultados de la prueba modificados son los que siguen::

En este caso, ¿significa que se pueden configurar tantos hilos como sea posible? Haga otra modificación: Echo 1000000>/Proc/Sys/Kernel/Threads-Max, los resultados de la prueba modificados son los siguientes:

Se encuentra que el número de subprocesos ya no aumentará después de alcanzar el 32279. Después de verificar, el número máximo de PID que pueden ser creados por un sistema Linux de 32 bits es 32678. Este valor puede modificarse a través de/proc/sys/kernel/pid_max (el método de modificación es el mismo que los hilos-max) pero en el sistema 32, este valor puede cambiar a más pequeño y solo puede ser más pequeño. Cuando Threads-Max es seguro, los resultados de la prueba para modificar PID_max son los siguientes:

La situación en Windows debe ser similar, pero el número de hilos que se pueden crear en Windows puede ser menor que Linux. Los servidores basados ​​en el modelo de subprocesos siempre están limitados por el número de hilos.

El número máximo que se puede generar en JVM se ve afectado por el tamaño de la memoria del montón del JVM, el tamaño de la memoria de la pila de subprocesos y el número máximo de subprocesos que el sistema puede crear (la implementación de los subprocesos Java se basa en el mecanismo de roscado del sistema subyacente, _beginthreadx bajo Windows y PThread_create bajo Linux). La cantidad específica se puede estimar en función de la memoria máxima al que el proceso Java puede acceder (generalmente 2G en sistemas de 32 bits), memoria de montón y memoria de pila de subprocesos.

secuencia:

Probado en el sistema Linux de 64 bits (memoria CentOS6, 3G), descubrí que hay otro parámetro que limita el número de subprocesos: MaxuserProcess (se puede ver a través de Ulimita, el valor predeterminado es 1024, y este valor se puede modificar a través de Ulimitu). Este valor no se limita en el entorno de prueba Ubuntu de 32 bits anterior.

Modifique Threads -Max, PID_MAX, MaxuserProcess, los tres parámetros a 100000, -xms, -xmx lo más pequeño posible (128m, 64m) y -xs lo más pequeño posible (104k a 64 bits, el valor puede ser de 128k). Predicho de antemano en este entorno de prueba, el número de subprocesos solo se limitará al tamaño de la memoria (3G) del entorno de prueba. Sin embargo, el resultado real de la prueba es que cuando el número de subprocesos alcanza 32k (32768, el número máximo de creado es de aproximadamente 33,000), el JVM lanza una advertencia: el intento de laspagas de UptAtestActack falló, y luego un OutOfMemoryError no puede crear el hilo local. Después de verificar la memoria, descubrí que todavía hay mucho tiempo libre, por lo que no debería deberse a la capacidad de memoria. La advertencia de Google es infructuosa. No sé por qué y necesita más investigación.

Paso 2:

Accidentalmente descubrí el artículo [7] hoy y lo probé de inmediato. Efectivamente, este factor afectará el número de creaciones de hilos. Según la descripción del artículo, el número de/proc/sys/vm/max_map_count se duplica, de 65536 a 131072. El número total de subprocesos creados ha alcanzado 65000+. Básicamente, la computadora tiene que estar atascada (memoria 3G) ... revisé brevemente la función de este parámetro, y la descripción en [8] es la siguiente:

“Este archivo contiene el número máximo de memoriaMapareAsprocessmayhave.MemoryMapareAseusedAsaside-Effect-EffectMalloc, directamente por mMAPandMProtect, y también al cargar bibliotecas compartidas.

Si bien la mayoría de las aplicaciones son necesarias menos que las de los mapas, ciertos programas, particularmente malcdebuggings, pueden consumir el culo, por ejemplo, UpTooneortWomapSperallation.

ThedefaultValueis65536 ".

Ok, este problema finalmente se ha resuelto por completo. Finalmente, se resumen los factores que afectan el número de hilos de Java:

Java Virtual Machine en sí: -xms, -xmx, -xss;

Limitaciones del sistema:

/proc/sys/kernel/pid_max,

/proc/sys/kernel/hilo-max,

max_user_process (ulimit-u),

/proc/sys/vm/max_map_count.

Resumir

Lo anterior se trata de la prueba simple de JVM que admite el número máximo de subprocesos. Espero que sea útil para todos. Los amigos interesados ​​pueden continuar referiéndose a otros temas relacionados en este sitio. Si hay alguna deficiencia, deje un mensaje para señalarlo.