Arquivo Discussoes de Programacao e Tecnologia 
Tenho uma aplicação web rodando em Tomcat 5.5 e quero abrir uma thread nova toda vez que o site for enviar um email para fazer isso de forma assíncrona sem travar a requisição.
Posso criar uma nova thread para todo novo envio ou preciso de um ThreadPool?
Acho que no passado a JVM tinha problemas com threads que não morriam quando deveriam, então era recomendável usar um ThreadPool.
Use para isso a classe do ExecutorsService, que foi introduzida no Java 5. Você pode obter uma instância de um ExecutorService a partir da classe Executors.
Aliás, note como foi recente a preocupação para a introdução dessa classe na API do Java.
O thread pool só é realmente significativo se sua aplicação tiver uma série de tasks de curta duração. Seria esse o seu caso?
É para um site mandar email de forma assíncrona…
Se a JVM estiver matando o thread direitinho, então não tem problema… Seria como criar um objeto e confiar no GC…
Preparar e mandar um email parece ser algo esporádico e de curta duração, mas que gasta um monte de CPU para codificar o email, seguido por um tempo praticamente ocioso em que ele tem de se comunicar com o servidor de SMTP e esperar sua resposta. Acho que deve se qualificar bem para ser usado com um thread pool sim, já que a duração total ainda é relativamente curta. Entretanto, se o servidor de SMTP for muito lento, talvez você precise aumentar um pouco o tamanho da thread pool já que você vai ter um monte de threads esperando o servidor responder. Se ele for rápido, você pode ter um tamanho menor para a thread pool.
Eu imaginei que sim. Mas se o número de e-mails não for significativo, não haverá diferença prática em usar ou não o thread-pool.
Por outro lado, após o Java 5 ficou tão absurdamente fácil fazer isso, que nem sequer compensa pensar no contrário.
Eu usaria.
O thread pool só é realmente significativo se sua aplicação tiver uma série de tasks de curta duração. Seria esse o seu caso?
Preparar e mandar um email parece ser algo esporádico e de curta duração, mas que gasta um monte de CPU para codificar o email, seguido por um tempo praticamente ocioso em que ele tem de se comunicar com o servidor de SMTP e esperar sua resposta. Acho que deve se qualificar bem para ser usado com um thread pool sim, já que a duração total ainda é relativamente curta. Entretanto, se o servidor de SMTP for muito lento, talvez você precise aumentar um pouco o tamanho da thread pool já que você vai ter um monte de threads esperando o servidor responder. Se ele for rápido, você pode ter um tamanho menor para a thread pool.
Minha dúvida é porque não abrir o thread e esperar ele morrer… Eventualmente ele morrerá… ThreadPool fazia sentido quando vc tinha um monte de thread ao mesmo tempo e a JVM ficava sobre-carregada…
A idéia de você ter um thread pool com tamanho limitado é realmente não afogar seu sistema quando você tiver de (por exemplo) mandar 10000 emails para várias pessoas que estão no mesmo domínio de email - imagine 10000 emails sendo enviados por 10000 threads tentando efetuar simultaneamente 10000 conexões ao mesmo servidor SMTP.
Alguém vai ter problemas (talvez você mesmo, que conseguiu “crashar” o servidor de email de sua empresa 
e vai levar uma senhora bronca).
É melhor deixar o thread pool controlar isso por você.
Outra coisa. O thread pool também é usado quando vc deve disparar muitas threads rapidamente, mas todas de curta duração.
O intervalo entre a criação e a destruição de uma thread pode gerar um atraso indesejável. E para evitar esse atraso, recicla-se as threads.
Um exemplo clássico: Imagine as threads necessárias para fazer os tiros de uma sub-metralhadora num jogo de shooter. Sem um thread pool, você veria um atraso entre a animação do tiro e o som dele saindo.
ja fiz algo parecido usando uma fila JMS do tipo persistente, ficou joia…e performático!!!