设计模式-单例模式
概述：
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
特点：
- 单例类确保自己只有一个实例。
- 单例类必须自己创建自己的实例。
- 单例类必须为其他对象提供唯一的实例。
实现方式：
分两种形式：懒汉单例类和饿汉单例类
懒汉式单例类：它在需要对象的时候，才判断是否已有对象，如果没有就立即创建一个对象，然后返回，如果已有对象就不再创建，立即返回
饿汉单例类：它在类加载的时候就立即创建对象
// 懒汉式
public class Singleton {
private Singleton(){};
private static Singleton instance = null;
// 在需要的时候才判断对象是否为null
public static synchronized Singleton getInstance() {
if (instance == null)
instance = new Singleton();
return instance;
}
}// 饿汉式
public class Singleton {
private Singleton() {};
private static Singleton instance = new Singleton();
// 在类加载的时候就创建了对象
public static Singleton getInstance() {
return instance;
}
}调用： Singleton.getInstance();懒汉模式和饿汉模式的优缺点：
懒汉模式：它的特点是运行时获得对象的速度比较慢，但加载类的时候比较快。它在整个应用的生命周期只有一部分时间在占用资源。
饿汉模式：它的特点是加载类的时候比较慢，但运行时获得对象的速度比较快。它从加载到应用结束会一直占用资源。
比较：这两种模式对于初始化较快，占用资源少的轻量级对象来说，没有多大的性能差异，选择懒汉式还是饿汉式都没有问题。但是对于初始化慢，占用资源多的重量级对象来说，就会有比较明显的差别了。所以，对重量级对象应用饿汉模式，类加载时速度慢，但运行时速度快；懒汉模式则与之相反，类加载时速度快，但运行时第一次获得对象的速度慢。
从用户体验的角度来说，我们应该首选饿汉模式。我们愿意等待某个程序花较长的时间初始化，却不喜欢在程序运行时等待太久，给人一种反应迟钝的感觉，所以对于有重量级对象参与的单例模式，我们推荐使用饿汉模式。
而对于初始化较快的轻量级对象来说，选用哪种方法都可以。如果一个应用中使用了大量单例模式，我们就应该权衡两种方法了。轻量级对象的单例采用懒汉模式，减轻加载时的负担，缩短加载时间，提高加载效率；同时由于是轻量级对象，把这些对象的创建放在使用时进行，实际就是把创建单例对象所消耗的时间分摊到整个应用中去了，对于整个应用的运行效率没有太大影响。
模式总结：
- 优点
- 在内存中只有一个对象，节省内存空间。
- 避免频繁的创建销毁对象，可以提高性能。
- 避免对共享资源的多重占用。
- 可以全局访问。
- 注意事项
- 只能使用单例类提供的方法得到单例对象，不要使用反射，否则将会实例化一个新对象。
- 不要做断开单例类对象与类中静态引用的危险操作。
- 多线程使用单例使用共享资源时，注意线程安全问题。
- 适用场景
- 需要频繁实例化然后销毁的对象。
- 创建对象时耗时过多或者耗资源过多，但又经常用到的对象。
- 有状态的工具类对象。
- 频繁访问数据库或文件的对象。
- 以及其他我没用过的所有要求只有一个对象的场景。
单例模式争议
单例模式的对象长时间不用会被jvm垃圾收集器收集吗？
不少资料中说：如果一个单例对象在内存中长久不用，会被jvm认为是一个垃圾，在执行垃圾收集的时候会被清理掉。对此这个说法，观点是：在hotspot虚拟机1.6版本中，除非人为地断开单例中静态引用到单例对象的联接，否则jvm垃圾收集器是不会回收单例对象的。
单例模式讨论篇：单例模式与垃圾收集在一个jvm中会出现多个单例吗?
在分布式系统、多个类加载器、以及序列化的的情况下，会产生多个单例，这一点是无庸置疑的。那么在同一个jvm中，会不会产生单例呢？使用单例提供的getInstance()方法只能得到同一个单例，除非是使用反射方式，将会得到新的单例。
Class c = Class.forName(Singleton.class.getName());
Constructor ct = c.getDeclaredConstructor();
ct.setAccessible(true);这样，每次运行都会产生新的单例对象。所以运用单例模式时，一定注意不要使用反射产生新的单例对象。
懒汉式单例线程安全吗
主要是网上的一些说法，懒汉式的单例模式是线程不安全的，即使是在实例化对象的方法上加synchronized关键字，也依然是危险的，但是经过编码测试，发现加synchronized关键字修饰后，虽然对性能有部分影响，但是却是线程安全的，并不会产生实例化多个对象的情况。
单例模式只有饿汉式和懒汉式两种吗?
饿汉式单例和懒汉式单例只是两种比较主流和常用的单例模式方法，从理论上讲，任何可以实现一个类只有一个实例的设计模式，都可以称为单例模式。
单例类可以被继承吗?
饿汉式单例和懒汉式单例由于构造方法是private的，所以他们都是不可继承的，但是其他很多单例模式是可以继承的，例如登记式单例。
饿汉式单例好还是懒汉式单例好?
在java中，饿汉式单例要优于懒汉式单例。C++中则一般使用懒汉式单例。
如果单例由不同的类装载器装入，那便有可能存在多个单例类的实例。假定不是远端存取，例如一些servlet容器对每个servlet使用完全不同的类装载器，这样的话如果有两个servlet访问一个单例类，它们就都会有各自的实例。
public class Singleton{
private static Class getClass(String classname) throws ClassNotFoundException {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
if (classLoader == null)
classLoader = Singleton.class.getClassLoader();
return (classLoader.loadClass(classname));
}
}8.如果Singleton实现了java.io.Serializable接口，那么这个类的实例就可能被序列化和复原。不管怎样，如果你序列化一个单例类的对象，接下来复原多个那个对象，那你就会有多个单例类的实例。
public class Singleton implements java.io.Serializable {
protected Singleton() {}
public static Singleton INSTANCE = new Singleton();
private Object readResolve() {
return INSTANCE;
}
}什么是线程安全：
线程安全就是说多线程访问同一代码，不会产生不确定的结果。编写线程安全的代码是低依靠线程同步。
线程安全一般都涉及到synchronized 就是一段代码同时只能有一个线程来操作 不然中间过程可能会产生不可预制的结果
优化(线程安全)与其他方式：
/**
* 第一种（懒汉，线程不安全）：
*/
public class SingletonA {
private SingletonA() {};
private static SingletonA instance = null;
public static SingletonA getInstance() {
if (instance == null)
instance = new SingletonA();
return instance;
}
}
Feature（特征）：延时加载、线程不安全、多线程下不能正常工作，需要额外的工作(Serializable、transient、readResolve())来实现序列化。
/**
* 第二种（懒汉，线程安全）
*/
public class SingletonB {
private SingletonB() {}
private static SingletonB instance;
public static synchronized SingletonB getInstance() {
if (instance == null) {
instance = new SingletonB();
}
return instance;
}
}
这种写法能够在多线程中很好的工作，而且看起来它也具备很好的lazy loading，但是，遗憾的是，效率很低，99%情况下不需要同步。
Feature（特征）：线程安全、效率比较低，因为需要线程同步的时候比较少。
/**
* 第三种（饿汉）(推荐)
*/
public class SingletonC {
private SingletonC() {}
private static SingletonC instance = new SingletonC();
public static SingletonC getInstance() {
return instance;
}
}这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用getInstance方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance显然没有达到lazy loading的效果。
Feature（特征）：可以通过反射机制攻击，线程安全[多个类加载器除外]。
/**
* 第四种（饿汉，变种）
*/
public class SingletonD {
private SingletonD() {}
private static SingletonD instance = null;
static {
instance = new SingletonD();
}
public static SingletonD getInstance() {
return instance;
}
}表面上看起来差别挺大，其实跟第三种方式差不多，都是在类初始化即实例化instance。
/**
* 第五种（静态内部类）(推荐)
*/
public class SingletonE {
private SingletonE() {}
private static class SingletonHolder {
private static final SingletonE INSTANCE = new SingletonE();
}
public static final SingletonE getInstance() {
return SingletonHolder.INSTANCE;
}
}这种方式同样利用了classloder的机制来保证初始化instance时只有一个线程，它跟第三种和第四种方式不同的是（很细微的差别）：第三种和第四种方式是只要Singleton类被装载了，那么instance就会被实例化（没有达到lazy loading效果），而这种方式是Singleton类被装载了，instance不一定被初始化。因为SingletonHolder类没有被主动使用，只有显示通过调用getInstance方法时，才会显示装载SingletonHolder类，从而实例化instance。想象一下，如果实例化instance很消耗资源，我想让他延迟加载，另外一方面，我不希望在Singleton类加载时就实例化，因为我不能确保Singleton类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化instance显然是不合适的。这个时候，这种方式相比第三和第四种方式就显得很合理。
Feature（特征）：线程安全、延迟加载。
/**
* 第六种（枚举）(极推荐)
*/
public enum SingletonF {
INSTANCE;
// 需要调用的方法
public void invokingMethod() {
}
// 调用:SingletonF.INSTANCE.invokingMethod();
}这种方式是Effective Java作者Josh Bloch 提倡的方式，它不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象，可谓是很坚强的壁垒啊，不过，个人认为由于1.5中才加入enum特性，用这种方式写不免让人感觉生疏，在实际工作中，我也很少看见有人这么写过。
Feature（特征）：写法简单，从Java1.5开始支持，无偿提供序列化机制，绝对防止多次实例化，即使在面对复杂的序列化或者反射攻击的时候。
/**
* 第七种（双重校验锁）(不推荐)
*/
public class SingletonG {
private SingletonG() {}
private volatile static SingletonG instance;
public static SingletonG getSingleton() {
if (instance == null) {
synchronized (SingletonG.class) {
if (instance == null) {
instance = new SingletonG();
}
}
}
return instance;
}
}这个是第二种方式的升级版，俗称双重检查锁定
第二种方存在的问题：只有第一次执行此方法时，才真正需要同步。换句话说，一旦设置好instance 变量，就不再需要同步这个方法了。之后每次调用这个方法，同步都是一种浪费。
用“双重检查加锁”，在getSingleton()中减少使用同步
首先检查实例是否已经创建，如果尚未创建，才进行同步。这样一来，只有第一次会同步，这正是我们想要的。
volatile关键字确保：当instance 变量被初始化成Singleton实例时，多个线程正确地instance 变量。如果性能是你关心的重点，那么这个做法可以帮你大大地减少getSingleton()的时间耗费。
总结，五类：恶汉、懒汉、双重校验锁、静态内部类、枚举。
恶汉：因为加载类的时候就创建实例，所以线程安全(多个ClassLoader存在时例外)。缺点是不能延时加载。
懒汉：需要加锁才能实现多线程同步，但是效率会降低。优点是延时加载。
双重校验锁：麻烦，在当前Java内存模型中不一定都管用，某些平台和编译器甚至是错误的，因为instance = new MaYun()这种代码在不同编译器上的行为和实现方式不可预知。
静态内部类：延迟加载，减少内存开销。因为用到的时候才加载，避免了静态field在单例类加载时即进入到堆内存的permanent代而永远得不到回收的缺点(大多数垃圾回收算法是这样)。
枚举：很好，不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。但是失去了类的一些特性，没有延迟加载，用的人也太少了。
以后多推广推广单元素枚举这种更好的单例实现方式。在项目中的代码开始修改实施
选择：
第一种和第二种方式一般不用。
第三种和第五种方式，简单易懂，而且在JVM层实现了线程安全（如果不是多个类加载器环境），一般的情况下，会使用第三种方式，只有在要明确实现lazy loading效果时才会使用第五种方式。
另外，如果涉及到反序列化创建对象时，试着使用枚举的方式来实现单例。
如有其他特殊的需求，可能会使用第七种方式，毕竟，JDK1.5已经没有双重检查锁定的问题了。
| 特征词 | JDK版本要求 | 是否Lazy Initialization | 是否多线程安全 | 实现难度 | 说明 | |
|---|---|---|---|---|---|---|
| 第一种 | classic(懒汉如上第一种) | 无 | 是 | 否 | 易 | 不要求线程安全 |
| 第二种 | use “synchronize”(懒汉+同步如上第二种) keyword | 无 | 是 | 是 | 易 | getInstance()的性能对应用程序不是很关键(比如该方法使用不太频繁) |
| 第三种 | eagerly create（恶汉） | 无 | 否 | 是 | 易 | 创建该实例负担不太繁重； 该实例被用到的可能性较大 |
| 第四种 | 双检锁 (double-checked locking) | 1.5 | 是 | 是 | 较复杂 | getInstance()的性能对应用程序很关键。 |
| 第五种 | Class holder lazy initialization（静态内部类） | 无 | 是 | 是 | 一般 | |
| 第六种 | Enum singleton（枚举） | 1.5 | 否 | 是 | 易 | 自动支持序列化；不能通过reflection attack来调用私有构造方法 |
枚举：虽然这种方式还没有被广泛采用，但这是实现Singleton的最佳方法（更简洁，自动支持序列化机制，绝对防止多次实例化）。
代码下载
单例模式SingletonMode - 10KB
参考：
- 单例模式(百度百科)
- 23种设计模式（1）：单例模式
- 单例模式的七种写法
- http://www.cnblogs.com/wangjq/archive/2012/06/28/2561250.html
- http://www.cnblogs.com/ykt/archive/2011/11/24/2261251.html