Fique por dentro no canal oficial do Java no YouTube com videos, keynotes, apresentações e muita informações dos bastidores da plataforma. Uma semana abençoada para todos!
“Enquanto aguardamos a bendita esperança: a gloriosa manifestação de nosso grande Deus e Salvador, Jesus Cristo.” Tito 2:13
Gostaria de avisar a todos seguidores do blog que a partir do dia 05 de outubro estarei em minhas merecidas férias, voltando às atividades somente depois do dia 05 de novembro. O blog e os feedbacks ficara parado nestes dias. É isso ai! Até mês que vem 
.
“Assim foram alguns de vocês. Mas vocês foram lavados, foram santificados, foram justificados no nome do Senhor Jesus Cristo e no Espírito de nosso Deus.” 1 Coríntios 6:11
De vez em quando temos a infeliz necessidade de dar um mergulho para “debaixo dos panos” da JVM quando aplicativos em produção apresentam problemas. As situações clássicas são: lentidão crescente, travamentos JVM, deadlocks, pausas de JVM, uso de CPU súbita ou persistentemente alta ou até mesmo terror de qualquer pessoa… o temido OutOfMemoryError (OOME). A boa notícia é que existem muitas ferramentas Open que você pode usar para extrair vários tipos de informações preliminares da sua JVM, permitindo-lhe obter um olhar clinico “sob o capô” com o objetivo de diagnosticar tais situações. No site da InfQ foi publicado um ótimo artigo que apresenta ferramentas e praticas relacionado ao assunto. Leitura obrigatória para qualquer profissional Java!
“Gloriem-se no seu santo nome; alegre-se o coração dos que buscam o Senhor.” 1 Crônicas 16:10
“A prototipagem ganha cada vez mais valor no mercado e já é utilizada em muitas empresas. Entretanto, ainda é vista muitas vezes apenas como uma forma de comunicação entre o requisito e o desenvolvimento, representando somente a disposição da tela. Na verdade a prototipagem permite a validação e melhor entendimento dos requisitos levantados com o usuário, além de lhe proporcionar uma visão previa do produto que será construído.”
Na revista MundoJ edição 48 foi escrito um artigo muito interessante sobre a prototipagem, esclarecendo as maiores dúvidas sobre o assunto. Leitura indicada para os interessados em aplicar prototipação. Segue as ferramentas indicadas no artigo:
1) Balsamiq – http://balsamiq.com/ Custo $79,00.
2) Pencil – http://pencil.evolus.vn/en-US/Home.aspx grátis.
3) Tiggr – http://gotiggr.com/ grátis.
“Pois também Cristo sofreu pelos pecados uma vez por todas, o justo pelos injustos, para conduzir-nos a Deus. Ele foi morto no corpo, mas vivificado pelo Espírito.” 1 Pedro 3:18
“Em um post em seu blog, K. Siva Prasad Reddy, desenvolvedor de software da JP Morgan, trouxe à tona a questão polêmica sobre a possibilidade de frameworks web estarem “emburrecendo” os desenvolvedores. Ele comenta que, após realizar algumas entrevistas de emprego em sua empresa, chegou à conclusão que a utilização de frameworks pode impedir que os desenvolvedores tenham um aprendizado mais profundo sobre as características técnicas da solução, gerando consequências negativas em várias áreas.” Veja o artigo original.
“Pois jamais a profecia teve origem na vontade humana, mas homens falaram da parte de Deus, impelidos pelo Espírito Santo.” 2 Pedro 1:21
Dentro da programação de uma solução usando a tecnologia Java, os desenvolvedores tem a responsabilidade diária de escolher corretamente em qual escopo de ciclo de vida seus objetos existiram. Em minhas consultorias em geral venho percebendo que a maioria dos profissionais Java desconhecem completamente um dos escopos mais interessantes e muito eficiente chamado de Thread-Local. A falta de uso desse escopo em uma solução pode gerar complicadores agravantes na arquitetura, levando a implementação na maioria das vezes para o caminho da complexidade e inflexibilidade. Diante esse cenário, hoje eu gostaria de apresentar o conceito e prática desse escopo, fazendo com que programadores e projetistas Java possam se equipar com mais esse poderoso recurso do JSE.
Thread-local é considerado como mais um “escopo de acesso” como outros muitos existentes dentro do Java utilizado para definir o ciclo de vida dos objetos existentes durante a execução de um programa orientado a objetos. O grande diferencial desse escopo seja talvez pelo fato dele ser completamente baseado em conceitos de programação concorrente, fazendo com ele fique um pouco mais complicado de se entender e usar.
O escopo Thread-Local possui dois tipos de comportamento distintos que lhe diferencia drasticamente dos outros. Poderíamos chamá-los de global e local.
Global – todos os objetos armazenados em uma Thread-Local são globais para a thread corrente de execução. Isso que dizer que os métodos de quaisquer objetos sendo executados dentro de uma mesma thread terão visibilidade para este escopo.
Local – todos os objetos armazenados em uma Thread-Local estarão restritos somente para objetos sendo executado dentro da determinada thread. Isso que dizer que os métodos de quaisquer objetos sendo executados em outras threads não terão visibilidade para este escopo.
O ponto de referencia para se assimilar a brincadeira é se conscientizar que quem executa um método de um objeto dentro de um programa Java é justamente algum objeto Thread, sendo ele criando manualmente ou não. Dentro de cada thread existe então um lugar especial que pode ser usado para armazenar objetos pertencentes especificamente a thread. Todos as chamadas de objetos que forem empilhados naquela thread terão visibilidade transparente para esse escopo, podendo então usa-lo para os mais diferentes propósitos.
Para tentar clarear mais as idéias, eu poderia dizer que o escopo Thread-Local funciona basicamente da mesma forma que o famoso e velho de guerra escopo estático. Todos os objetos colocados como estáticos no Java são criados apenas uma vez e ficam na memória até o termino da JVM. A única diferença é que os objetos colocados na Thread-Local ficam na memória até o termino da execução da determinada thread corrente. O escopo acaba, quando a Thread terminar de ser executada.
A figura abaixo apresenta um gráfico que ilustra a escopo estático:
Temos na figura acima dois objetos do tipo thread invocando concorrentemente métodos de alguns objetos compartilhados e outros objetos não compartilhados. Tudo que é colocado como estático é globalmente compartilhado para todas as threads e todos os objetos sendo executados dentro de cada thread.
Já na próxima figura temos a representação que ilustra o escopo Thread-Local:
Temos na ultima figura dois objetos do tipo thread invocando concorrentemente os mesmo objetos da primeira figura. Nesse caso em especifico, o escopo Thread-Local age como um compartimento opcional colocado dentro da cada thread, no qual todos os métodos invocados dentro daquela determinada thread tem acesso transparente, podendo usá-lo para qualquer fim necessário.
Use em qualquer lugar que necessite compartilhar objetos em nível de execução de Thread. Alguns possíveis exemplos seriam – parâmetros de sistema, parâmetros de usuários, parâmetros de autenticação e autorização e até parâmetros de processos. Um caso clássico de Thread-Local é a propagação de objetos de transação JDBC com chamadas recursivas. Objetos do padrão DAO poderiam usar este escopo para compartilhar a transação corrente, adicionando varias instruções SQL de diferentes objetos DAO. Frameworks que oferecem serviços transacionais para camadas de persistência como Spring utilizam-se dessa abordagem, podendo também ser facilmente implementada sem nenhum framework de terceiro.
A escopo Thread-Local é disponibilizado no Java usando a classe java.lang.ThreadLocal. Para todas as informações dessa classe, veja o JavaDoc.
Segue abaixo a implementação de um exemplo bem simples de Thread-Local.
A primeira classe chamada de ClasseThreadLocal foi utilizada para implementar a escopo Thread-Local. A segunda classe chamada de Regra foi utilizado para implementar o objeto que será executando concorrentemente dentro de varias threads. Veja que o método gravar() apenas acessa o valor dentro do escopo Thread-Local. Já a classe ProcessoThread foi utilizado para implementar as threads que serão executadas em paralelo. Veja que o método run() armazena um objeto do tipo String dentro do escopo Thread-Local que será posteriormente acessível dentro do objeto implementado pela classe Regra. Por fim vemos a classe Exemplo implementando a método main() que faz toda a brincadeira acontecer. Veja que ele cria apenas um objeto Regra e quatro objeto ProcessoThread. Resumidamente, cada objeto thread executa concorrentemente o mesmo objeto Regra que transparentemente e separadamente acessa cada um valor diferente pertencente a sua própria thread de execução.
Existe uma certa situação em usar Thread-Local dentro de containers JEE, uma vez que a maioria deles otimizam gatos com a criação de objetos threads usando abordagem de pool. Por isso, os objetos colocados dentro do escopo Thread-Local em execuções dentro de containers JEE podem ficar não elegíveis para o GC após a execução, uma vez a thread volta para o pool e fica disponível para a próxima invocação. A forma correta de tratar isso é limpar o escopo Thread-Local no final de cada execução, chamando o método ThreadLocal.remove(). Eu fico por aqui e espero que o artigo te ajude a usar esse incrível escopo. Aquele abraço 
.
“Porque, se perdoardes aos homens as suas ofensas, também vosso Pai celestial vos perdoará a vós”. Mateus 6:14
“Em sentido oposto ao que geralmente ocorre, a responsabilidade pela baixa qualidade do código de sistemas não pode ser atribuída somente aos desenvolvedores, mas sim também à cultura e aos valores comummente incentivados nas organizações. Em última instância, deve ser atribuída aos exemplos passados por aqueles que assumem posições de liderança. É o que o especialista em qualidade de código Avdi Grimm defende em seu post mais recente, onde também aponta alternativas.” O artigo oficial pode ser acessado no site da InfoQ.
“Pois tive grande gozo e consolação no teu amor, porque por ti, irmão, os corações dos santos têm sido reanimados”. Filemom 1:7
Umas das coisas que mais dificulta o aprendizado de produtos da plataforma Java é cada um tem seu objetivo bem definido aplicado em uma camada especifica de funcionalidade dentro da solução. Diante disso, hoje eu gostaria de indicar a leitura deste artigo escrito por Julio Battisti que aborda justamente toda a parte conceitual do desenvolvimento baseado em camadas. Confesso que é melhor artigo que eu já li a respeito do assunto. Boa leitura a todos .
“O ímpio se enlaça na transgressão dos lábios, mas o justo sairá da angústia”. Provérbios 12:13
Veja neste artigo escrito por John Waterwood os motivos pelos quais ele escolheu Java em seus novos projetos.
“Assim os apascentou, segundo a integridade do seu coração, e os guiou pela perícia de suas mãos”. Salmos 78:72
Existem dois problemas básicos que acontecem quando se coloca uma aplicação em produção – consumo de memória e performance. E normalmente estes são tópicos ignorados pela maioria dos programadores de primeira viagem. E por isso, hoje eu gostaria de relembrar um post sobre o assunto http://fernandofranzini.wordpress.com/2009/12/16/praticas-de-aplicativos-web/ Uma ótima semana para todos .
“Salva o teu povo, e abençoa a tua herança; e apascenta-os e exalta-os para sempre”. Salmos 28:9
Este é o meu espaço utilizado para compartilhar notícias, traduções e artigos com o objetivo de promover o conhecimento relacionado com engenharia de software, tecnologias Java e assuntos relacionados. Seja muito bem vindo !
