Eu sempre recebo essa exceção ao tentar executar meus testes do Junit no meu mac:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at java.util.concurrent.ThreadPoolExecutor.addIfUnderMaximumPoolSize(ThreadPoolExecutor.java:727)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:657)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92)
at com.google.appengine.tools.development.ApiProxyLocalImpl$PrivilegedApiAction.run(ApiProxyLocalImpl.java:197)
at com.google.appengine.tools.development.ApiProxyLocalImpl$PrivilegedApiAction.run(ApiProxyLocalImpl.java:184)
at java.security.AccessController.doPrivileged(Native Method)
at com.google.appengine.tools.development.ApiProxyLocalImpl.doAsyncCall(ApiProxyLocalImpl.java:172)
at com.google.appengine.tools.development.ApiProxyLocalImpl.makeAsyncCall(ApiProxyLocalImpl.java:138)
O mesmo conjunto de testes de unidade passa perfeitamente bem no Ubuntu e no Windows.
Algumas informações sobre os recursos do meu sistema no mac:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 266
virtual memory (kbytes, -v) unlimited
$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07-334-10M3326)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode)
A razão pela qual eu não acho que isso é um problema de aplicação é porque os mesmos testes passam em ambientes diferentes. Eu tentei configurar heap para 1024m, 512m e definindo a pilha para 64k e 128k (e cada uma dessas combinações) sem sorte. Meus arquivos abertos eram originalmente 256 e eu colidi com isso para 1024.
Eu estive procurando um pouco e todas as postagens dizem para diminuir o tamanho do heap e aumentar o tamanho da pilha, mas isso não parece ajudar. Alguém tem mais ideias?
EDIT: Aqui estão algumas informações sobre o ambiente na minha caixa Ubuntu:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)
Pode ser o max user processes que você está atingindo. Tente aumentar isso para algo como 1024.
ulimit -u 1024
Existem limites globais para isso, então confira sysctl.conf e veja a saída de:
sysctl kern.maxprocperuid kern.maxproc
e ajuste se necessário.
Aloque mais memória para o jvm. Geralmente esta é a causa. Se você tiver 1 GB, adicione 0,5 GB ou 1. Dependendo da sua RAM, você precisará manter 1-2 GB da RAM para os processos do sistema operacional. Não aloque mais memória do que você tem.
Como disse o Mat, podem ser os problemas com muitos arquivos abertos, mas, nesse caso, você deve ver uma mensagem desse tipo. Pesquise em logs.
tamanho da pilha (kbytes, -s) 8192
Esse valor é muito grande para um grande aplicativo multithread. Se você está girando um monte de threads tente configurá-lo para 1024 com ulimit -s ou em /etc/security/limits.conf
Outra abordagem é ajustar o tamanho da pilha da JVM conforme mencionado aqui:
Prevenindo "OutOfMemory: não é possível criar um novo thread" usando o Javas -Xss non- opção padrão (consulte também docs da ferramenta )
Esta pode ser uma opção viável, sempre que não estiver em seu poder controlar / reduzir a quantidade de threads (por exemplo, quando o culpado é um lib ou framework de terceiros, você não pode abandonar)