创建型模式之单例模式

创建型模式之单例模式

​ 所谓类的单例设计模式，就是采取一定的方法保证在整个的软件系统中，对某个类 只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法(静态方法)。

比如Hibernate的SessionFactory，它充当数据存储源的代理，并负责创建Session 对象。SessionFactory并不是轻量级的，一般情况下，一个项目通常只需要一个 SessionFactory就够，这是就会使用到单例模式。
也就是说，为了节约系统资源，有时需要确保系统中某个类只有唯一一个实例，当这个唯一实例创建成功之后，我们无法再创建一个同类型的其他对象，所有的操作都只能基于这个唯一实例。为了确保对象的唯一性，我们可以通过单例模式来实现，这就是单例模式的动机所在。

单例模式有八种实现方式：

1. 饿汉式(静态常量)

2. 饿汉式（静态代码块）

3. 懒汉式(线程不安全)

4. 懒汉式(线程安全，同步方法)

5. 懒汉式(线程安全，同步代码块)

6. 双重检查

7. 静态内部类

8. 枚举

1) 饿汉式(利用静态常量完成)

单例肯定是只有一个实例，那如何利用静态常量来完成单例模式呢？
思路大致如下，静态常量在类加载的时候只会被加载一次，我们可以将我们要声明为单例的类型声明为一个类的静态常量，让其在类的初始化阶段进行创建；
并且对外提供一个获取到该对象的静态公共方法；
同时需要注意将该类的构造器私有化防止该类的对象在外部被new创建对象破坏单例；
注意静态常量是用final static 关键字进行修饰的；

这种方式避免了线程同步问题，因为是利用静态常量进行初始化的，在加载之后其内部属性就不会发生变化，从而避免了线程安全问题。

步骤如下：

1、 让类的构造器私有化 (防止该类的对象在外部被new创建对象 )

2、在类的内部创建该类的一个实例对象，并用final static 关键字进行修饰
3、类向外暴露一个静态的公共类方法，如getInstance方法返回第二步创建的对象，以供外部通过该方法获取该类的单例对象。

如下图所示

优缺点：
1) 优点：这种写法比较简单，它在类装载的时候就完成实例化。避免了线程同步问题。
2) 缺点：在类装载的时候就完成实例化，没有达到Lazy Loading懒加载的效果。如果从始至终从未使用过这个实例，而它又在类装载的时候就完成了实例化，则会造成内存的浪费
3) 这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中大多数都是调用getInstance方法， 但是导致类装载的原因有很多种，因此不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance就没有达到lazy loading的效果
4) 结论：这种单例模式在你确定你一定会用到该对象实例的时候可用，但不确定用不用的时候就有可能造成内存浪费。

2) 饿汉式（静态代码块）

优缺点说明：

1. 这种方式和上面静态变量的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。
2. 结论：这种单例模式可用，但是可能造成内存浪费

3) 懒汉式(线程不安全)

在使用的时候才会进行创建对象，而不是像饿汉式那样在类装载的时候创建对象

优缺点说明：

1. 起到了Lazy Loading的效果**（用到的时候才创建）**，但是只能在单线程下使用。
2. 如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，**这时便可能会产生多个实例。**所以在多线程环境下不可使用这种方式
3. 结论：在实际开发中，不要使用这种方式，可能会破坏单例模式。

4） 懒汉式(线程安全，同步方法)

​ 既然上面的懒汉式方式中在执行getInstance方法的时候可能会出现安全问题，那我们将该方法变成同步方法即可，这样就不会出现线程安全问题了。

1. 解决了线程不安全问题
2. **缺点是效率太低了，每个线程在想获得类的实例时执行getInstance()方法都要进行同步判断，是方法级别的阻塞。**而这个方法其实只需要执行一次实例化代码就够了，后面的想获得该类实例，直接return就行了。
3. 结论：在实际开发中，不推荐使用这种方式

5）、 懒汉式(线程安全，同步代码块)

优缺点：

1. 这种方式，本意是想对第四种实现方式的改进，因为前面同步方法效率太低，改为同步产生实例化的的代码块
2. 但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一致，假如一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句并且创建了一个新对象再退出；然后未来得及执行的线程继续执行且创建新对象，这时便会产生多个实例
3. 结论：在实际开发中，不能使用这种方式

6）、懒汉式双重检查（推荐）

既然前面的几种方式不是存在效率问题就是存在安全问题，那么有没有一种既能解决效率问题又解决安全问题呢？

public class SingletonTest06 {

