Avertissement: je viens de résumer toutes les réponses impressionnantes et de l'écrire dans mes mots.
Lors de la mise en œuvre de Singleton, nous avons 2 options
1. Chargement paresseux
2. Chargement précoce
Le chargement différé ajoute un peu de surcharge (pour être honnête), utilisez-le uniquement lorsque vous avez un objet très volumineux ou un code de construction lourd ET que vous avez également d'autres méthodes ou champs statiques accessibles qui pourraient être utilisés avant qu'une instance ne soit nécessaire, alors et seulement alors vous devez utiliser l'initialisation paresseuse. Sinon, choisir un chargement précoce est un bon choix.
Le moyen le plus simple de mettre en œuvre Singleton est
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;
}
}
Tout va bien sauf son singleton chargé tôt. Permet d'essayer un singleton paresseux
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;
}
}
Jusqu'ici tout va bien mais notre héros ne survivra pas en se battant seul avec plusieurs fils diaboliques qui veulent de nombreuses instances de notre héros. Permet donc de le protéger du diabolique 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;
}
}
mais il ne suffit pas de protéger le héros, vraiment !!! C'est le mieux que nous pouvons / devrions faire pour aider notre héros
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;
}
}
Ceci est appelé "idiome de verrouillage à double vérification". Il est facile d'oublier la déclaration volatile et difficile de comprendre pourquoi elle est nécessaire.
Pour plus de détails: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Maintenant, nous sommes sûrs du mauvais fil, mais qu'en est-il de la sérieuse sérialisation? Nous devons nous assurer que même pendant la dé-sérialisation aucun nouvel objet n'est créé
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;
}
}
La méthode readResolve()s'assurera que la seule instance sera retournée, même lorsque l'objet a été sérialisé lors d'une précédente exécution de notre programme.
Enfin, nous avons ajouté suffisamment de protection contre les threads et la sérialisation, mais notre code semble volumineux et laid. Laissons notre héros se refaire une beauté
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;
}
}
Oui, c'est notre même héros :)
Puisque la ligne private static final Foo INSTANCE = new Foo();n'est exécutée que lorsque la classeFooLoader est réellement utilisée, cela prend soin de l'instanciation paresseuse,
et est-il garanti être thread-safe.
Et nous sommes venus si loin, voici la meilleure façon de réaliser tout ce que nous avons fait est la meilleure façon possible
public enum Foo {
INSTANCE;
}
Qui en interne sera traité comme
public class Foo {
// It will be our sole hero
private static final Foo INSTANCE = new Foo();
}
C'est ça! Plus de peur de la sérialisation, des threads et du code laid. Les singleton ENUMS sont également initialisés paresseusement .
Cette approche est fonctionnellement équivalente à l'approche du domaine public, sauf qu'elle est plus concise, fournit gratuitement le mécanisme de sérialisation et offre une garantie à toute épreuve contre les instanciations multiples, même face à des attaques sophistiquées de sérialisation ou de réflexion. Bien que cette approche n'ait pas encore été largement adoptée, un type d'énumération à élément unique est le meilleur moyen d'implémenter un singleton.
-Joshua Bloch dans "Java efficace"
Maintenant, vous avez peut-être compris pourquoi ENUMS est considéré comme le meilleur moyen d'implémenter Singleton et merci pour votre patience :)
Mis à jour sur mon blog .