单例设计模式

为什么要使用单例

1，节省内存 （内个对象都会占用一定的内存空间）

 2，业务需要（例如 公司只能有一个董事长，所以董事长这个对象在内存中只能有一份，所以要使用单例）

实现单利模式需要注意以下几点

（1）构造函数私有化

（2）提供静态方法或枚举返回单例对象

（3）确保单例类的对象只有一个，尤其是多线程下

（4）确保单例对象在反序列化时不会重新构建对象

具体实现方式

饿汉式 （先吃了再说，即 一开始就创建）

 

	
	
public class CEO{
	
	private static final CEO sInstance=new CEO();
	
	private CEO(){}
	
	public static CEO getCeo(){
		return sInstance;
	}
	
}
	

CEO对象之能通过getCeo（）获取，这种单例实现方式简单，同时线程安全，但却过早实例化，一加载CEO类就实例化了CEO对象并赋值给了sInstance，我们真正需要CEO对象却是在getCeo（）的时候。比如某段代码需要通过Class.forName("")加载CEO类，但却不是为了创建CEO对象，这时候就不该实例化CEO对象。

懒汉式 （不到迫不得已不吃，即 延时创建对象）

	
public class CEO{
	
	private static  CEO sInstance;
	
	private CEO(){}
	
	public static synchronized CEO getCeo(){
		if (sInstance==null) {
			sInstance=new CEO();
		}
		return sInstance;
	}
	
}
	

 

懒汉式虽然保证了延时创建对象和线程安全，但却做了某些没必要的   锁判断。

例如，当第一次调用getCeo（）时，这时可能有多个线程同时想调用getCeo，但由于有synchronized，所以只有一个线程能进入，其他线程都必须在getCeo（）方法外等待，这时进入getCeo（）方法的线程尽管慢悠悠的创建CEO对象就可以了，等该线程离开时，CEO对象已经存在了，其他线程进入时sInstance就不为null了，所以就不需要再创建CEO对象了，直接返回sInstance即可，以上的执行过程没有问题，也没有多余的锁判断，但当之后若有若干个线程同时想获取CEO对象时却做了没必要的锁判断，例如 CEO对象已经创建好了，过了半个小时，这时突然有几十个线程想获取CEO对象，于是这几十个线程就都调用getCeo（）方法，由于方法前加了synchronized，所以这几十个线程只能排队执行，但是CEO对象早已存在了，根本就不需要排队的，完全可以并发执行getCeo方法的。

改进的懒汉式 Double Check Lock（DCL）

	
public class CEO{
	
	private static  CEO sInstance;
	
	private CEO(){}
	
	public static synchronized CEO getCeo(){
		if (sInstance==null) {
			
			synchronized (CEO.class) {
				if (sInstance==null) {
					sInstance=new CEO();
				}
			}
			
		}
		return sInstance;
	}
	
}
	

这种实现方式既可以在需要的时候才创建CEO对象，又能保证线程安全，且没有多余的   锁判断

为什么上面的synchronized (CEO.class) {  }中还要判断sInstance？

比如有两个线程，线程A和线程B，假设这两个线程都执行过了第一层的if语句，这时遇到了synchronized，所以只能有一个线程进入，假设进入的是线程A，这时线程B只能在synchronized代码块外等待了，线程A这时可以慢悠悠的创建CEO对象，当线程A创建完后离开了synchronized代码块，这时线程B可以进入synchronized代码块了，然后线程B也会执行sInstance=new CEO（），这时就导致有两个CEO对象了，若synchronized里加了sInstance判断就不会导致创建多个CEO对象了。

上面的这种实现方式看样很完美了，但依旧有问题

sInstance=new CEO(); 并不是一个原子操作，这句话大致做了如下3件事情

（1）给CEO的实例分配内存空间

（2）执行CEO的构造函数，初始化

（3）把分配的内存空间地址赋值给sInstance（这时sInstance！=null）

但是由于Java编译器允许处理器乱序执行，以及JDK1.5之前JMM中Cache、寄存器到主内存回写顺序的规定，上面的（2）（3）执行顺序是无法保证的，即执行顺序可能是1-2-3，也可能是1-3-2，如果执行顺序是1-3-2，在3执行完2还没执行的时候，被切换到了线程B，这时sInstance因为已经在线程A内执行过了第三点，sInstance已经不是null了，所以线程B就直接取走sInstance，但这时sInsttance还没有初始化！

但在JDK1.5及以后可以使用volatile关键字，如 private volatile static  CEO sInstance;这样就可以保证sInstance对象每次都是从主内存读取，这样就不存在上面的问题了。

不过volatile 对性能也有一点影响，但为了程序正确，这点影响可以忍受。

静态内部类实现

DCL虽然一定程度上解决了资源消耗，多余同步，线程安全问题，但不够优雅。

	
public class CEO{
	
	private CEO(){}
	
	public static synchronized CEO getCeo(){
		return InstanceHolder.sInstance;
	}
	
	/**
	 * 静态内部类
	 * @author Young
	 *
	 */
	private  static class InstanceHolder{
		private static final CEO sInstance=new CEO();
	} 
}
	

上面这种方式中，第一次加载CEO类时，不会创建CEO对象，只有调用getCeo（）方法时才会导致sInstance被实例化。这种方式不仅能保证线程安全也能够保证对象的唯一性，同时也延迟了单利的实例化。

枚举实现方式

	
public enum CEO{
	 
	INSTANCE;
	public  void  show(){
		 System.out.println("enum..");
	}
	
}

枚举不仅有字段，还可以有方法，而且枚举实例的创建是线程安全的，而且在任何情况下他都是一个实例。

在前面的几种实现方式中，反序列化时都会创建新的实例，即使构造方法已经私有化。

反序列化操作提供了一个很特别的钩子函数，类中有一个私有的，被实例化的方法，readResolve（），这个方法可以让开发人员控制反序列化，例如前面几种实现方式如果要杜绝对象在反序列化时重新生成对象，必须要加入下面的方法：

private Object readResolve()throws ObjectStreamException{
		return sInstance;
	}

枚举并不存在这个问题，因为即使反序列化也不会重新生成新的实例