设计模式——单例模式

保证一个类仅有一个实例,并提供一个访问它的全局访问点。
单例模式,可以说是GOF的23种设计模式中最简单的一个。
某些情况下,我们可能需要某个类只能创建出一个对象,这就是单例模式的意义。该模式的关键是将类的构造方法设置为private权限,并提供一个返回它的唯一实例的方法(static方法)。
单例模式在设计上有如下特点:
1.单线程安全单例模式(不使用同步锁)

public class Singleton {
     private static Singleton instance;   
     //private类型的构造函数,保证其他类对象不能直接new一个该对象的实例
     private Singleton(){  
 	 //private类型的构造函数,保证其他类对象不能直接new一个该对象的实例
     }
     public static Singleton getInstance(){    //该类唯一的一个public方法  
        if(instance==null)  			       //1
            instance=new Singleton();	 //2
        return instance;			     //3
     }
 }

首先,对于静态成员变量instance初始值赋予null,确保系统启动时没有额外的负载,此类的设计确保只创建一个 Singleton 对象,这个实现适合于单线程程序。然而,当引入多线程时,就必须通过同步来保护 getInstance() 方法。如果不保护 getInstance() 方法,则可能返回 Singleton 对象的两个不同的实例。假设两个线程并发调用 getInstance() 方法并且按以下顺序执行调用:
1. 线程 1 调用 getInstance() 方法并确定 instance 在 //1 处为 null 。
2. 线程 1 进入 if 代码块,但在执行 //2 处的代码行时被线程 2 预占。
3. 线程 2 调用 getInstance() 方法并在 //1 处确定 instance 为 null 。
4. 线程 2 进入 if 代码块并创建一个新的 Singleton 对象并在 //2 处将变量 instance 分配给这个新对象。
5. 线程 2 在 //3 处返回 Singleton 对象引用。
6. 线程 2 被线程 1 预占。
7. 线程 1 在它停止的地方启动,并执行 //2 代码行,这导致创建另一个 Singleton 对象。
8. 线程 1 在 //3 处返回这个对象。
结果是 getInstance() 方法创建了两个 Singleton 对象,而它本该只创建一个对象。通过同步 getInstance() 方法从而在同一时间只允许一个线程执行代码,这个问题得以改正,代码如下:

2.多线程安全单例模式实例一(使用同步方法)

 public class Singleton {  
       private static Singleton instance;  
       private Singleton (){
       }   
      //对获取实例的方法进行同步
      public static synchronized Singleton getInstance(){    
         if (instance == null)			//1
           instance = new Singleton();  //2
         return instance;			//3
      }
  }  

 

上述代码一次锁住了一个方法, 这个粒度有点大,虽然代码针对多线程访问 getInstance() 方法运行得很好。但同步方法会降低性能,而且当分析这段代码时,您会意识到只有在第一次调用方法时才需要同步,因此我们可以在每次使用的时候立即实例化一个单例。

3.多线程安全单例模式实例二(不使用同步锁)

public class Singleton {
     private static Singleton instance=new Singleton();    ///直接初始化一个实例对象
     private Singleton(){   
     }
     public static Singleton getInstance(){    ///该类唯一的一个public方法    
         return instance;
     }
 }

 

上述代码中的一个缺点是无法对instance实例做延迟加载,假如单例的创建过程很慢,会使得启动速度变慢,而且该类加载的时候就会直接new一个静态对象出来,而我们只是希望在第一次使用的时候才初始化一个该类对象,所以这种方式适合在小系统。

回过头来继续分析实例一,由于只有第一次调用执行了 //2 处的代码,而只有此行代码需要同步,因此就无需对后续调用使用同步。所有其他调用用于确定 instance 是否非 null ,并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。尽管如此,由于该方法是 synchronized 的,需要为该方法的每一次调用付出同步的代价,即使只有第一次调用需要同步。改进就是只锁住其中的new语句就OK,就是所谓的“双重锁”机制。
4.多线程安全单例模式实例三(使用双重锁)

 public class Singleton {  
  	public static Sinngleton instance;  
  	private static Singleton(){
       }   
    //对获取实例的方法进行同步
    private Singleton  getInstance(){    
       		if (instance == null){
             		synchronized(Singleton.class){
                    		instance = new Singleton(); 
           		}
            }
      	return instance;
    }  
 }

