单例模式分三种:懒汉式单例、饿汉式单例、内部类单例、登记式单例几种。
单例模式有一下特点:
1、单例类只能有一个实例。
2、单例类必须自己自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。
懒汉模式不是线程安全的。
饿汉模式是线程安全的。
内部内模式利用Classloader的特
注册表模式是线程安全的同时又提供运行期指定单例。
饿汉式单例类
public class Singleton
{
private Singleton(){
}
private static Singleton instance = new Singleton();
private static Singleton getInstance(){
return instance;
}
}
内部类式单例类
public class Singleton
{
private Singleton(){
}
private class SingletonHoledr(){
private static Singleton instance = new Singleton();
}
private static Singleton getInstance(){
return SingletonHoledr.instance;
}
}
懒汉式单例类
可以同步但是效率不高:
public class Singleton
{
private Singleton(){
}
private static Singleton instance;
public static synchronized Singleton getInstance(){
if(instance == null){
return instance = new Singleton();
}else{
return instance;
}
}
}
这样写程序不会出错,因为整个getInstance是一个整体的"critical section",但就是效率很不好,因为我们的目的其实只是在第一个初始化instance的时候需要locking(加锁),而后面取用instance的时候,根本不需要线程同步。
于是聪明的人们想出了下面的做法:
双检锁写法:
public class Singleton{
private static Singleton single; //声明静态的单例对象的变量
private Singleton(){} //私有构造方法
public static Singleton getSingle(){ //外部通过此方法可以获取对象
if(single == null){
synchronized (Singleton.class) { //保证了同一时间只能只能有一个对象访问此同步块
if(single == null){
single = new Singleton();
}
}
}
return single; //返回创建好的对象
}
}
思路很简单,就是我们只需要同步(synchronize)初始化instance的那部分代码从而使代码既正确又很有效率。
这就是所谓的“双检锁”机制(顾名思义)。
很可惜,这样的写法在很多平台和优化编译器上是错误的。
原因在于:instance = new Singleton()这行代码在不同编译器上的行为是无法预知的。一个优化编译器可以合法地如下实现instance = new Singleton():
1. instance = 给新的实体分配内存
2. 调用Singleton的构造函数来初始化instance的成员变量
现在想象一下有线程A和B在调用getInstance,线程A先进入,在执行到步骤1的时候被踢出了cpu。然后线程B进入,B看到的是instance 已经不是null了(内存已经分配),于是它开始放心地使用instance,但这个是错误的,因为在这一时刻,instance的成员变量还都是缺省值,A还没有来得及执行步骤2来完成instance的初始化。
当然编译器也可以这样实现:
1. temp = 分配内存
2. 调用temp的构造函数
3. instance = temp
如果编译器的行为是这样的话我们似乎就没有问题了,但事实却不是那么简单,因为我们无法知道某个编译器具体是怎么做的,因为在Java的memory model里对这个问题没有定义。
双检锁对于基础类型(比如int)适用。很显然吧,因为基础类型没有调用构造函数这一步。
关于单例模式的文章,其实网上早就已经泛滥了。但一个小小的单例,里面却是有着许多的变化。网上的文章大多也是提到了其中的一个或几个点,很少有比较全面且脉络清晰的文章,于是,我便萌生了写这篇文章的念头。企图把这个单例说透,说深入。但愿我不会做的太差。
首先来看一个典型的实现:
public class SingletonOne {
private static SingletonOne instance = null;
private SingletonOne() {
}
public static SingletonOne getInstance() {
if (instance == null) { // 1
instance = new SingletonOne(); // 2
}
return instance;
}
}
注释中已经有简单的分析了。接下来分析一下关于“非线程安全”的部分。
1、当线程A进入到第28行(#1)时,检查instance是否为空,此时是空的。
2、此时,线程B也进入到28行(#1)。切换到线程B执行。同样检查instance为空,于是往下执行29行(#2),创建了一个实例。接着返回了。
3、在切换回线程A,由于之前检查到instance为空。所以也会执行29行(#2)创建实例。返回。
4、至此,已经有两个实例被创建了,这不是我们所希望的。
怎么解决线程安全问题?
方法一:同步方法。即在getInstance()方法上加上synchronized关键字。这时单例变成了
使用同步方法的单例
package com.something.singleton;
public class SingletonTwo {
private static SingletonTwo instance = null;
private SingletonTwo() {
}
public static synchronized SingletonTwo getInstance() {
if (instance == null) { // 1
instance = new SingletonTwo(); // 2
}
return instance;
}
}
加上synchronized后确实实现了线程的互斥访问getInstance()方法。从而保证了线程安全。但是这样就完美了么?我们看。其实在典型实现里,会导致问题的只是当instance还没有被实例化的时候,多个线程访问#1的代码才会导致问题。而当instance已经实例化完成后。每次调用getInstance(),其实都是直接返回的。即使是多个线程访问,也不会出问题。但给方法加上synchronized后。所有getInstance()的调用都要同步了。其实我们只是在第一次调用的时候要同步。而同步需要消耗性能。这就是问题。
方法二:双重检查加锁Double-checked locking。
其实经过分析发现,我们只要保证 instance = new SingletonOne(); 是线程互斥访问的就可以保证线程安全了。那把同步方法加以改造,只用synchronized块包裹这一句。就得到了下面的代码:
public static SingletonThree getInstance() {
if (instance == null) { // 1
synchronized (SingletonThree.class) {
instance = new SingletonThree(); // 2
}
}
return instance;
}
这个方法可行么?分析一下发现是不行的!
1、线程A和线程B同时进入//1的位置。这时instance是为空的。
2、线程A进入synchronized块,创建实例,线程B等待。
3、线程A返回,线程B继续进入synchronized块,创建实例。。。
4、这时已经有两个实例创建了。
为了解决这个问题。我们需要在//2的之前,再加上一次检查instance是否被实例化。(双重检查加锁)接下来,代码变成了这样:
public static SingletonThree getInstance() {
if (instance == null) { // 1
synchronized (SingletonThree.class) {
if (instance == null) {
instance = new SingletonThree(); // 2
}
}
}
return instance;
}
这样,当线程A返回,线程B进入synchronized块后,会先检查一下instance实例是否被创建,这时实例已经被线程A创建过了。所以线程B不会再创建实例,而是直接返回。貌似!到此为止,这个问题已经被我们完美的解决了。遗憾的是,事实完全不是这样!这个方法在单核和多核的cpu下都不能保证很好的工作。导致这个方法失败的原因是当前java平台的内存模型。java平台内存模型中有一个叫“无序写”(out-of-order writes)的机制。正是这个机制导致了双重检查加锁方法的失效。这个问题的关键在上面代码上的第5行:instance = new SingletonThree(); 这行其实做了两个事情:1、调用构造方法,创建了一个实例。2、把这个实例赋值给instance这个实例变量。可问题就是,这两步jvm是不保证顺序的。也就是说。可能在调用构造方法之前,instance已经被设置为非空了。下面我们看一下出问题的过程:
1、线程A进入getInstance()方法。
2、因为此时instance为空,所以线程A进入synchronized块。
3、线程A执行 instance = new SingletonThree(); 把实例变量instance设置成了非空。(注意,实在调用构造方法之前。)
4、线程A退出,线程B进入。
5、线程B检查instance是否为空,此时不为空(第三步的时候被线程A设置成了非空)。线程B返回instance的引用。(问题出现了,这时instance的引用并不是SingletonThree的实例,因为没有调用构造方法。)
6、线程B退出,线程A进入。
7、线程A继续调用构造方法,完成instance的初始化,再返回。
好吧,继续努力,解决由“无序写”带来的问题。
public static SingletonThree getInstance() {
if (instance == null) {
synchronized (SingletonThree.class) { // 1
SingletonThree temp = instance; // 2
if (temp == null) {
synchronized (SingletonThree.class) { // 3
temp = new SingletonThree(); // 4
}
instance = temp; // 5
}
}
}
return instance;
}
解释一下执行步骤。
1、线程A进入getInstance()方法。
2、因为instance是空的 ,所以线程A进入位置//1的第一个synchronized块。
3、线程A执行位置//2的代码,把instance赋值给本地变量temp。instance为空,所以temp也为空。
4、因为temp为空,所以线程A进入位置//3的第二个synchronized块。
5、线程A执行位置//4的代码,把temp设置成非空,但还没有调用构造方法!(“无序写”问题)
6、线程A阻塞,线程B进入getInstance()方法。
7、因为instance为空,所以线程B试图进入第一个synchronized块。但由于线程A已经在里面了。所以无法进入。线程B阻塞。
8、线程A激活,继续执行位置//4的代码。调用构造方法。生成实例。
9、将temp的实例引用赋值给instance。退出两个synchronized块。返回实例。
10、线程B激活,进入第一个synchronized块。
11、线程B执行位置//2的代码,把instance实例赋值给temp本地变量。
12、线程B判断本地变量temp不为空,所以跳过if块。返回instance实例。
好吧,问题终于解决了,线程安全了。但是我们的代码由最初的3行代码变成了现在的一大坨~。于是又有了下面的方法。
方法三:预先初始化static变量。
public class SingletonFour {
private static SingletonFour instance = new SingletonFour();
private SingletonFour() {
}
public static SingletonFour getInstance() {
return instance;
}
}
看到这个方法,世界又变得清净了。由于java的机制,static的成员变量只在类加载的时候初始化一次,且类加载是线程安全的。所以这个方法实现的单例是线程安全的。但是这个方法却牺牲了Lazy的特性。单例类加载的时候就实例化了。如注释所述:非懒加载,如果构造的单例很大,构造完又迟迟不使用,会导致资源浪费。
那到底有没有完美的办法?懒加载,线程安全,代码简单。
方法四:使用内部类。
public class SingletonFive {
private static class SingletonHolder{
private static SingletonFive instance = new SingletonFive();
}
private SingletonFive() {
}
public static SingletonFive getInstance() {
return SingletonHolder.instance;
}
}
解释一下,因为java机制规定,内部类SingletonHolder只有在getInstance()方法第一次调用的时候才会被加载(实现了lazy),而且其加载过程是线程安全的(实现线程安全)。内部类加载的时候实例化一次instance。
最后,总结一下:
1、如果单例对象不大,允许非懒加载,可以使用方法三。
2、如果需要懒加载,且允许一部分性能损耗,可以使用方法一。(官方说目前高版本的synchronized已经比较快了)
3、如果需要懒加载,且不怕麻烦,可以使用方法二。
4、如果需要懒加载,没有且!推荐使用方法四。