单例模式的使用场景：
产生某对象会消耗过多的资源，为避免频繁地创建与销毁对象对资源的浪费。如：
对数据库的操作、访问 IO、线程池、网络请求等。某种类型的对象应该有且只有一个。如果制造出多个这样的实例，可能导致：程序行为异常、资源使用过量、结果不一致等问题。
单例模式的几种写法
- 饿汉，线程安全
public class Singleton {
public static Singleton instance = new Singleton();
private Singleton (){}
}
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}
public class Singleton {
private static Singleton instance = null;
sttaic {
instance = new Singleton();
}
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}
这三种方式没什么差别，都依赖 JVM 在类装载时就完成唯一对象的实例化，基于类加载的机制，它们天生就是线程安全的，在急切初始化的方案下都是可行的。
- 懒汉，线程安全
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
这种写法能够在多线程中很好的工作，而且看起来它也具备很好的lazy loading，但是，效率很低，只有new对象的是时候需要同步，对象创建好了后再取对象的时候是不需要同步的。
所以我们可以将它改进为另一种形式，被称为“双重检查锁定的方式”
public class Singleton {
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getSingleton() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
这种方法的“双重检查”体现在进行了两次 if (singleton == null) 的检查，这样既同步代码块保证了线程安全，同时实例化的代码也只会执行一次，实例化后同步操作不会再被执行，从而效率提升很多
双重检查锁定存在的问题是，在操作指令重排序的情况下，可能会导致对象不唯一 ，所以要在定义单例时加上 volatile 关键字修饰，保证执行的顺序，就可以使单例起效。
- 静态内部类
public class Singleton {
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
private Singleton (){}
public static final Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，这种方式的 Singleton 类被装载时，只要 SingletonHolder 类还没有被主动使用，instance 就不会被初始化。只有在显式调用 getInstance() 方法时，才会装载 SingletonHolder 类，实例化对象，实现了延迟加载。
“静态内部类”方式与“双重检查锁定”方式相比的优势在于“双重检查锁定” 方式在 JDK 版本低于 1.5 时多线程环境下可能会失效，而“静态内部类”则不受JDK版本的限制。
- 枚举
public enum Singleton {
INSTANCE;
public void dosomething() {
}
}
这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。保证了在任何情况（包括反序列化、反射、克隆）下都是一个单例，不过由于枚举是 JDK 1.5 才加入的特性，所以同“双重检查锁定” 方式一样，它对 JDK 的版本也有要求
- 登记式单例——使用 Map 容器来管理单例模式
public class SingletonManager {
private static Map<String, Object> objMap = new HashMap()<String, Object>;
public static void registService(String key, Object instance) {
if(!objMap.containsKey(key))
objMap.put(key, instance);
}
public static Object getService(String key) {
return objMap.getKey();
}
}
在程序的初始，我们将一组单例类型注入到一个统一的管理类中来维护，即将这些实例存放在一个 Map 登记薄中，在使用时则根据 key 来获取对象对应类型的单例对象。对于已经登记过的实例，从 Map 直接返回实例；对于没有登记的，则先登记再返回。从而在对用户隐藏具体实现、降低代码耦合度的同时，也降低了用户的使用成本
需要注意的对单例模式的破坏
- 如果Singleton实现了java.io.Serializable接口，那么这个类的实例就可能被序列化和复原。要避免单例对象在反序列化时重新生成对象，则在 implements Serializable 的同时应该实现 readResolve() 方法，并在其中保证反序列化的时候获得原来的对象：
public class Singleton implements java.io.Serializable {
public static Singleton INSTANCE = new Singleton();
protected Singleton() {
}
private Object readResolve() {
return INSTANCE;
}
}
- 使用反射调利用私有构造器也可以破坏单例，要防止此情况发生，可以在私有的构造器中加一个判断，需要创建的对象不存在就创建；存在则说明是第二次调用，抛出 RuntimeException 提示。修改私有构造函数代码如下：
public class Singleton {
...
private Singleton() {
if(instance != null)
throw new RuntimeException("不能创建多个Singleton对象");
}
...
}
- 通过克隆来创建一个新对象，单例模式就失效了。单例模式的类是不可以实现 Cloneable 接口的，这与 Singleton 模式的初衷相违背。那要如何阻止使用 clone() 方法创建单例实例的另一个实例？可以 override 它的 clone() 方法，使其抛出异常。（也许你想问既然知道了某个类是单例且单例不应该实现 Cloneable 接口，那不实现该接口不就可以了吗？事实上尽管很少见，但有时候单例类可以继承自其它类，如果其父类实现了 clone() 方法的话，就必须在我们的单例类中复写 clone() 方法来阻止对单例的破坏。）
@Override
public class Singleton implements Cloneable {
...
proteced Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
...
}
- 不同的类加载器可以加载同一个类。所以当一个工程下面存在不止一个类加载器时，整个程序中同一个类就可能被加载多次，如果这是个单例类就会产生多个单例并存失效的现象。因此当程序有多个类加载器又需要实现单例模式，就须自行指定类加载器，并要指定同一个类加载器
private static Class getClass(String classname) throws ClassNotFoundException {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
if(classLoader == null)
classLoader = Singleton.class.getClassLoader();
return (classLoader.loadClass(classname));
}
}
