深刻理解双重检查锁定(double-checked locking)与单例模式
2017-12-01 18:13
621 查看
加载,表示启动程序的文件或信息的载入
java中类的字节码文件加载进内存,就是内容以io流的形式存入内存。
User user=new User(“男”,26);
该语句做了几件事:
因为new用到了User.class,所以找到User.class文件并加载到内存中
执行该类的static代码块,如果有的话,给User.class类进行初始化
在堆内存中开辟空间,分配内存地址。
在堆内存中建立对象的特有属性,并进行默认初始化。
对属性进行显式初始化
对对象进行构造代码块初始化
对对象进行对应的构造函数初始化
将内存地址赋给栈内存中的p变量
懒加载
饿汉式单例
这样的代码缺点是:第一次加载类的时候会连带着创建Singleton实例,这样的结果与我们所期望的不同,因为创建实例的时候可能并不是我们需要这个实例的时候。同时如果这个Singleton实例的创建非常消耗系统资源,而应用始终都没有使用Singleton实例,那么创建Singleton消耗的系统资源就被白白浪费了。
为了避免这种情况,我们通常使用惰性加载的机制,也就是在使用的时候才去创建。以上代码的惰性加载代码如下:
懒汉式单例
线程安全问题
这是如果两个线程A和B同时执行了该方法,然后以如下方式执行:
A进入if判断,此时instance为null,因此进入if内
B进入if判断,此时A还没有创建instance,因此instance也为null,因此B也进入if内
A创建了一个instance并返回
B也创建了一个instance并返回
此时问题出现了,我们的单例被创建了两次,而这并不是我们所期望的。
3 各种解决方案及其存在的问题
3.1 使用Class锁机制
以上问题最直观的解决办法就是给getInstance方法加上一个synchronize前缀,这样每次只允许一个现成调用getInstance方法:
这种解决办法的确可以防止错误的出现,但是它却很影响性能:每次调用getInstance方法的时候都必须获得Singleton的锁,而实际上,当单例实例被创建以后,其后的请求没有必要再使用互斥机制了
3.2 double-checked locking
曾经有人为了解决以上问题,提出了double-checked locking的解决方案
让我们来看一下这个代码是如何工作的:首先当一个线程发出请求后,会先检查instance是否为null,如果不是则直接返回其内容,这样避免了进入synchronized块所需要花费的资源。其次,即使第2节提到的情况发生了,两个线程同时进入了第一个if判断,那么他们也必须按照顺序执行synchronized块中的代码,第一个进入代码块的线程会创建一个新的Singleton实例,而后续的线程则因为无法通过if判断,而不会创建多余的实例。
上述描述似乎已经解决了我们面临的所有问题,但实际上,从JVM的角度讲,这些代码仍然可能发生错误。
对于JVM而言,它执行的是一个个Java指令。在Java指令中创建对象和赋值操作是分开进行的,也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序,也就是说有可能JVM会为新的Singleton实例分配空间,然后直接赋值给instance成员,然后再去初始化这个Singleton实例。(即先赋值指向了内存地址,再初始化)这样就使出错成为了可能,我们仍然以A、B两个线程为例:
A、B线程同时进入了第一个if判断
A首先进入synchronized块,由于instance为null,所以它执行instance = new Singleton();
由于JVM内部的优化机制,JVM先画出了一些分配给Singleton实例的空白内存,并赋值给instance成员(注意此时JVM没有开始初始化这个实例),然后A离开了synchronized块。
B进入synchronized块,由于instance此时不是null,因此它马上离开了synchronized块并将结果返回给调用该方法的程序。
此时B线程打算使用Singleton实例,却发现它没有被初始化,于是错误发生了。
4 通过内部类实现多线程环境中的单例模式
为了实现慢加载,并且不希望每次调用getInstance时都必须互斥执行,最好并且最方便的解决办法如下:
JVM内部的机制能够保证当一个类被加载的时候,这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候,JVM能够帮我们保证instance只被创建一次,并且会保证把赋值给instance的内存初始化完毕,这样我们就不用担心3.2中的问题。此外该方法也只会在第一次调用的时候使用互斥机制,这样就解决了3.1中的低效问题。最后instance是在第一次加载SingletonContainer类时被创建的,而SingletonContainer类则在调用getInstance方法的时候才会被加载,因此也实现了惰性加载。
java中类的字节码文件加载进内存,就是内容以io流的形式存入内存。
User user=new User(“男”,26);
该语句做了几件事:
因为new用到了User.class,所以找到User.class文件并加载到内存中
执行该类的static代码块,如果有的话,给User.class类进行初始化
在堆内存中开辟空间,分配内存地址。
在堆内存中建立对象的特有属性,并进行默认初始化。
对属性进行显式初始化
对对象进行构造代码块初始化
对对象进行对应的构造函数初始化
将内存地址赋给栈内存中的p变量
懒加载
饿汉式单例
public class Singleton { private static Singleton instance = new Singleton(); private Singleton(){ … } public static Singleton getInstance(){ return instance; } }
这样的代码缺点是:第一次加载类的时候会连带着创建Singleton实例,这样的结果与我们所期望的不同,因为创建实例的时候可能并不是我们需要这个实例的时候。同时如果这个Singleton实例的创建非常消耗系统资源,而应用始终都没有使用Singleton实例,那么创建Singleton消耗的系统资源就被白白浪费了。
为了避免这种情况,我们通常使用惰性加载的机制,也就是在使用的时候才去创建。以上代码的惰性加载代码如下:
懒汉式单例
public class Singleton{ private static Singleton instance = null; private Singleton(){ … } public static Singleton getInstance(){ if (instance == null) instance = new Singleton(); return instance; } }
线程安全问题
这是如果两个线程A和B同时执行了该方法,然后以如下方式执行:
A进入if判断,此时instance为null,因此进入if内
B进入if判断,此时A还没有创建instance,因此instance也为null,因此B也进入if内
A创建了一个instance并返回
B也创建了一个instance并返回
此时问题出现了,我们的单例被创建了两次,而这并不是我们所期望的。
3 各种解决方案及其存在的问题
3.1 使用Class锁机制
以上问题最直观的解决办法就是给getInstance方法加上一个synchronize前缀,这样每次只允许一个现成调用getInstance方法:
public static synchronized Singleton getInstance(){ if (instance == null) instance = new Singleton(); return instance; }
这种解决办法的确可以防止错误的出现,但是它却很影响性能:每次调用getInstance方法的时候都必须获得Singleton的锁,而实际上,当单例实例被创建以后,其后的请求没有必要再使用互斥机制了
3.2 double-checked locking
曾经有人为了解决以上问题,提出了double-checked locking的解决方案
public static Singleton getInstance(){ if (instance == null) synchronized(instance){ if(instance == null) instance = new Singleton(); } return instance; }
让我们来看一下这个代码是如何工作的:首先当一个线程发出请求后,会先检查instance是否为null,如果不是则直接返回其内容,这样避免了进入synchronized块所需要花费的资源。其次,即使第2节提到的情况发生了,两个线程同时进入了第一个if判断,那么他们也必须按照顺序执行synchronized块中的代码,第一个进入代码块的线程会创建一个新的Singleton实例,而后续的线程则因为无法通过if判断,而不会创建多余的实例。
上述描述似乎已经解决了我们面临的所有问题,但实际上,从JVM的角度讲,这些代码仍然可能发生错误。
对于JVM而言,它执行的是一个个Java指令。在Java指令中创建对象和赋值操作是分开进行的,也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序,也就是说有可能JVM会为新的Singleton实例分配空间,然后直接赋值给instance成员,然后再去初始化这个Singleton实例。(即先赋值指向了内存地址,再初始化)这样就使出错成为了可能,我们仍然以A、B两个线程为例:
A、B线程同时进入了第一个if判断
A首先进入synchronized块,由于instance为null,所以它执行instance = new Singleton();
由于JVM内部的优化机制,JVM先画出了一些分配给Singleton实例的空白内存,并赋值给instance成员(注意此时JVM没有开始初始化这个实例),然后A离开了synchronized块。
B进入synchronized块,由于instance此时不是null,因此它马上离开了synchronized块并将结果返回给调用该方法的程序。
此时B线程打算使用Singleton实例,却发现它没有被初始化,于是错误发生了。
4 通过内部类实现多线程环境中的单例模式
为了实现慢加载,并且不希望每次调用getInstance时都必须互斥执行,最好并且最方便的解决办法如下:
public class Singleton{ private Singleton(){ … } private static class SingletonContainer{ private static Singleton instance = new Singleton(); } public static Singleton getInstance(){ return SingletonContainer.instance; } }
JVM内部的机制能够保证当一个类被加载的时候,这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候,JVM能够帮我们保证instance只被创建一次,并且会保证把赋值给instance的内存初始化完毕,这样我们就不用担心3.2中的问题。此外该方法也只会在第一次调用的时候使用互斥机制,这样就解决了3.1中的低效问题。最后instance是在第一次加载SingletonContainer类时被创建的,而SingletonContainer类则在调用getInstance方法的时候才会被加载,因此也实现了惰性加载。
相关文章推荐
- Singleton - 单例模式和Double-Checked Locking - 双重检查锁定模式
- Singleton(单例)模式和Double-Checked Locking(双重检查锁定)模式
- Java设计模式之单例模式 double---checked----locking双重检查锁定
- 双重检查锁定(double-checked locking)与单例模式
- 双重检查锁定(double-checked locking)与单例模式
- 双重检查锁定(double-checked locking)与单例模式
- Design Pattern_Singleton(单件模式)和Double-Checked Locking(双重检查锁定)
- 双重检查锁定(double-checked locking)与单例模式
- 双重检查锁定的漏洞的分析 The "Double-Checked Locking is Broken" Declaration
- 单例模式中的 双重检查锁定(Double-Check Locking ) (多线程下单例模式中的双重检查锁定的实现)
- 单例模式中的 双重检查锁定(Double-Check Locking )
- 【Java】双重检查锁定(Double-checked locking)与延迟初始化(Initialization on demand holder)
- 单例模式中的 双重检查锁定(Double-Check Locking ) (多线程下单例模式中的双重检查锁定的实现)
- Singleton 单件模式及其变体 Double-Checked Locking 双重检查锁模式
- 双重检查锁定失败可能性——参照《The "Double-Checked Locking is Broken" Declaration》
- 单例模式中的 双重检查锁定(Double-Check Locking )
- Singleton 单件模式及其变体 Double-Checked Locking 双重检查锁模式
- 双重检查锁定及单例模式 全面理解这一失效的编程习语
- 双重检查锁定及单例模式——全面理解这一失效的编程习语
- Double-checked locking and the Singleton pattern--双重检查加锁失效原因剖析