http://www.guj.com.br/posts/list/5.java JForum - http://www.jforum.net
Enfim, o que é um "grande número de threads"? 5, 50, 500, 5000?

Existe alguma maneira de calcular isso, ou só a base do profiling mesmo?

O java tem alguma limitação nesse sentido, ou é limitado apenas pelo SO?]]> http://www.guj.com.br/posts/preList/62273/326906.java http://www.guj.com.br/posts/preList/62273/326906.java GMT
Uma das coisas que você pode fazer para controlar o espaço de memória usado por cada thread é a opção -Xss; essa opção (que tem a mesma sintaxe da -Xms e -Xmx que se usam para controlar a quantidade de memória do heap do Java) controla quanto "stack" nativo cada thread vai ter disponível.

]]> http://www.guj.com.br/posts/preList/62273/326913.java http://www.guj.com.br/posts/preList/62273/326913.java GMT
Sobre a quantidade, depende MUITO de onde você estiver rodando, da quantidade de processadores, da versão do SO e até mesmo da JVM que você estiver utilizando. Programação concorrente é uma coisa que agente tem sempre que ter MUITO cuidado.]]> http://www.guj.com.br/posts/preList/62273/326915.java http://www.guj.com.br/posts/preList/62273/326915.java GMT
Acho que é limitado pela memória.

O uso de ThreadPool precisa de algum cuidado e uma boa googlada pode ajudar no raciocínio.

Uma boa fonte é acompanhar os posts do Claudio Miranda que volta e meia aborda temas semelhantes. Um deles é este: [url=http://www.claudius.com.br/blog/claudio/2007/06/05/Quantidade-de-threads-por-processo]Quantidade de threads por processo[/url]

É bom usar porque é o melhor meio de saber as vantagens.

No java 7 virão algumas coisas novas e todo um framework baseado em conceitos diferentes de todo o modo como a gente trabalha com Threads em Java. Será útil em algumas circunstâncias mas não em todas.

[]s
Luca]]> http://www.guj.com.br/posts/preList/62273/326916.java http://www.guj.com.br/posts/preList/62273/326916.java GMT
Mas, falar em "número grande" é um termo empírico. Se não há maneiras de se estimar o que é grande a antemão, fica realmente difícil projetar com antecedência.

E também é meio óbvio que isso variará de máquina para máquina. Mas as vezes a gente precisa de um balisador, uma regra geral, mesmo que isso não atenda a todos os casos. Ou então, precisamos de um meio mais ou menos confiável de pelo menos estimar isso. Afinal, infelizmente, nosso chefe quer saber de antemão se o sistema é possível, antes de investir nele.

Por exemplo, devo me preocupar se eu tiver mais de 100 threads? Ou mais de 1000? O parque de máquinas aqui da Siemens é enorme. Mas pelo menos já saímos da era do Pentium 2. Acho que posso dizer com relativa segurança que todos temos pelo menos 128mb de ram.

É uma aplicação para cliente final, não uma aplicação que rodará num servidor.

E a concorrência entre as threads nesse caso também não é um grande problema. As threads não interagem entre si. O objetivo delas é executar carga em centrais telefônicas. Cada uma tem seu próprio grupo de objetos e roda uma instância separada do script. Agora, para isso, o computador não pode se sobrecarregar [i]antes[/i] da central...

Em todo caso, já estou construindo um protótipo aqui, para fazer os devidos profilings com scripts reais. E se achar alguma maneira matemática ou menos dependente de "feeling" de estimar isso, posto por aqui. ]]> http://www.guj.com.br/posts/preList/62273/327246.java http://www.guj.com.br/posts/preList/62273/327246.java GMT
Um número grande de threads varia na quantidade de clientes e conexões em sistemas para integração.

Em algumas medições que fiz, com uma base de cerca de 3000 conexões clientes em um sistema intranet, aplicação web, cerca de 350 threads davam conta do recado.

Por que só isso ?

O pool de threads reutiliza várias threads no ciclo de vida da aplicação
Quando são threads de serviços (conexões, EJB, servlets, acceptor), todas são reutilizadas.
Cada usuário não está intensamente usando o sistema, clicando, requisitando e consultando informações.

Isso muda quando a aplicação cria e gerencia threads, o que pode impactar (negativamente) muito o consumo de recursos.

Claudio Miranda]]> http://www.guj.com.br/posts/preList/62273/542926.java http://www.guj.com.br/posts/preList/62273/542926.java GMT http://www.guj.com.br/posts/preList/62273/542956.java http://www.guj.com.br/posts/preList/62273/542956.java GMT