为什么使用单例模式？
尽可能的节约内存空间，减少无谓的GC消耗
这些类，在应用中如果有两个或者两个以上的实例会引起错误，又或者我换句话说，就是这些类，在整个应用中，同一时刻，有且只能有一种状态。eg： 一般实践当中，有很多应用级别的资源会被做成单例，比如配置文件信息，逻辑上来讲，整个应用有且只能在同在时间有一个，当然如果你有多个，这可能并不会引起程序级别错误，这里指的错误特指异常或者ERROR。但是当我们试图改变配置文件的时候，问题就出来了。
在我的工作过程中，我发现所有可以使用单例模式的类都有一个共性，那就是这个类没有自己的状态，换句话说，这些类无论你实例化多少个，其实都是一样的，而且更重要的一点是，这个类如果有两个或者两个以上的实例的话，我的程序竟然会产生程序错误或者与现实相违背的逻辑错误。
这样的话，如果我们不将这个类控制成单例的结构，应用中就会存在很多一模一样的类实例，这会非常浪费系统的内存资源，而且容易导致错误甚至一定会产生错误，所以我们单例模式所期待的目标或者说使用它的目的，是为了尽可能的节约内存空间，减少无谓的GC消耗，并且使应用可以正常运作。
写法：
1. 最傻的写法：
public class SingleInstance{
private static SingleInstance singleton;
private SingleInstance(){
//doInit
}
public static SingleInstance getInstance(){
if(singleton == null){
singleton = new SingleInstance();
}
}
}
这种就不多说了，在多个线程执行下可能会创建出很多个实例不能保证单例。
2. 加上锁的第一种写法：
public class BadSynchronizedSingleton {
//一个静态的实例
private static BadSynchronizedSingleton synchronizedSingleton;
//私有化构造函数
private BadSynchronizedSingleton(){}
//给出一个公共的静态方法返回一个单一实例
public synchronized static BadSynchronizedSingleton getInstance(){
if (synchronizedSingleton == null) {
synchronizedSingleton = new BadSynchronizedSingleton();
}
return synchronizedSingleton;
}
}
这种做法把整个方法锁住确实是能解决上面说的问题，但是凡是一个线程使用getInstance就会把这个对象锁住。造成很多无谓的等待。
3. 单例模式版本，也称为双重加锁：
public class SynchronizedSingleton {
//一个静态的实例
private static SynchronizedSingleton synchronizedSingleton;
//私有化构造函数
private SynchronizedSingleton(){}
//给出一个公共的静态方法返回一个单一实例
public static SynchronizedSingleton getInstance(){
if (synchronizedSingleton == null) {
synchronized (SynchronizedSingleton.class) {
if (synchronizedSingleton == null) {
synchronizedSingleton = new SynchronizedSingleton();
}
}
}
return synchronizedSingleton;
}
}
这种做法与上面那种最无脑的同步做法相比就要好很多了，因为我们只是在当前实例为null，也就是实例还未创建时才进行同步，否则就直接返回，这样就节省了很多无谓的线程等待时间，值得注意的是在同步块中，我们再次判断了synchronizedSingleton是否为null，解释下为什么要这样做。
假设我们去掉同步块中的是否为null的判断，有这样一种情况，假设A线程和B线程都在同步块外面判断了synchronizedSingleton为null，结果A线程首先获得了线程锁，进入了同步块，然后A线程会创造一个实例，此时synchronizedSingleton已经被赋予了实例，A线程退出同步块，直接返回了第一个创造的实例，此时B线程获得线程锁，也进入同步块，此时A线程其实已经创造好了实例，B线程正常情况应该直接返回的，但是因为同步块里没有判断是否为null，直接就是一条创建实例的语句，所以B线程也会创造一个实例返回，此时就造成创造了多个实例的情况。
经过刚才的分析，貌似上述双重加锁的示例看起来是没有问题了，但如果再进一步深入考虑的话，其实仍然是有问题的。
如果我们深入到JVM中去探索上面这段代码，它就有可能（注意，只是有可能）是有问题的。
因为虚拟机在执行创建实例的这一步操作的时候，其实是分了好几步去进行的，也就是说创建一个新的对象并非是原子性操作。在有些JVM中上述做法是没有问题的，但是有些情况下是会造成莫名的错误。
首先要明白在JVM创建新的对象时，主要要经过三步。
分配内存
初始化构造器
将对象指向分配的内存的地址
这种顺序在上述双重加锁的方式是没有问题的，因为这种情况下JVM是完成了整个对象的构造才将内存的地址交给了对象。但是如果2和3步骤是相反的（2和3可能是相反的是因为JVM会针对字节码进行调优，而其中的一项调优便是调整指令的执行顺序），就会出现问题了。
因为这时将会先将内存地址赋给对象，针对上述的双重加锁，就是说先将分配好的内存地址指给synchronizedSingleton，然后再进行初始化构造器，这时候后面的线程去请求getInstance方法时，会认为synchronizedSingleton对象已经实例化了，直接返回一个引用。如果在初始化构造器之前，这个线程使用了synchronizedSingleton，就会产生莫名的错误。
所以我们在语言级别无法完全避免错误的发生，我们只有将该任务交给JVM，所以有一种比较标准的单例模式。如下所示。
package com.oneinstance;
public class InnerClassSingleton {
public static Singleton getInstance(){
return Singleton.singleton;
}
private static class Singleton{
protected static Singleton singleton = new Singleton();
}
}
咱们上面说的都是懒汉式加载的方式，还有一种饿汉式加载的方式：
public class Singleton {
private static Singleton singleton = new Singleton();
private Singleton(){}
public static Singleton getInstance(){
return singleton;
}
}
从始至终就没有使用这个实例，造成内存的浪费。
不过在有些时候，直接初始化单例的实例也无伤大雅，对项目几乎没什么影响，比如我们在应用启动时就需要加载的配置文件等，就可以采取这种方式去保证单例。
