DevMedia - asp.net, Java, Delphi, SQL e web Design, tudo em um só lugar!
Bem vindo a DevMedia!
LOGIN:     SENHA:
 
 

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL
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


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.
"
A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da Java Magazine DIGITAL
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?

    0 COMENTÁRIO

[Fechar]

Este post é fechado - você precisa ter acesso ao post para incluir um comentário.


Nenhum comentário foi postado - seja o primeiro a comentar!
Cursos relacionados
Publicidade
[Fechar]

Você precisa estar logado para dar um feedback.

Clique aqui para efetuar o login
[Fechar]


Este post está fechado. Saiba mais sobre a assinatura MVP!
web-03
DevMedia  |  Anuncie  |  Fale conosco
Hospedagem web por Porta 80 Web Hosting
2013 - Todos os Direitos Reservados a web-03