	public static void main(String[] args) {
		System.out.println("双重检查");
		Singleton instance = Singleton.getInstance();
		Singleton instance2 = Singleton.getInstance();
		System.out.println(instance == instance2); // true
		System.out.println("instance.hashCode=" + instance.hashCode());
		System.out.println("instance2.hashCode=" + instance2.hashCode());
	}
}
// 懒汉式(线程安全，同步方法)
class Singleton {
	private static   Singleton instance;
	private Singleton() {}
	//提供一个静态的公有方法，加入双重检查代码，解决线程安全问题, 同时解决懒加载问题
	//同时保证了效率, 推荐使用
	public static synchronized Singleton getInstance() {
		if(instance == null) {
			synchronized (Singleton.class) {
				if(instance == null) {
					instance = new Singleton();
				}
			}
		}
		return instance;
	}
}

在getInstance方法中加入了两重的 if(instance == null)判断，假设此时a、b两个线程都来到了第一重的 if(instance == null)判断，且a线程比b线程先进入第一重if(instance == null)判断中的 synchronized (Singleton.class) 处，那么此时b就被挡在了synchronized (Singleton.class) 外面。当线程a来到第二重if(instance == null) 判断的时候，由于还没有创建该类的单例实例对象，所以此时会new一个对象。然后a线程执行return instance;语句。之后b线程再进入第二重的if判断，但是由于此时的单例对象instance已经被创建了，所以此时b线程并不会执行第二重if判断里面的内容而又再次创建对象。**这样就解决了线程的安全问题。**在这之后假如又有线程d\e\f来到第一重if判断处，由于此时的单例对象并不为空，故它们都不能进入第一重if判断而直接执行return instance;语句。这样就保证了效率的问题。

但是 ！但是！但是！上面的if(INSTANCE == null)判断代码没有在同步代码块synchronized中， 不能享有synchronized保证的原子性、可见性、以及有序性。所以可能会导致 指令重排 ，也就是说 在多线程环境下，上面的代码还是有问题的。
因为从字节码的角度来看, 这一步INSTANCE = new Singleton();操作不是一个原子操作, 它分为将对象赋值以及执行构造方法两个指令, 所以执行INSTANCE = new Singleton();操作就有可能就会发生指令重排的问题，导致将对象赋值以及执行构造方法两个指令的执行顺序不确定，如果是赋值操作先执行，在 t1线程 还未完全将构造方法执行完毕的时候t2判断INSTANCE 不为null，那么 t2 拿到的是将是一个未初始化完毕的单例 。（使用对象的时候构造方法还没有执行！！！）
所以这里我们需要使对 INSTANCE 使用 volatile 修饰即可禁用指令重排。(读写屏障原理)
注意在 JDK 5 以上的版本的 volatile 才会真正有效

public final class Singleton {
    private Singleton() { }
    private static volatile Singleton INSTANCE = null;
    public static Singleton getInstance() {
        // 实例没创建，才会进入内部的 synchronized代码块
        if (INSTANCE == null) {
            synchronized (Singleton.class) { // t2
                // 也许有其它线程已经创建实例，所以再判断一次
                if (INSTANCE == null) { // t1
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

优缺点说明：

1. Double-Check概念是多线程开发中常使用到的，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。
   2) 这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象，也避免的反复进行方法同步.
2. 线程安全；延迟加载；效率较高
3. 结论：在实际开发中，推荐使用这种单例设计模式

7）、 懒汉式静态内部类 （推荐使用）

​ 静态内部类的一个特点是，外部的类被装载的时候静态的内部类是不会被加载的；即外部类Singleon被装载的时候静态内部类SingleonInstance是不会被装载的。

​ 另一个特点是当外面去调用外部类Singleon的getInstance方法的时候用到静态内部类SingleonInstance的INSTANCE变量的时候就会导致静态内部类SingleonInstance被装载且只会被装载一次，又是线程安全的。

​ 所以静态内部类是一种非常好的实现单例模式的方法

优缺点说明：

1. 这种方式采用了类装载的机制来保证初始化实例时只有一个线程能够初始化成功。
2. 静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonInstance类，从而完成Singleton的实例化。
3. 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。
4. 优点：避免了线程不安全，利用静态内部类特点实现延迟加载，效率高
5. 结论：推荐使用。

8）、枚举

利用枚举同样可以轻松的实现单例模式

public class SingletonTest08 {
   public static void main(String[] args) {
   	Singleton instance = Singleton.INSTANCE;
   	Singleton instance2 = Singleton.INSTANCE;
   	System.out.println(instance == instance2);
   	
   	System.out.println(instance.hashCode());
   	System.out.println(instance2.hashCode());
   	
   	instance.sayOK();
   }
}

//使用枚举，可以实现单例, 推荐
enum Singleton {
   INSTANCE; //只有一个属性，保证单例
   public void sayOK() {
   	System.out.println("ok~");
   }
}

补充：

优缺点说明：

1. 借助JDK1.5中添加的枚举来实现单例模式，不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象以及反射修改构造器的私有性破坏单例。