单例模式的实现
单例模式的实现一般来说有2种方式：懒汉式（延迟加载）、饿汉式（非延迟加载）。
1. 饿汉式（非延迟加载）
/**
* Created by liuruijie on 2017/2/13.
* 饿汉式（非延迟加载）单例类
*/
public class HungrySingleton {
private static HungrySingleton hungSingleton = new HungrySingleton();
public static HungrySingleton getInstance() {
return hungSingleton;
}
private HungrySingleton(){}
}
以上代码，静态变量在类被加载的时候初始化，之后就不会再执行hungSingleton = new HungrySingleton();语句，所以保证了单例。
还有一种写法，通过枚举来实现：
/**
* Created by liuruijie on 2017/2/13.
* 饿汉式（非延迟加载）单例类 -- 枚举
*/
public enum LazySingleton {
SINGLETON_INSTANCE;
public static LazySingleton getInstance() {
return SINGLETON_INSTANCE;
}
}
就这么简单。
饿汉式（非延迟加载）这种方式相对简单，也不会有什么安全问题，但是它的最大弊端显而易见，就是唯一的实例在这个类被加载时就被创建了，即还未使用实例，资源就已经被提前分配了。所以一般来说，为了提高性能，使用更多的还是懒汉式（延迟加载）。
2. 懒汉式（延迟加载）
这个方式水就很深了，它的实现有好几种，现在由浅入深一个一个看。
1） 最简单的方式
/**
* Created by liuruijie on 2017/2/13.
* 懒汉式（延迟加载）单例类 -- 0
*/
public class LazySingleton {
private static LazySingleton singleton;
public static LazySingleton getInstance() {
//获取实例之前检查是否为空
if(singleton == null){ //a
//第一次获取的时候总是为空的
//初始化实例
singleton = new LazySingleton(); //b
}
return singleton;
}
private LazySingleton(){}
}
先不说这个写法的问题，可以看到这个写法表明了懒汉式（延迟加载）的大概思路。在getInstance()方法种首先检查唯一的实例是不是还没被初始化，如果没有就将其初始化后再返回，已经初始化了就直接返回这个实例。
再来说这个写法的问题，老生常谈的线程安全问题。这个写法完全没有考虑多线程的情况。
假设有线程1，线程2两个线程。线程1执行了a之后，判断实例是为空的；之后切换线程2，线程2当然也会执行a，并且由于此时实例还未被初始化，所以，线程2会通过判断，执行b，初始化实例；切回线程1，线程1继续执行b，又将实例初始化了一次，此时对象实例已不唯一，破坏了单例模式。
2） 加锁的方式
线程并发出现的问题大多可以用加锁，也就是同步的方式解决，于是为getInstance方法加上synchronized关键字。
/**
* Created by liuruijie on 2017/2/13.
* 懒汉式（延迟加载）单例类 -- 1
*/
public class LazySingleton {
private static LazySingleton singleton;
public static synchronized LazySingleton getInstance() {
//获取实例之前检查是否为空
if(singleton == null){ //a
//第一次获取的时候总是为空的
//初始化实例
singleton = new LazySingleton(); //b
}
return singleton; //c
}
private LazySingleton(){}
}
此时问题是解决了，但是我们都知道加锁同步会对性能产生很大影响，我们应该让在同步块中的语句尽量少。现在来分析一下可以优化的地方，这个方法也就3条语句，a、b、c。从第一种方式种的问题可以看出，主要成因与a和b有关，于是我们应该缩小同步块范围到这两条语句。
/**
* Created by liuruijie on 2017/2/13.
* 懒汉式（延迟加载）单例类 -- 1
*/
public class LazySingleton {
private static LazySingleton singleton;
public static LazySingleton getInstance() {
synchronized(LazySingleton.class){
//获取实例之前检查是否为空
if(singleton == null){ //a
//第一次获取的时候总是为空的
//初始化实例
singleton = new LazySingleton(); //b
}
}
return singleton; //c
}
private LazySingleton(){}
}
这样看似很美妙，解决了线程安全问题，还优化了性能。但是，现在还没有优化彻底。想想看，只有第一次，对象实例还没有初始化的时候，锁才有意义，实例初始化之后，不会再执行语句b了，但是还是要经过synchronized，这是无意义的，所以还能优化。
3）双重检测锁的方式
/**
* Created by liuruijie on 2017/2/13.
* 懒汉式（延迟加载）单例类 -- 2
*/
public class LazySingleton {
private static volatile LazySingleton singleton;
public static LazySingleton getInstance() {
if (singleton==null){ //a
synchronized(LazySingleton.class){ //b
//获取实例之前检查是否为空
if(singleton == null){ //c
//第一次获取的时候总是为空的
//初始化实例
singleton = new LazySingleton(); //d
}
}
}
return singleton; //e
}
private LazySingleton(){}
}
什么叫双重检测锁（Double Checked Locking,DCL），这么高大上的名字，但它其实就是两个if判断语句加一个synchronized锁 -_=。
由于我们希望在初始化实例之后不要经过无意义的同步语句。所以往外面再加一个没有同步的if条件去判断实例是否为空。但是当然也必须保留原来在同步块里面的if语句，因为初衷就是对初始化对象时的判断语句和赋值语句做同步处理。
这样第一次，线程1执行到c后，切换线程2，线程2执行到b会阻塞，线程1执行完同步块中的d后，切换线程2，线程2执行c时，由于实例已经初始化，所以不会去执行d，而直接执行e返回了。并且对象实例初始化之后，每次调用getInstance方法都会在a执行后执行调到e返回，不会再经过synchronized了。
眼睛犀利的朋友可能看到了还有一个地方的不同，那就是静态变量singleton前面多了个volatile关键字去修饰。这是为了解决双重检测锁存在的线程安全问题。
很多人觉得，这样写非常完美，怎么也看不出问题。但是如果不加volatile的确是有问题的，因为java虚拟机会进行指令重排。
volatile关键字
先来说说volatile关键字，它主要有两个作用，他能够保证变量的可见性，并且他能够防止指令重排序，这里主要用到它的第二个作用。
指令重排
什么是指令重排序，结合以上代码
singleton = new LazySingleton();
这只是一条语句，看上去只进行变量初始化一个简单的操作，但是在java虚拟机层面，它是很复杂的，分为很多个操作，需要进行类加载检查，分配内存，初始化对象头信息等等。不过解释这里的问题，只需要将其大致分为三个部分：
（1）分配内存
（2）调用构造函数
（3）赋值
这只是我们所觉得的正常的指令顺序，但是java虚拟机在编译时这些指令很可能变成：
（1）分配内存
（2）赋值
（3）调用构造函数
因为对于单线程来说，这两个指令顺序并没有什么区别，因为赋值和调用构造函数是没有先后关系的，我可以先将对象内存地址赋值给引用然后再去调用构造函数初始化对象的属性，这样得到的结果是一样的。而且单线程的所有语句都是串行的，也就是顺序执行的，能够保证在下一条语句执行的时候，这三个指令都已执行完成。
不过一旦到了多线程的环境中，就存在潜在问题，现在回到代码。
在指令重排之后，当线程1执行了（1）和（2）还未执行（3）的时候，就切到线程2执行，此时线程2在第一个if判断时，对象虽然还不完整，但已经不为空了，所以线程2会跳到return语句，直接返回一个不完整的对象，这样只要线程1还没有执行完初始化操作中的第三条指令，你的程序就会继续使用一个不完整的对象，这样产生的后果肯定是不堪设想的。
而volatile关键字会杜绝关于被修饰变量的指令重排的发生，也就是说始终保持正常的指令顺序，这样保证只要语句singleton = new LazySingleton()没有执行完，singleton变量永远为空。
在加上了volatile关键字后，DCL就能正常工作。
4）ThreadLocal方式
除了加volatile关键字外，要解决DCL的问题，还有一种方式，就是使用ThreadLocal。
/**
* Created by liuruijie on 2017/2/13.
* 懒汉式（延迟加载）单例类 -- 3
*/
public class LazySingleton {
private static ThreadLocal<LazySingleton> threadLocal = new ThreadLocal<>();
private static LazySingleton singleton;
public static LazySingleton getInstance() {
if (threadLocal.get()==null) { //a
synchronized (LazySingleton.class) { //b
//获取实例之前检查是否为空
if (singleton == null) { //c
//第一次获取的时候总是为空的
//初始化实例
singleton = new LazySingleton(); //d
}
}
threadLocal.set(singleton); //e
}
return singleton; //f
}
private LazySingleton(){}
}
什么是ThreadLocal变量，就是只属于当前线程的局部变量，换句话说就是每个线程都会持有一个该threadlocal变量的副本，当不同的线程访问同一个ThreadLocal变量，得到的值可能是不同的，它有两个重要的方法，一个是get，一个是set，对应读和写。
怎么用它来解决DCL的问题呢，思路是这样的：
在volatile方式中，已经分析了问题所在，就是第一层if条件判断时可能会出现不完整同时又不为空的对象实例，于是，将这里的判断条件替换为只属于当前线程的局部变量，因为这个局部变量一开始是为空的，所以无论线程1是否执行完语句d，线程2，线程3，的threadlocal变量都是为空的，第一个if判断条件都会通过，接着就是同步块了，等待线程1执行完语句d，也就是对象实例初始化完成之后，第二层的if判断条件不会满足，接着各个线程分别执行了threadloacal.set，也就是语句e后，其threadlocal变量就不为空了，之后便不会通过第一层的if条件，跳到语句f返回实例。
threadlocal避开了DCL的问题，但是却增大了内存开销，因为threadlocal本质上是用一个hashmap来管理的这些变量，键为线程对象，值为该线程对应的局部变量副本的值。
5）内部类方式
除了使用DCL之外，延迟加载的单例模式还可以通过内部类来实现。
/**
* Created by liuruijie on 2017/2/13.
* 懒汉式（延迟加载）单例类 -- 3
*/
public class LazySingleton {
public static LazySingleton getInstance() {
//直接返回内部类中的实例对象
return LazyHolder.lazySingleton;
}
private LazySingleton(){}
//静态内部类
private static class LazyHolder{
//持有外部类的实例，并初始化
private static LazySingleton lazySingleton = new LazySingleton();
}
}
主要思路是，内部类持有外部类的静态实例，并将其在内部类被加载时就初始化。然后在外部类中的getInstance方法中返回此实例。类似饿汉式，由于内部类只会被加载一次，也就是只会执行一次初始化语句，所以保证了实例的唯一。
而内部类什么时候加载，其实所有的类都是在使用它的时候被加载的，包括内部类。所以内部类不会随着外部类的加载而加载，只有在使用它的时候才会被加载。
使用一个类情况有哪些？
1.调用静态变量
2.调用静态方法
3.创建此类对象
做一个简单的实验就明白了。
/**
* Created by liuruijie on 2017/2/14.
* 内部类与外部类加载时机
*/
public class Out {
static {
System.out.println("外部类被加载");
}
public static void loadOut(){
//这个方法不使用内部类
}
public static void loadIn(){
int a = In.num; //通过调用静态变量来使用内部类
}
private static class In{
static int num;
static {
System.out.println("内部类被加载");
}
}
}
用到的是只要一加载类就会执行的静态代码块来验证。
首先只加载外部类
Out.loadOut();
运行结果：
可以看到只有外部类被加载了，内部类并没有被加载
加载内部类
Out.loadIn();
结果：
结果证明了之前的结论。
其中需要注意的有两点：
（1）这里的内部类必须是静态内部类，原因很简单，这里的单例模式获取对象实例需要用到内部类，而非静态内部类同非静态变量一样是对象级的，必须先有对象实例才能访问，这样就产生了矛盾。
并且只有静态内部类才能够持有静态变量和方法。至于为什么，目前我还没找出好的解释，所以就把它当成一个语法规定吧。
（2）内部类的访问修饰符应该为private或者protected，因为静态内部类在其他类中是可以被访问的，这个虽然不影响单例模式，但是类应该尽量将具体的实现屏蔽起来，这样外部就不会知道这个单例类的实现是采用的内部类的方式了。（个人看法）
小结
对于单例模式，为了提高性能而通常选择懒汉式的实现，但是又带来了许多线程安全问题，能解决这些问题的有3种实现，带volatile的DCL、用threadlocal的DCL、静态内部类。其中最简单的是静态内部类的方式，也最容易理解。但是另外两个方式对于多线程的学习和理解来讲也是很重要的。
单例注册表
上面提到的单例模式虽好，但是都有一点瑕疵，就是不能重用。如果我要将一个类变成单例的，我必须要在这个类上写上面提到的那些代码，过段时间，另一个类也需要写成单例的，我又要写上这些代码。
而单例注册表就是一种可以获得任何类的唯一实例的一个表。只要是同一个单例注册表获取到的同一个类的实例，总是相同的。
先看看使用起来是怎么样的，随便建一个类用来测试：
/**
* Created by liuruijie on 2017/2/13.
* 随便建的一个类
*/
public class Student {
//假装有很多属性和方法
}
获取这个类的单例：
//这是一个单例注册表
BeanFactory beanFactory = BeanFactory.getInstance();
//获取实例1
Student student1 = (Student) beanFactory
.getBean(Student.class.getName());
//获取实例2
Student student2 = (Student) beanFactory
.getBean(Student.class.getName());
//比较获取到的两个实例
System.out.println(student1.hashCode());
System.out.println(student2.hashCode());
看看结果：
两个对象是一样的。
其实这个单例注册表的实现很简单，就是用一个hashmap来维护单例对象。
代码一看便知：
/**
* Created by liuruijie on 2017/2/13.
* 单例注册表
*/
public class BeanFactory {
/**
* 这些是维护此注册表的，
* 因为不是重点
* 所以采用了最简单的方式
* 可以用其他方式
*/
private static BeanFactory beanFactory = new BeanFactory();
private BeanFactory(){
}
public static BeanFactory getInstance() {
return beanFactory;
}
//缓存单例对象的hash表
private final HashMap<String, Object> cacheMap = new HashMap<>();
//通过类名获取其单例对象
public Object getBean(String className) {
Object bean = cacheMap.get(className);
//使用双重检测锁来实现单例
if (bean == null) {
synchronized (this.cacheMap) {
//第二次检测
bean = cacheMap.get(className);
if (bean == null) {
try {
bean = Class.forName(className).newInstance();
} catch (InstantiationException e) {
System.err.println("could not instance an object of type:" + className);
e.printStackTrace();
} catch (IllegalAccessException e) {
System.err.println("could not access class " + className);
e.printStackTrace();
} catch (ClassNotFoundException e) {
System.err.println("could not find class " + className);
e.printStackTrace();
}
}
cacheMap.put(className, bean);
}
}
return bean;
}
}
注意这里的cacheMap是没有加volatile关键字的，为什么，因为在bean = Class.forName(className).newInstance();这句没执行完的时候，cacheMap中不可能有不完整的对象，只有在后面的cacheMap.put(className, bean);执行之后，cacheMap中才会有对应的对象并且肯定是完整的。所以这里不需要加volatile。
可能会有人觉得，这些类名和方法名很熟悉，让人联想到spring框架，我想说的是spring就是采用这种方式来维护bean的单例性的。当然，要做好这样一个类，上面那些肯定是不够的。
看看spring这段源码：
public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
···
protected <T> T doGetBean(String name, Class<T> requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException {
final String beanName = this.transformedBeanName(name);
Object sharedInstance = this.getSingleton(beanName);
Object bean;
if(sharedInstance != null && args == null) {
···
bean = this.getObjectForBeanInstance(sharedInstance, name, beanName, (RootBeanDefinition)null);
}else{
final RootBeanDefinition ex1 = this.getMergedLocalBeanDefinition(beanName);
···
if(ex1.isSingleton()) {
sharedInstance = this.getSingleton(beanName, new ObjectFactory() {
public Object getObject() throws BeansException {
try {
return AbstractBeanFactory.this.createBean(beanName, ex1, args);
} catch (BeansException var2) {
AbstractBeanFactory.this.destroySingleton(beanName);
throw var2;
}
}
});
bean = this.getObjectForBeanInstance(sharedInstanc, name, beanName, ex1);
}
···
return bean;
}
}
spring这段代码涉及到的东西很多，而且将许多语句封装成了方法，不过不用仔细看，从这几句就知道单例注册表在其中是有应用的。
最后的总结
本篇文章是我学习单例模式的笔记整理出来的，从单例模式的实现到单例模式的应用都有所涉及，其中还有许多地方可以深究，比如，延迟加载的各种并发问题，volatile关键字所涉及到的java的内存模型，还有spring的单例模式具体实现等等。