当 instance 为 null 时,两个线程可以并发地进入 if 语句内部。然后,一个线程进入 synchronized 块来初始化 instance ,而另一个线程则被阻断。当第一个线程退出 synchronized 块时,等待着的线程进入并创建另一个 Singleton 对象。注意:当第二个线程进入 synchronized 块时,它并没有检查 instance 是否非 null 。为使此方法更为有效,一个被称为“双重检查锁”的名词就应运而生了。

5.多线程安全单例模式实例四(使用双重检查锁)

 public class Singleton {  
       private volatile static Singleton instance;  //确保多线程正确处理instance变量
       private Singleton (){
       }   
        //对获取实例的方法进行同步
       public static Singleton getInstance(){    
         if (instance == null){
             synchronized(Singleton.class){			//1
                 if (instance== null) 			      //2
                    instance = new Singleton();		//3 
             }
         }
         return instance;
      }
     
 }

双重检查锁定背后的理论是:在 //2 处的第二次检查使创建两个不同的 Singleton 对象成为不可能。假设有下列事件序列:
1. 线程 1 进入 getInstance() 方法。
2. 由于 instance 为 null ,线程 1 在 //1 处进入 synchronized 块。
3. 线程 1 被线程 2 预占。
4. 线程 2 进入 getInstance() 方法。
5. 由于 instance 仍旧为 null ,线程 2 试图获取 //1 处的锁。然而,由于线程 1 持有该锁,线程 2 在 //1 处阻塞。
6. 线程 2 被线程 1 预占。
7. 线程 1 执行,由于在 //2 处实例仍旧为 null ,线程 1 还创建一个 Singleton 对象并将其引用赋值给 instance 。
8. 线程 1 退出 synchronized 块并从 getInstance() 方法返回实例。
9. 线程 1 被线程 2 预占。
10. 线程 2 获取 //1 处的锁并检查 instance 是否为 null 。
11. 由于 instance 是非 null 的,并没有创建第二个 Singleton 对象,由线程 1 创建的对象被返回。
双重检查锁定背后的理论是完美的。不幸地是,现实完全不同。双重检查锁定的问题是:并不能保证它会在单处理器或多处理器计算机上顺利运行。
双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug,而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”,这也是这些习语失败的一个主要原因。
总结起来方法4和方法5并不是很完善,也因此被大家给抛弃了,关于双重锁和双重检查锁,大家可以看这篇博客(java 双重检查锁定及单例模式),作者写的很好,现在再分析下方法3,虽然方法3使用了延迟加载,但是同步关键字的引入却大大降低了程序性能,是不是有点得不偿失?为了解决这个问题,还需要对其进行改进:

6.多线程安全单例模式实例五(使用内部类)

 public class Singleton {  
       private Singleton (){
       }  
private static class SingletonHolder{
private static Singleton instance= new Singleton(); 
}
//使用内部类来维护单例的实例 
      public static Singleton getInstance(){    
         return SingletonHolder.instance;			
      }
  }  

使用内部类的方式实现单例,既可以做到延迟加载,也不必使用同步关键字,是一种比较完善的实现。通常情况下,以上方法已经可以确保在系统中只存在唯一的实例,但仍有例外的情况,具体如何使用,大家就根据自己的情况选择吧

参考:

 

http://blog.sina.com.cn/s/blog_7f311ef50102uxvr.html

https://my.oschina.net/u/2249934/blog/343441

http://mobile.51cto.com/ahot-418975.htm

http://blog.sina.com.cn/s/blog_7f311ef50102uxvs.html

http://www.cnblogs.com/xudong-bupt/p/3433643.html

http://blog.csdn.net/kufeiyun/article/details/6166673

 

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值