Serialização – Item 74

serializacao-rastreabilidade-medicamento-rdc-54-2013Implemente Serializable Criteriosamente

A definição de uma classe serializável constitui um compromisso sério que deve ser adotado com cuidado. Uma vez feito, o autor da classe está assumindo o compromisso de evoluir as novas futuras versões, garantindo compatibilidade de serialização retroativa. Uma classe serializável apresenta as seguintes desvantagens:

  1. Diminui a flexibilidade de evolução, uma vez que o autor é responsável por dar suporte para serialização retroativa. Em alguns casos pode até impedir novas implementações por falta de compatibilidade.
  2. Altas cargas de testes no lançamento de uma nova versão da classe para garantir suporte para serialização retroativa.
  3. Aumenta a probabilidade de invariância, uma vez que é fácil esquecer-se de assegurar o estado consistente na reconstrução do objeto serializado.

Portanto, a facilidade de usar serializable é ilusória e não é uma decisão a ser tomada superficialmente.

Para todas as informações, veja o post inicial.

“Portanto, vistam-se de misericórdia, de bondade, de humildade, de delicadeza e de paciência.” Colossenses 3:12

Concorrência – Item 73

avoid-running-into-walls-step-7Evite o uso de grupos de thread

A classe “ThreadGroup” foi criada com funcionalidades bem limitadas e com muitas falhas. Ela se encaixa melhor na categoria de experimento mal sucedido. Portanto, considere a obsoleta e evite o seu uso. Caso existe a necessidade de trabalhar com grupos lógicos de threads (pooling), prefira o uso da API ExcecutorService da java.util.concurrent.

Para todas as informações, veja o post inicial.

“Estou certo de que o SENHOR está sempre comigo; ele está ao meu lado direito, e nada pode me abalar.”Salmos 16:8

Concorrência – Item 72

downloadNão dependa do agendador de thread

Nunca crie programas que dependa do agendador de threads para se funcionar corretamente. O programa resultante não será robusto e nem portável. Portanto, não depende de Thread.yield() ou das prioridades das Threads. Estes recursos são apenas “dicas” para o agendador da JVM, não tendo garantias de execução. As prioridades das Threads podem ser usadas para melhorar a qualidade de um programa já funcional, mas nunca devem ser utilizados para corrigir os erros graves de um programa mal elaborado.

Para todas as informações, veja o post inicial.

“Deus nos salvou e nos chamou para sermos o seu povo. Não foi por causa do que temos feito, mas porque este era o seu plano e por causa da sua graça.” 2 Timóteo 1:9

Concorrência – Item 71

metro-dfUse a inicialização preguiçosa criteriosamente

Inicialização preguiçosa é uma otimização que pode ser uma faca de dois gumes. Ela diminui o custo de inicialização, mas aumenta o custo de acesso. Dependendo da parcela de campos, do custo de inicialização e da frequência de acesso, ela pode (como qualquer outra prática de otimização) acabar prejudicando o desempenho. A única forma de realmente saber é avaliando o desempenho com e sem a inicialização preguiçosa. Portanto, prefira inicializar os campos normalmente e não preguiçosamente. Se tiver que optar pela inicialização preguiçosa para atingir seus objetos de desempenho ou para romper a circularidade de inicialização prejudicial, use a adequada técnica de acordo como o seu caso:

  • Para campos de instâncias use o idioma de “verificação repetida”.
  • Para campos estáticos use o idioma de “classe possuidora”.
  • Para campos de instâncias que tolerem inicialização repetida, use o idioma de “verificação única”.

Para todas as informações, veja o post inicial.

“Se você disser com a sua boca: ‘Jesus é Senhor’ e no seu coração crer que Deus ressuscitou Jesus, você será salvo. Porque nós cremos com o coração e somos aceitos por Deus; falamos com a boca e assim somos salvos. Romanos 10:9-10

Concorrência – Item 70

imagesDocumente a garantia de execução concorrente

A maneira de como uma classe se comporta quando suas instâncias ou métodos estáticos estão sujeitos a uso concorrente é parte importante do contrato que a classe firma com seus clientes. Se isso não for documentado, os programadores clientes serão forçados as fazer suposições que se estiverem erradas resulte em sincronização insuficiente (Item 66) ou excessiva (Item 67) ambos erros graves.  Portanto toda classe deve documentar claramente suas propriedades de garantias de execuções (Imutável, Garantia Incondicional, Garantia Condicional e Sem Garantia) cuidadosamente em prosa ou em anotação @Imutable, @ThreadSafe ou @NotThreadSafe como indicado pelo livro Java Concorrente na Prática.

Para todas as informações, veja o post inicial.

“Portanto, obedeçam a Deus e enfrentem o Diabo, que ele fugirá de vocês.” Tiago 4:7

Concorrência – Item 69

pista-wgp-londres-carros-5170-yellow-23187-MLB20242118419_022015-OPrefira utilitários de concorrência a wait() e notify()

A partir do lançamento da versão 5, a plataforma Java fornece utilitários de concorrência de nível mais alto (java.util.concurrent) oferecendo inúmeras facilidades que antes os programadores tinham que gerenciar manualmente. Veja http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html .

Portanto, não é mais indicado a coordenação manual de threads usando os métodos wait(), notify() e notifyAll(). O mecanismo preferível de uso são os novos sincronizadores de nível superior, que possui uma série de facilidades. Consulte a documentação para todas as informações.

Para todas as informações, veja o post inicial.

“E tudo o que vocês fizerem ou disserem, façam em nome do Senhor Jesus e por meio dele agradeçam a Deus, o Pai.” Colossenses 3:17

Concorrência – Item 68

downloadPrefira executores e tarefas a thread

A partir do lançamento da versão 5, a plataforma Java fornece utilitários de concorrência de nível mais alto (java.util.concurrent) oferecendo inúmeras facilidades que antes os programadores tinham que gerenciar manualmente. Veja http://docs.oracle.com/javase/tutorial/essential/concurrency/index.html

A principal abstração que servia tanto de unidade de trabalho quanto mecanismo de execução conhecido como Thread foi separado em duas vertentes – Runnable e Callable. Portanto, não é mais indicado à criação manual de threads e principalmente de grupos lógicos de threads (pooling). O mecanismo preferível para criar e executar tarefas em paralelos é o ExecutorService que possui uma série de facilidades e otimizações. Consulte a documentação para todas as informações – http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html.

Para todas as informações, veja o post inicial.

“A pessoa faz os seus planos, mas quem dirige a sua vida é Deus, o SENHOR.” Provérbios 16:9