Study notes @Effective Java
The content of the article comes from the book Joshua Bloch-Effective Java (3rd)-2018.chm
BTW: For the concept of serializable/serialized and deserialized, the concept of serialization and deserialization in the article, please refer to the following article
https://blog.csdn.net/qq_27093465/article/details/78544505
Chapter two
Create and unregister objects
Item 3 makes the singleton attribute have a private constructor or enumeration type
Enforce the singleton property with a private constructor or an enum type
Simply, a singleton is a class that is instantiated only once. Typically, singleton representations are either stateless objects such as functions or essentially the only system components.
There are two ways to implement singletons (patterns), both are based on keeping the constructor private and exporting a public static member to provide access to a unique instance.
Members are methods of final fields:
// Singleton with public final field
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public void leaveTheBuilding() { ... }
}
The private constructor is called only once to initialize the public static final field Elvis.INSTANCE instance.
The lack of public or protected constructors guarantees a "single sprite" universe: once the Elvis class is initialized, there is only one instance of Elvis, no more, no
client client can not change this,
but there is one special note: a privileged client The client can use the AccessibleObject.setAccessible method to reflectively call the private constructor.
If you need to defend against this attack, you can modify the constructor to throw an exception when asked to create a second instance.
The public member is a static factory method:
// Singleton with static factory
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() { ... }
}
All calls to Elvis.getInstance return a reference to the same object and will not create any other Elvis instance (same as the special instructions mentioned earlier)
advantage
Advantages of the public field method: The
main API makes the class clear. It is a singleton: the public static field is final, so it always contains the same object reference. The
second advantage is that it has the advantage of a simpler
static factory method:
one is that it makes You can flexibly change your thinking about whether the class is a singleton without changing its API; the factory method returns a separate instance, but it will be modified to return, for example, a separate instance of each thread that calls it. The
second The advantage is that if the application needs it, you can write a generic singleton factory. The
last advantage is that a method reference can be a supplier.
For example, Elvis::instance is a supplier.
Unless any advantages are relevant, you should use the public field approach.
To make a singleton class serializable using one of these two methods, it is not sufficient to add a serializable implementation to its declaration.
To maintain the singleton guarantee, you must declare all instance fields transient and provide a readResolve method.
Otherwise, every time a serialized instance is deserialized, a new instance will be created. Importantly, in our example, it will lead to false witnesses by Elvis [ spurious sightings]
To prevent this from happening, add this readResolve method to the Elvis class:
// readResolve method to preserve singleton property
private Object readResolve() {
// Return the one true Elvis and let the garbage collector
// take care of the Elvis impersonator.
return INSTANCE;
}
This method is similar to the public field method, but it is more streamlined, provides a serialization mechanism for free, and provides an iron guarantee that even in the face of complex serialization or reflection attacks, it can prevent multiple instantiations. This approach may feel a bit unnatural, but a single element enumeration is usually the best way to implement a singleton. Please note that if the singleton must extend a superclass other than Enum, you cannot use this method (although Enum can be declared to implement the interface)
The third method
The third method to implement a singleton is to declare a single-element [single-element] enumeration:
// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
original
Since the author did not understand this section, the contents of the notes are left in the original text
Item 3: Enforce the singleton property with a private constructor or an enum type
A singleton is simply a class that is instantiated exactly once [Gamma95]. Singletons typically represent either a stateless object such as a function (Item 24) or a system component that is intrinsically unique. Making a class a singleton can make it difficult to test its clients because it’s impossible to substitute a mock implementation for a singleton unless it implements an interface that serves as its type.
There are two common ways to implement singletons. Both are based on keeping the constructor private and exporting a public static member to provide access to the sole instance. In one approach, the member is a final field:
// Singleton with public final field
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public void leaveTheBuilding() { ... }
}
The private constructor is called only once, to initialize the public static final field Elvis.INSTANCE. The lack of a public or protected constructor guarantees a “monoelvistic” universe: exactly one Elvis instance will exist once the Elvis class is initialized—no more, no less. Nothing that a client does can change this, with one caveat: a privileged client can invoke the private constructor reflectively (Item 65) with the aid of the AccessibleObject.setAccessible method. If you need to defend against this attack, modify the constructor to make it throw an exception if it’s asked to create a second instance.
In the second approach to implementing singletons, the public member is a static factory method:
// Singleton with static factory
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() { ... }
}
All calls to Elvis.getInstance return the same object reference, and no other Elvis instance will ever be created (with the same caveat mentioned earlier).
The main advantage of the public field approach is that the API makes it clear that the class is a singleton: the public static field is final, so it will always contain the same object reference. The second advantage is that it’s simpler.
One advantage of the static factory approach is that it gives you the flexibility to change your mind about whether the class is a singleton without changing its API. The factory method returns the sole instance, but it could be modified to return, say, a separate instance for each thread that invokes it. A second advantage is that you can write a generic singleton factory if your application requires it (Item 30). A final advantage of using a static factory is that a method reference can be used as a supplier, for example Elvis::instance is a Supplier<Elvis. Unless one of these advantages is relevant, the public field approach is preferable.
To make a singleton class that uses either of these approaches serializable (Chapter 12), it is not sufficient merely to add implements Serializable to its declaration. To maintain the singleton guarantee, declare all instance fields transient and provide a readResolve method (Item 89). Otherwise, each time a serialized instance is deserialized, a new instance will be created, leading, in the case of our example, to spurious Elvis sightings. To prevent this from happening, add this readResolve method to the Elvis class:
// readResolve method to preserve singleton property
private Object readResolve() {
// Return the one true Elvis and let the garbage collector
// take care of the Elvis impersonator.
return INSTANCE;
}
A third way to implement a singleton is to declare a single-element enum:
// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
This approach is similar to the public field approach, but it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. This approach may feel a bit unnatural, but a single-element enum type is often the best way to implement a singleton. Note that you can’t use this approach if your singleton must extend a superclass other than Enum (though you can declare an enum to implement interfaces).