Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Concorrência e os tipos atômicos - Revista Java Magazine 103
O artigo apresenta como instruções simples e compactas podem não ser thread-safe e as opções que temos, dependendo do cenário, para resolver este problema: o uso dos locks ou dos tipos atômicos.
Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
O termo “código Java multi-thread” não está mais vinculado a aplicações complexas, restritas a um grupo seleto de desenvolvedores lidando com threads, locks e similares. O dia-a-dia da maioria dos desenvolvedores já está repleto de situações nas quais suas classes podem ser acessadas por múltiplas threads ao mesmo tempo, mesmo que você nunca tenha escrito um trecho de código envolvendo uma Thread sequer. O entendimento de como o código irá se comportar em tais situações é essencial, mesmo que você desenvolva aplicações mais “tradicionais”. Neste contexto, este artigo fornece informações úteis para quem deseja escrever código Java multi-thread de forma correta, tirando benefício dos tipos atômicos introduzidos na versão 5.0 da linguagem.
As múltiplas threads já estão aí
A programação concorrente já é uma realidade. Independente da arquitetura ou camada de sua aplicação Java, certamente existe alguma forma de acesso concorrente ou, se não existe, é porque alguém já se preocupou com isso por você. Dois exemplos interessantes, um em cada extremo, em relação ao desafio da programação concorrente, são os Servlets e os EJBs.
Na arquitetura dos Servlets, uma única instância é acessada de forma concorrente.
Múltiplas threads acessam o mesmo objeto ao mesmo tempo. Isso quer dizer que sua aplicação é responsável por gerenciar o acesso concorrente a elementos compartilhados, principalmente no que se refere às propriedades da classe. As variáveis criadas internamente nos métodos são locais às threads e não é necessário se preocupar com elas.
O caso dos EJBs é o oposto. Existe a garantia que somente uma thread por vez acessa uma instância do EJB ao mesmo tempo (exceto para o caso de um EJB Singleton, no qual o acesso concorrente é permitido). Para garantir a performance, são criadas várias instâncias, o que é chamado de pool. Neste caso, o desenvolvedor não precisa se preocupar em proteger as propriedades da classe já que elas serão acessadas somente por uma thread por vez.
"
Este é um post disponível para assinantes MVP
As múltiplas threads já estão aí
A programação concorrente já é uma realidade. Independente da arquitetura ou camada de sua aplicação Java, certamente existe alguma forma de acesso concorrente ou, se não existe, é porque alguém já se preocupou com isso por você. Dois exemplos interessantes, um em cada extremo, em relação ao desafio da programação concorrente, são os Servlets e os EJBs.
Na arquitetura dos Servlets, uma única instância é acessada de forma concorrente.
Múltiplas threads acessam o mesmo objeto ao mesmo tempo. Isso quer dizer que sua aplicação é responsável por gerenciar o acesso concorrente a elementos compartilhados, principalmente no que se refere às propriedades da classe. As variáveis criadas internamente nos métodos são locais às threads e não é necessário se preocupar com elas.
O caso dos EJBs é o oposto. Existe a garantia que somente uma thread por vez acessa uma instância do EJB ao mesmo tempo (exceto para o caso de um EJB Singleton, no qual o acesso concorrente é permitido). Para garantir a performance, são criadas várias instâncias, o que é chamado de pool. Neste caso, o desenvolvedor não precisa se preocupar em proteger as propriedades da classe já que elas serão acessadas somente por uma thread por vez.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Daniel Cicero Amadei
Blog: http://www.amadei.com.br
Bacharel em Sistemas de Informação pelo Mackenzie e pós-graduado pela Fundação Vanzolini. Trabalha com Java desde 1999 e possui as certificações SCJP, SCWCD, SCBCD, SCDJWS, SCEA, BEA Certified Developer: Integration Solutions e BEA Certified SOA Architect....
O que você achou deste post?
Cursos relacionados




