Isenção de responsabilidade: Acabei de resumir todas as respostas impressionantes e as escrevi em minhas palavras.
Ao implementar o Singleton, temos 2 opções
1. Carregamento lento
2. Carregamento antecipado
O carregamento lento adiciona um pouco de sobrecarga (muito para ser honesto), portanto, use-o somente quando você tiver um objeto muito grande ou código de construção pesada E também tiver outros métodos ou campos estáticos acessíveis que possam ser usados antes que uma instância seja necessária, e somente então você precisará usar a inicialização lenta. Caso contrário, escolher o carregamento antecipado é uma boa escolha.
A maneira mais simples de implementar o Singleton é
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
return INSTANCE;
}
}
Tudo é bom, exceto seu singleton carregado cedo. Vamos tentar o singleton carregado preguiçosamente
class Foo {
// Our now_null_but_going_to_be sole hero
private static Foo INSTANCE = null;
private Foo() {
if (INSTANCE != null) {
// SHOUT
throw new IllegalStateException("Already instantiated");
}
}
public static Foo getInstance() {
// Creating only when required.
if (INSTANCE == null) {
INSTANCE = new Foo();
}
return INSTANCE;
}
}
Até aí tudo bem, mas nosso herói não sobreviverá enquanto luta sozinho com vários tópicos malignos que desejam muitos exemplos de nosso herói. Então, vamos protegê-lo do mal multi-threading
class Foo {
private static Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
// No more tension of threads
synchronized (Foo.class) {
if (INSTANCE == null) {
INSTANCE = new Foo();
}
}
return INSTANCE;
}
}
mas não é o suficiente para proteger o herói, sério !!! É o melhor que podemos / devemos fazer para ajudar nosso herói
class Foo {
// Pay attention to volatile
private static volatile Foo INSTANCE = null;
// TODO Add private shouting constructor
public static Foo getInstance() {
if (INSTANCE == null) { // Check 1
synchronized (Foo.class) {
if (INSTANCE == null) { // Check 2
INSTANCE = new Foo();
}
}
}
return INSTANCE;
}
}
Isso é chamado de "idioma de bloqueio com verificação dupla". É fácil esquecer a afirmação volátil e difícil entender por que ela é necessária.
Para detalhes: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Agora temos certeza sobre o mal do fio, mas e a cruel serialização? Temos que garantir que, mesmo durante a desserialização, nenhum novo objeto seja criado
class Foo implements Serializable {
private static final long serialVersionUID = 1L;
private static volatile Foo INSTANCE = null;
// Rest of the things are same as above
// No more fear of serialization
@SuppressWarnings("unused")
private Object readResolve() {
return INSTANCE;
}
}
O método readResolve()garantirá que a única instância seja retornada, mesmo quando o objeto foi serializado em uma execução anterior do nosso programa.
Finalmente, adicionamos proteção suficiente contra threads e serialização, mas nosso código parece volumoso e feio. Vamos dar uma olhada no nosso herói
public final class Foo implements Serializable {
private static final long serialVersionUID = 1L;
// Wrapped in a inner static class so that loaded only when required
private static class FooLoader {
// And no more fear of threads
private static final Foo INSTANCE = new Foo();
}
// TODO add private shouting construcor
public static Foo getInstance() {
return FooLoader.INSTANCE;
}
// Damn you serialization
@SuppressWarnings("unused")
private Foo readResolve() {
return FooLoader.INSTANCE;
}
}
Sim, este é o nosso herói mesmo :)
Como a linha private static final Foo INSTANCE = new Foo();é executada apenas quando a classe FooLoaderé realmente usada, isso cuida da instanciação lenta,
e é garantido que seja seguro para threads.
E chegamos até aqui, aqui está a melhor maneira de alcançar tudo o que fizemos é a melhor maneira possível
public enum Foo {
INSTANCE;
}
Que internamente será tratado como
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
É isso aí! Não há mais medo de serialização, threads e código feio. Também ENUMS singleton são preguiçosamente inicializado .
Essa abordagem é funcionalmente equivalente à abordagem de campo público, exceto que é mais concisa, fornece o mecanismo de serialização gratuitamente e oferece uma garantia rígida contra instanciações múltiplas, mesmo em face de sofisticados ataques de serialização ou reflexão. Embora essa abordagem ainda não tenha sido amplamente adotada, um tipo de enum de elemento único é a melhor maneira de implementar um singleton.
-Joshua Bloch em "Java eficaz"
Agora você deve ter percebido por que os ENUMS são considerados a melhor maneira de implementar o Singleton e agradecemos sua paciência :)
Atualizei-o no meu blog .