文章内容来源于Joshua Bloch - Effective Java (3rd) - 2018.chm一书
BTW：关于文章中出现serializable/serialized 与deserialized的概念，序列化与反序列化的概念，参考下面这篇文章
https://blog.csdn.net/qq_27093465/article/details/78544505
第二章
创建和注销对象
Item 3使单例属性具有私有构造函数或枚举类型
Enforce the singleton property with a private constructor or an enum type
简单地，单例是只实例化一次的类。典型地，单例表示要么是无状态的对象例如函数要么就是本质上唯一的系统组件。
有两种方法实现单例（模式），两者都是基于保持构造函数私有和导出一个公共静态成员以提供对唯一实例的访问。
成员是final字段的方法：
// Singleton with public final field
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { ... }
public void leaveTheBuilding() { ... }
}
私有构造函数只被调用一次，以初始化公共静态final字段Elvis.INSTANCE实例。
缺少public或protected的构造函数保证了一个“单精灵”的宇宙：一旦Elvis类被初始化，就只存在一个Elvis实例，不多不少
client客户端无法改变这个
但有一点需要特别注意：一个特权客户端可以借助AccessibleObject.setAccessible方法反射地调用私有构造函数。
如果需要防御此攻击，可以修改构造函数，使其在被要求创建第二个实例时抛出异常。
public成员是静态工厂方法：
// 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() { ... }
}
所有Elvis.getInstance的调用返回相同对象的引用，并且不会创建任何其他Elvis实例（和前面提到的特别说明一样）
优点
public 字段的方法优点：
主要是API使class很清晰是单例：public static字段是final，因此它总是包含相同的对象引用
第二个优点是它更简单
静态工厂方法的优点：
一是它使您能够灵活地改变你对类是否是单例的思想，而不必更改其API；工厂方法返回单独的实例，但是它会被修改去返回，例如，调用它的每个线程的单独实例
第二个优点是如果应用程序需要，你可以编写通用的单例工厂
最后一个优点是一个方法引用可以是supplier
例如 Elvis::instance 是一个 Supplier
除非有任何优势相关了，否则就应该使用public 字段的方法。
要使单例类使用这两种方法之一可序列化，向其声明中添加可序列化的实现是不足够充分的。
要维护singleton保证，须声明所有实例字段transient并提供一个readResolve方法
否则，每次反序列化一个序列化实例时，都会创建一个新实例，重要的，在我们的例子中，会导致Elvis虚假目击[spurious sightings]
要防止发生这种情况，请将此readResolve方法添加到Elvis类：
// 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;
}
这种方法类似于公共字段方法，但它更精简，免费提供序列化机制，并提供了一个铁质的保证，即使在面对复杂的序列化或反射攻击时，也可以防止多次实例化。这种方法可能感觉有点不自然，但单个元素枚举类型通常是实现单例的最佳方式。请注意，如果单例必须扩展除Enum以外的超类，则不能使用此方法（尽管可以声明Enum来实现接口）
第三个方法
第三个方法实现单例是声明一个单元素[single-element]枚举：
// Enum singleton - the preferred approach
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
原文
由于笔者这一小节没有看懂，所以笔记内容留下原文
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).