Double-checked locking: pra que?!

Voce esta julgando as coisas sem conhecer o codigo usado. Claro que muitas vezes um static xxx meuMetodo da pro gasto, mas E DAI se eu quiesse colocar um getInstance()?
Por exemplo, o metodo para pegar determinada mensagem eh estatico, mas o metodo para dar reload no arquivo .properties nao. Por que? eu simplesmente quis fazer assim, meter static em tudo nao me agradava, entao criei uma instancia privada para ter acesso as partes nao-static.

Como disse na outra mensagem, se chegar pro codigo do cara e dizer "AARGGHH, isso aqui nao tem nada a ver, tinha que ter usado tudo static" soh vai deixar a pessoa humilhada e constrangida.

Rafael

Rafael Steil wrote:Voce esta julgando as coisas sem conhecer o codigo usado. Claro que muitas vezes um static xxx meuMetodo da pro gasto, mas E DAI se eu quiesse colocar um getInstance()?

Rafael, CALMA.

Eu não estou tentando te atacar ou julgar. Estou tentando levantar uma discussão construtiva sobre o uso (especificamente, o mal-uso) de singletons. Não leve o que eu estou escrevendo tão a sério, ou como uma afronta pessoal - de forma alguma é a minha intenção.

Rafael Steil wrote:Como disse na outra mensagem, se chegar pro codigo do cara e dizer "AARGGHH, isso aqui nao tem nada a ver, tinha que ter usado tudo static" soh vai deixar a pessoa humilhada e constrangida.

Eu lasco esses "AAAAAARGH"s bem frequentemente, apesar de - eu acho - ser um pouco mais discreto

O curioso é que, ao invés de olhares humilhados e constrangidos, geralmente eu sou recebido com um "mas pq?", que geralmente são bem mais construtivos, e geram uma discussão bastante interessante

JavaEvangelist Membro desde: 28/06/2003 19:22:53 Mensagens: 338 Offline

Bom, dos artigos recomendados, a citação que mais me chamou atenção foi...

If the class maintains no state, and you cannot conceive of it maintaining state in the future, it's static. Otherwise it's a Singleton.

... encontrada nesse artigo e que acessei atraves desse outro. Não uso singletons a todo momento, mas, em alguns casos parece-me ser a alternativa mais interessante, por exemplo, um pool de conexões. Não dá pra ficar criando o pool a todo instante. Entretanto, ao que parece, a alternativa sugerida seria colocar o pool como um atributo estatico em algum canto, é isso? Algo como:

Era mesmo isso? Se for, não vejo qual a vantagem. Já que eu poderia fazer o singleton assim:

Sobre o overhead que terei quando sincronizar o getInstance, li nesse artigo, recomendado nesse post, que o custo da sincronização nas jvms mais modernas não é tão grande assim. É claro, se eu tiver uma quantidade muito grande de threads acessando o getInstance, um pequeno overhead pode se transformar numa grande espera. Mas, acho que dá pra continuar usando o singleton se eu não usar lazy initiation como no exemplo acima ou eu posso rever algumas coisas e transformar o singleton numa factory, acho.

Até.

Virtual Machine Man Membro desde: 21/08/2002 03:53:28 Mensagens: 661 Offline

Eu também solto esses AAAARGH, e nem sempre o pessoal gosta. Quando eles aprendem que nao é com eles, e que geralmente eu faco AARGH quando vejo um código igualzinho ao que eu mesmo um dia escrevi e me deu tanto trabalho depois, eles páram de se ofender. Mas de uns tempos pra cá, tenho tomado mais cuidado.

Muito código que eu geralmente critico eu mesmo já escrevi igual um dia. Outras vezes, é coisa que eu nunca vi, e nunca tive a inspiracao para fazer assim. Nesses casos, quando o outro cara é bom na discussao, eu aprendo alguma coisa.

Meus AAARGHs geralmente promovem melhor software, ou pq o cara aprende alguma coisa, ou pq eu aprendo alguma coisa. Nunca, mas nunca mesmo, eu avalio um programador pelo código que ele escreve, mas pelo quanto ele é capaz de defendê-lo (nos pontos bons) e aprimorá-lo (nos pontos ruins) numa discussao. Pq eu preciso confiar no código dele, e ele no meu.

Eu chamo de singleton uma instância única. Mas essa instancia tem que ser acessada de alguma forma, e nem sempre a melhor forma é um método estático na classe, com construtor privado. Eu penso em componentes, e sei que um dia vou poder precisar de mais de uma daquela instância. Hoje que eu aprendi IoC eu posso fazer assim:

Aquelao!!

eu tambem prefiro sempre singleton. A sun ja cagou pra caramba em fazer a System e a Math tudo estatico. Se a math fosse um singleton, a gente poderia fazer Math.getMath("normal") ou Math.getMath("strictl") por exemplo. Pois hoje em dia a gente tem de trocar tudo que eh Math para StrictMath. Pessimo.

Mas a definicao que o cancao deu eh otima. use singleton se a classe possui um estado. Essa regra deve ser sempre obedecida. E mesmo se ela nao valer (caso da math), as vezes tambem eh interessante usar singleton.

louds, achei a url que tem a cyclic barrier, ve se eh o q eu tava falando:
http://gee.cs.oswego.edu/dl/concurrent/dist/docs/index.html

Então Paulo, como já tinha falado, voce confundiu a primitiva de sincronização barrier com oque vem a ser uma 'memory-barrier'.

Um barrier simplesmente bloqueam todas threads nela ate um condição ser atingida, depois não bloqueia mais.

louds wrote:

Um barrier simplesmente bloqueam todas threads nela ate um condição ser atingida, depois não bloqueia mais.

essa ai eh a primtiva de sincronizacao? memory barrier faz o que?

Notícias, artigos e o maior fórum brasileiro sobre Java