Arquivo Discussoes de Programacao e Tecnologia 
Olá !
Estou com uma dúvida sobre thread, por exemplo eu criou um aplicativo que a cada acesso a ele cria uma thread, e fica imprindo dados na tela, quando é finalizado sei lá como por exemplo fechada a janela ele gera uma expception pois não consegue mais imprimir na tela, oque acontece com essa thread ela morre e libera a memória ? ou fica rodando ? se fica rodando como se faz pra matá-la e liberar a memória ?
Qualquer comentário já ajuda a me tirar essa dúvida valeu !
[]s
Se você termina o programa, todas as threads que ele criou também terminam.
Concordo que seu eu fechar o aplicativo ele vai matar tudo mas no caso de ser um servlet (eu coloquei “aplicativo” ali em cima foi mals) ele fica persistente na memoria, e isso pelo jeito faz com que as threads mesmo teoricamente finalizadas fiquem ativas, e isso pode começar a gerar lentidão no acesso e etc correto ?
[]s
Marcio,
não entendi muito bem o que você quis dizer em relação a Servlets e Threads.
Mas já tive uma experiência (negativa) e posso te alertar:
Se você cria uma thread dentro da Servlet, ela (a thread) é independente da Servlet. Isso quer dizer que se você der um STOP na Servlet, a thread vai continuar rodando.
Ou pior ainda: se você fizer um restart na Servlet, além da Thread antiga continuar rodando, dependendo de como você programou a criação da Thread, uma nova será criada e aí a cada restart da Servlet você terá Thread + 1! 
Cuidado!
[]'s
Marco Campêlo
E como eu posso “obrigar” a matar essa thread para que esse tipo de problema não ocorra ou seja, sobrecarga, lentidão no servidor?
E uma dúvida mesmo ocorrendo uma exception a thread continua rodando e alocada na memória ?
[]s
E como eu posso “obrigar” a matar essa thread para que esse tipo de problema não ocorra ou seja, sobrecarga, lentidão no servidor?
[]s
http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/Servlet.html#destroy()
Você pode matar a Thread quando o destroy da Servlet for chamado.
[]'s
Marco Campêlo
Mas o destory só será chamado quando o servlet for realmente finalizado (reinico do servidor ou desligamento) e nesse caso eu irei continuar com o mesmo problema pois duarante o funcionamento sa aplicação, as threads ficaram persistentes e afetando o desempenho do servidor, correto ?
Ou estou viajando ?
[]s
Entendo que o destroy será chamado quando você der um stop na sua WebApplication.
BTW, por que você precisa de Threads na Servlet? 
[]'s
Marco Campêlo
É só um estudo que estou fazendo de deixar um “aplicativo” no caso um servlet eterno ou seja que ele fique mandando msg pra tela, enquanto estiver vivo, com a utilização de syncronizes, wait() e notify() e tambem consigo o mesmo digamos processo, mas o problema fica na mesma, que é mesmo finalizando o servlet sobre restos de thread, e não consegui achar nenhum meio de fazer uma “limpeza” geral.
Se alguem tiver alguma dica, por favor coloque aqui!
Finalizando a Servlet sobra restos da Thread?
Por que?
O que eu disse é que você precisa implementar o método destroy () na Servlet e dentro dele fazer o trabalho de matar a Thread.
Simples assim!
[]'s
Marco Campêlo
Usar thread em servelet não é uma boa forma de programação e sim usar um pool , e é bom evitar mulplas treads com aplicativos web.
Concordo contigo que startar uma Thread dentro de uma Servlet pode ser algo (muito) nocivo se você não souber MUITO bem o que está fazendo.
Mas não entendi como um pool (pool de que?) poderia substituir uma Thread.
[]'s
Marco Campêlo
Vou junto com o Saulo!
Não é aconselhável utilizar threads dentro de webcontainer, já que é o container quem se responsabiliza pelo gerenciamento das threads, que seriam as próprias servlets que atendem as requisições dos usuários. à partir da hora que vc utiliza uma thread dentro da sua aplicação, é sem dúvida nenhuma algo muito arriscado, a não ser que você conheça com detalhes o ciclo de vida da servlet. Mas ainda sim, evite!
Procure uma outra alternativa para solucionar seu problema!
Espero não ter viajado, e espero ter ajudado!
Abraços!
Thiago
O container de servlet pode criar um pool para atender as varias chamadas a um servlet o interessante de se fazer realmente em servlet é usar um bloco de sincronismo para acessar ou mudar recursos que não podem ser alterados simultaneamente ou implementar a interface SigleThreadModel na servlet ai o conteiner pode usar um monitor para travar e liberar a thread que ele esta usando para responder uma servlet como um pool.
Entendi, galera valeu pela ajuda, vou dar uma analisada no geral do que foi falado por aqui e continuar os estudos, valeu !
[]s
Não é aconselhável utilizar threads dentro de webcontainer, já que é o container quem se responsabiliza pelo gerenciamento das threads, que seriam as próprias servlets que atendem as requisições dos usuários.
Se as Threads fossem gerenciadas pela própria Servlet, você não precisaria se preocupar em matar a sua Thread no destroy da Servlet.
O problema é justamente esse. Se você starta uma Thread na Servlet, a Thread é independente da Servlet e vai continuar rodando mesmo que você dê um stop em sua Web Application.
Ou você mata a Thread no destroy da Servlet (ou fazendo algum outro controle), ou então, ela só vai morrer quando você matar a JVM (parar o Container).
[]'s
Marco Campêlo
Saulo,
isto está correto.
Mas quando eu disse que já precisei usar Threads dentro de uma Servlet, não era para aumentar a capacidade de processamento da Servlet ou para atender múltiplos requests e sim para executar uma tarefa em background, independente dos requests que a Servlet recebia, mas que deviam acontecer durante o ciclo de vida da Web App.
Abraços,
Marco Campêlo
A bom, mas batendo na tecla que vc disse … é um tanto arriscado , principalmente pela disponibilidade que seu aplicativo tem que ter , já que em alguma instancia vc vai ter que talvez ate derrubar seu aplicativo ou maqiuna. Adotar uma destruição no destroy é realmente a melhor pratica , que vc mencionou acima mas será que vai ser efetivo ? e se sua thread não terminar de fazer o trablaho sujo dela hehe, ai fica dificil adotar uma outra forma. Então a melhor forma seria não adotar a thread em um servelt talvez em um ejb que são mais gerenciaveis.
Oque vocês sugerem usar em vez de uma thread ? Fazer o controle syncronized de um obejto por exemplo ? Com Wait(), Notify() e Notifyall() ?
[]s
Com certeza , com um bloco sincronized ou usando a interface singlethreadmodel.
Servlet SingleThread não resolve o problema dele, que quer implementar uma “Servlet eterna”! 
[]'s
Marco Campêlo
Bom restou então utilizar um bloco syncronized então, vou trabalhar com ele, só uma ultima coisa esse bloco não é caracterizado como uma thread ?
Na documentação da Sun no método wait():
Causes current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object. In other words, this method behaves exactly as if it simply performs the call wait(0).
The current thread must own this object’s monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object’s monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
This method should only be called by a thread that is the owner of this object’s monitor. See the notify method for a description of the ways in which a thread can become the owner of a monitor.
[]s
Oque vocês sugerem usar em vez de uma thread ? Fazer o controle syncronized de um obejto por exemplo ? Com Wait(), Notify() e Notifyall() ?[]s
da p/ fazer um while(true) dentro do metodo doGet do servlet, com isso ele ficaria eternamente printando msg ate vc mandar sair do while.
[]'s