Grande números de threads

Isso normalmente depende do SO, já que o Java não tem muito overhead para tratamento de threads; as implementações normalmente mapeiam uma thread do SO para uma thread do Java (exceto aquelas implementações antigas do Java ou as que rodam em sistemas operacionais que não têm threads - nesse caso são as “green threads”).

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.

A limitação, até onde eu sei, é só do SO mesmo, agora, quanto mais Threads você tiver, pior pra ele e pro escalonador dele né.

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.

Olá

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: Quantidade de threads por processo

É 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

Na verdade, o meu problema não é tanto no thread pool ou na programação concorrente. Essa é uma área que tenho bastante experiência. E, na verdade, eu já imaginava que a limitação seria por conta do SO.

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 antes 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.

Capturei a discussão no referer do meu site (obrigado Lucas)

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

Aqui usamos threads para simulação de carga, chegamos a usar 700 threads, também com pools e reutilização. E também deram conta do recado, sem aparentemente penalizar a máquina ou comprometer o SO.