JVM suporta o número máximo de threads simples teste

Recentemente, se você deseja testar o número máximo de concorrências no OpenFire, precisará abrir um grande número de threads para simular o cliente. Sempre fiquei intrigado com quantos tópicos uma instância da JVM pode abrir, então pretendo testá -lo e encontrar os seguintes fatores que afetam o número de threads:

O programa de teste é o seguinte: Código Java:

 importar java.util.concurrent.atomic.atomicinteger; classe pública testthread estende o 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.incremendget ()); while (true) tente {thread.sleep (Integer.max_value); } catch (interruptedException e) {break; }}}

Ambiente de teste: Sistema: Ubuntu 10.04 Linux Kernel 2.6 (32 bits)
Memória: 2G
JDK: 1.7

Resultados do teste:
Ø Sem limitações do sistema consideradas

Quando o número de threads criados atinge 31.842, nenhum threads pode ser criado no sistema.

A partir dos resultados do teste acima, pode-se observar que o aumento da memória da heap (-xms, -xmx) reduzirá o número de roscas que podem ser criadas e o aumento da memória da pilha de roscas (-xss, o valor mínimo desse parâmetro em sistemas de 32 bits é 60k) também reduzirá o número de roscas que podem ser criadas.

Ø Combinado com limitações do sistema

O limite do número de encadeamentos 31842 é determinado pelo número máximo de roscas que o sistema pode gerar:/proc/sys/kernel/threads-max, mas seu valor padrão é 32080. Modificar seu valor para 10000: eco 10000>/proc/sys/kernel/threads-max e os resultados modificados são como os resultados da seguinte

Nesse caso, isso significa que o maior número possível de threads pode ser configurado? Faça outra modificação: eco 1000000>/proc/sys/kernel/threads-max, os resultados dos testes modificados são os seguintes:

It is found that the number of threads will no longer increase after reaching 32279. After checking, the maximum number of pids that can be created by a 32-bit Linux system is 32678. This value can be modified through /proc/sys/kernel/pid_max (the modification method is the same as threads-max), but in the 32 system, this value can only be changed to smaller and cannot be larger. Quando threads-max é certo, os resultados dos testes para modificar o PID_MAX são os seguintes:

A situação no Windows deve ser semelhante, mas o número de threads que podem ser criados no Windows pode ser menor que o Linux. Os servidores baseados no modelo de encadeamento são sempre limitados pelo número de threads.

O número máximo que pode ser gerado na JVM é afetado pelo tamanho da memória da pilha da JVM, pelo tamanho da memória da pilha do encadeamento e pelo número máximo de roscas que o sistema pode criar (a implementação dos threads java é baseada no mecanismo de rosqueamento do sistema subjacente, _begginthex sob Windows e PTHREAD_CRETED SOBRE SOBRE Linux). A quantidade específica pode ser estimada com base na memória máxima que o processo Java pode acessar (geralmente 2G em sistemas de 32 bits), memória da heap e memória da pilha da Thread.

Sequência:

Testado no sistema Linux de 64 bits (CentOS6, Memory 3G), descobri que existe outro parâmetro que limita o número de encadeamentos: MaxUserProcess (pode ser visualizado através do ULIMITA, o valor padrão é 1024 e esse valor pode ser modificado por Ulimitu). Este valor não é limitado no ambiente de teste do Ubuntu acima de 32 bits.

Modifique os threads -max, pid_max, maxuserprocess, todos os três parâmetros a 100000, -xms, -xmx o menor possível (128m, 64m) e -xss o menor possível (104k a 64 bits, o valor pode ser 128k). Previsto com antecedência neste ambiente de teste, o número de threads será limitado apenas ao tamanho da memória (3G) do ambiente de teste. No entanto, o resultado do teste real é que, quando o número de threads atinge 32k (32768, o número máximo de criado é de cerca de 33.000), a JVM lança um aviso: TentmoAllocatEstackGuardPages falhou e, em seguida, um OrofMemoryError não pode criar o encadeamento local. Depois de verificar a memória, descobri que ainda há muito tempo livre, por isso não deve ser devido à capacidade de memória. O aviso do Google é infrutífero. Não sei por que e precisa de mais pesquisas.

Etapa 2:

Hoje descobri o artigo [7] e tentei imediatamente. Com certeza, esse fator afetará o número de criações de threads. De acordo com a descrição do artigo, o número de/proc/sys/vm/max_map_count é dobrado, de 65536 a 131072. O número total de threads criados atingiu 65000+. O computador basicamente precisa estar preso (memória 3G) ... verifiquei brevemente a função deste parâmetro, e a descrição em [8] é a seguinte:

“Este arquivo contém o número máximo de memóriaMaparasProcessMayHave.MemoryMapareaseUsedasaside-efeitos CallingMalloc, diretamente por MMAPandMProtect, também ao carregar bibliotecas compartilhadas.

Embora a maioria das aplicações seja necessária menos que a dos mapas, certos programas, particularmente Mallocdebuggers, podem consumir o ASS, por exemplo, UpTeoneortwomapsPerallocation.

ThedefaultValueIs65536. "

OK, esse problema finalmente foi resolvido completamente. Finalmente, os fatores que afetam o número de threads java estão resumidos:

Máquina virtual Java: -xms, -xmx, -xss;

Limitações do sistema:

/proc/sys/kernel/pid_max,

/proc/sys/kernel/thread-max,

max_user_process (ulimit-u),

/proc/sys/vm/max_map_count.

Resumir

O exposto acima é tudo sobre o teste simples de JVM que suporta o número máximo de threads. Espero que seja útil para todos. Amigos interessados ​​podem continuar se referindo a outros tópicos relacionados neste site. Se houver alguma falha, deixe uma mensagem para apontá -la.