Estratégia para Encerramento de Threads

  A grande maioria das threads que usamos deixamos encerrar naturalmente ao encerrar a tarefa que estamos executando. Ou seja, ao encerrarmos o Runnable a thread encerra também.
  Mas, existem alguns casos em que uma thread tem uma duração infinita. Digo, no sentido "infinito enquanto dure" do Vinicius de Moraes...
  No Java não temos uma maneira direta de encerrar uma thread. Temos de solicitar o encerramento da thread via um "recado".
  Uma forma é usar uma variável booleana para indicar a intenção de que desejamos encerrar o processo em execução.
  Deve-se definir essa variável como volatile ou sincronizar os acessos a ela, senão o "recado" pode não chegar à thread destinatária.
  Mas, essa forma não resolve todos os casos, se a tarefa estiver bloqueada por algum motivo, e se não sair do bloqueio, não verá o pedido de encerramento.
  Para esses casos, temos a opção de usarmos o método da thread chamado interrupt(). Esse método liga uma variável de status da thread que indica que foi solicitado uma interrupção. Aí é só verificar essa variável com o método isInterrupted() para saber se o encerramento foi solicitado, ou, se estiver bloqueado por algum método que responda a interrupção, vai receber um InterruptedException.
  O importante é que precisamos definir uma estratégia de encerramento para as threads. Devemos definir claramente, como solicitar o encerramento, quando a tarefa deve verificar se foi solicitado o encerramento e, finalmente, quais procedimentos realizar para encerrar a tarefa.

Isso é fundamental no Android, senão, podemos ter threads "trabalhando" mesmo com a app em background.

PS1: Temos alguns casos em que o recurso que está bloqueando não responde à interrupção, nesses casos, devemos usar uma tática diferente para cada caso, mas, como regra geral, fechamos/encerramos o recurso, o que acarretará em alguma Exception.

PS2: Se estiver bloqueado por trava, só vai avançar se obtiver a trava.

PS3: Se estiver usando AsyncTask, usar cancel() para solicitar o encerramento e no doInBackground() verificar se foi solicitado o encerramento via isCanceled().

PS final: Se você usa uma outra estratégia, posta aqui para termos outra abordagem!


Abraços

Estudando Design Patterns

Plano de estudos para o primeiro trimestre: Design Patterns.

Materiais:


.Apostila - Design Patterns em Java, da K19

.Livro - Design Patterns: Elements of Reusable Object-Oriented Software
             Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides

.Livro - Head First Design Patterns
             Eric Freeman, Elisabeth Robson, Bert Bates e Kathy Sierra


Abraços

Cuidados em relação ao uso de Threads

Estive dando uma boa estudada em threads e registrei algumas observações que acho útil deixar aqui no blog, pode ser de interesse para quem também esteja estudando o tópico.

Tenho dito que usar threads é imperativo no Android, quem já tomou um "ANR" ou mais recentemente, "NetworkOnMainThreadException", sabe do que estou falando.
Já postei também sobre os diversos benefícios advindos do uso de threads em aplicativos Android.

Mas, tem o outro lado da questão: os riscos no uso de threads.
Primeiro temos os riscos de segurança, relacionados com o uso compartilhado de dados, principalmente dados mutáveis, e seu gerenciamento, podemos resumir esses problemas como "acesso em momento indevido", seja por acesso a um objeto em fase de construção, ou no meio de uma atualização, ou atomicidade, ou problemas de visibilidade.
Por visibilidade entendam: uma thread pode não "ver" as últimas alterações que outra thread tenha feito num determinado dado.
Depois temos os problemas relacionados com ativação de threads, seja travamento por deadlock, ou threads que não conseguem avançar por falta de recursos.
E, por fim, temos os problemas de performance, afinal, ter uma outra thread tem um custo, que não está relacionado com processamento produtivo e sim em gerenciar as diversas threads.

Usar threads com eficiência significa tentar usar o máximo de processamento paralelo e o mínimo de processamento sequencial. Identificar quando o processamento deve ser sequencial, é responsabilidade do programador, então, o DVM (Dalvik Virtual Machine) espera (e todos os seus usuários, sem contar o seu chefe e outros interessados...) que você tenha informado corretamente esses pontos de sincronismo.
Isso, sincronização, deve ser feito para garantir consistência sequencial.
Você precisa ter ciência de que o compilador, o Dalvik, o Sistema Operacional e o processador todos estão fazendo malabarismos com o seu código para obter o máximo de performance possível.
Então saiba usar nos lugares certos as palavras chaves synchronized, volatile, lock, unlock, wait, notify, etc, senão o seu programa vai fazer coisas difíceis de imaginar, imagine como conseguir corrigir!

Bons códigos!