Dúvida com synchronized

19 de maio de 2009 7 respostas

antonioedirane 19 de maio de 2009

Fiquei com dúvida nesta questão.
Given

public class NamedCounter {
private final String name;
private int count;
public NamedCounter(String name) { this.name = name; }
public String getName() { return name; }
public void increment() { coount++; }
public int getCount() { return count; }
public void reset() { count = 0; }
}

Which three changes should be made to adapt this class to be used
safely by multiple threads? (Choose three.)
A. declare reset() using the synchronized keyword
B. declare getName() using the synchronized keyword
C. declare getCount() using the synchronized keyword
D. declare the constructor using the synchronized keyword
E. declare increment() using the synchronized keyword

Resposta correta: ACE.
Não entendi o porque que as alternativas B e D não precisam do synchronized.

7 Respostas

tnaires 19 de mai. de 2009

Olá
As alternativas B e D dizem respeito ao atributo name, declarado como final - portanto não é possível modificá-lo - e com tipo String, cujos objetos são imutáveis. Ora, se o valor do atributo só pode ser lido, mas não modificado, não há porque se preocupar em sincronizá-lo.

antonioedirane 19 de mai. de 2009

tnaires:
Olá
As alternativas B e D dizem respeito ao atributo name, declarado como final - portanto não é possível modificá-lo - e com tipo String, cujos objetos são imutáveis. Ora, se o valor do atributo só pode ser lido, mas não modificado, não há porque se preocupar em sincronizá-lo.

Valeu tnaires.
Não tinha me atentado que era final. Fiquei só olhando para a thread.
Muito Obrigado.

Vini_Fernandes 19 de mai. de 2009

Cara, a palavra reservada synchronized é utilizada para sincronizar métodos e blocos de código, portanto é um erro de síntaxe sincronizar um construtor, entao acabamos de responder uma das dúvidas. Um dos propósitos de sincronizar o método é proteger o código do método que será realizado, por exemplo, voce nao quer que duas pessoas acessando uma mesma conta corrente saquem valores ao mesmo tempo, pois dessa maneira eles poderao sacar valores que nao deveriam, consequentemente, teriamos como resultado um saldo devedor. Assim, deveremos implementar algo parecido com isso:

public class ContaCorrente{
   private float saldo = 1000.0;
   public synchronized void sacar(float valor){
       saldo -= valor;
   }
   public float getSaldo(){
       return saldo;
   }
}

Veja que o metodo getSaldo() nao esta sincronizado, pois, independente da ordem em as theads (dois clientes distintos) chamarem o metodo, não vai mudar em o estado da Conta Corrente! A unica coisa que eles fazem eh receber o valor do saldo da conta e isso nao importa se foi feito pelo cliente A ou cliente B.

Espero ter ajudado

tnaires 20 de mai. de 2009

Mas lembre-se que não é só o fato de ser final, pois se o tipo do objeto fosse mutável - java.util.Date, por exemplo - você poderia ainda modificar seu conteúdo e o atributo seria passível de sincronização.

deyvid 20 de mai. de 2009

Ok, muito bom. Mas não entendi por que C ( public int getCount() { return count; } ) precisa se sincronizado visto que não estamos lidando com mudança de valores neste caso específico

tnaires 20 de mai. de 2009

Porque no momento em que uma thread está chamando o método getCount() e aguardando o término da sua execução, outra thread pode estar executando o método increment() ou reset(), que altera o valor da variável.

Agora talvez a questão tenha sido um pouco infeliz, pois acho que as instruções envolvidas nos métodos increment() e reset() são atômicas.

Lavieri 20 de mai. de 2009

Agora talvez a questão tenha sido um pouco infeliz, pois acho que as instruções envolvidas nos métodos increment() e reset() são atômicas.

eu concordo… não há razão para sincronizmo… é tudo atomico… se precisar synchronismo vai ser quando vc junta operações, essa questão é no minimo triste… mas pelo enuncionado, so sobram as 3 possibilidades indiciadas como certa mesmo… mas a questão é muito infeliz sim

Criado 19 de maio de 2009

Ultima resposta 20 de mai. de 2009

Respostas 7

Participantes 5

7 Respostas

Topicos relacionados