多线程场景下延迟初始化的策略
Posted Kingsley
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了多线程场景下延迟初始化的策略相关的知识,希望对你有一定的参考价值。
1.什么是延迟初始化
延迟初始化(lazy initialization,即懒加载)是延迟到需要域的值时才将它初始化的行为。如果永远不需要这个值,这个域就永远不会被初始化。这种方法既静态域,也适用于实例域。
最好建议“除非绝对必要,否则就不要这么做”。
2.延迟初始化线程安全的一个策略:同步
延迟初始化的一个好处,是当域只在类的实例部分被访问,并且初始化这个域的开销很高,那就可能值得进行延迟初始化。
但是在大多数情况下,正常的初始化要优先于延迟初始化。因为在多线程的场景下,采用某种形式的同步是很重要的,否则就容易造成严重的Bug。
如下面的域bar,采取了延迟初始化的方法,那么在获取的时候,必须加上同步。
1 class Foo { 2 3 private Bar bar; 4 5 synchronized Bar getBar() { 6 if(null == bar) { 7 bar = new Bar(); 8 } 9 return bar; 10 } 11 }
代码段-1
否则的话,将上面的synchronized关键字去掉,考虑这样的场景:
假设线程AB同时访问getBar()方法,下面表示线程执行代码的顺序,数字表示第几行。
A->6, B->6, A->7, A->9, B->7, B->9;
结果A,B两个线程获得的Bar对象,并不是同一个对象,有些情况下是允许的,但有些情况下很可能会引发问题,比如下面会讲到的单例模式。
很明显,同步可以解决这个问题。但无论是synchronized关键字是加在方法上还是块里面,每次访问getBar()方法,都需要加锁,解锁,增加了开销。
上面的案例对于静态域同样适用。
综上所述,同步可以解决在多线程访问域时线程不安全的问题,但会增加额外的开销。所以这不是一个好的方法。
3.静态域延迟初始化的策略:lazy initialization holder class模式
如果出于性能的考虑而需要对静态域使用延迟初始化,就使用lazy initialization holder class模式(也称作initianlize-on-demand holder class idiom)。
这种模式的写法如下:
1 class Foo { 2 3 //1. 一个私有静态类,将静态域放到静态类里 4 private static class BarHolder { 5 static final Bar bar = new Bar(); 6 } 7 8 //2. 访问域的时候,返回静态类的域 9 public Bar getBar() { 10 return BarHolder.bar; 11 } 12 }
代码段-2
当getBar()方法被调用时,它读取了BarHolder.bar的值,导致BarHolder类得到初始化。类初始化的时候,会初始化静态域bar.
对于多个线程来说,无论谁先读取BarHolder.bar的值,BarHolder都将只初始化一次,因此每次访问的结果都是同一个Bar对象。
这种模式的魅力在于,getBar()方法没有被步,并且只执行一个域访问,因此延迟初始化实际上并没有增加任何访问成本。
这种模式最常见的应用,就是在单例模式中。单例模式要求类本身有一个静态域(如instance),指向类的一个实例,该类的getInstance()返回该静态域,并且每次返回的都是同一个对象,这才是一个单例。
假如使用延迟初始化,在getInstance的时候,没有添加同步,如下面所示。
1 class Foo { 2 3 private static Foo instance ; 4 5 public static Foo getInstance() { 6 if(null == instance) { 7 instance = new Foo(); 8 } 9 return instance; 10 } 11 }
代码段-3
很明显,多次访问可能返回不同的对象,而如果加上synchronized关键字,或者加上读写锁,则开销较大,每次获取一个对象的时候还要竞争锁。
使用了lazy initialization holder class模式,就可以写成下面这样:
1 class Foo { 2 3 private static class FooHolder { 4 static final Foo instance = new Foo(); 5 } 6 7 public static Foo getInstance() { 8 return FooHolder.instance; 9 } 10 }
代码段-4
当然,最好的实践,还是不要采用延迟初始化。除非是初始化比较耗时而影响了系统的启动,比如我们公司采用OSGi框架,每个bundle启动的时间都要做优化,那么单例的初始化可以等到系统已经启动了,操作时用到再初始化。
4.实例域延迟初始化的策略:双重检查模式(double-check idiom)
这种模式避免了域在被初始化之后访问这个域时的锁定开销(参考代码段-1)。这种模式背后的思想是:两次检查域的值(因此为double check),第一次检查时没有锁定,看看这个域是否被初始化了;第二次检查时有锁定。只有当第二次检查时表明这个域没有被初始化,才会调用初始化方法。因为如果域已经被初始化就不会有锁定(域被声明为volatile很重要)。和代码段-1对比一下,一个每次访问都会锁定,无论域是否已经初始化,一个是存在若干次需要锁定,一旦域已经初始化,将不会再有锁定。可见,开销变小了。
1 class Foo { 2 //volatile关键字 3 private volatile Bar bar; 4 5 public Bar getBar() { 6 //局部变量只是减少读取次数,提升性能,不是严格需要 7 Bar result = this.bar; 8 //第一次检查,不锁定 9 if(null == result) { 10 //一旦初始化,第一次检查将无法通过,不会有锁定开销 11 synchronized (this) { 12 result = this.bar; 13 //第二次检查,锁定 14 if(null == result) { 15 this.bar = result = new Bar(); 16 } 17 } 18 } 19 return result; 20 } 21 }
代码段-5
注意:在Java 1.5发行之前,双重检查模式的功能很不稳定,因为volatile修饰符的主义不够强,难以支持它。Java 1.5版本引入的内存模式解决了这个问题(内存模式参考 原子性和可见性)。如今,双重检查模式是延迟初始化一个实例域的方法。
有些时候,你可能需要延迟初始化一个可以接受重复初始化的实例域。如果处于这种情况,就可以使用双重检查模式的一个变形,省去第二次检查。这种叫做单重检查模式(single-check iidiom)。对实例域来说,代码如下:
1 class Foo { 2 // volatile关键字 3 private volatile Bar bar; 4 5 public Bar getBar() { 6 // 局部变量只是减少读取次数,提升性能,不是严格需要 7 Bar result = this.bar; 8 // 只有一次检查 9 if (null == result) { 10 this.bar = result = new Bar(); 11 } 12 return result; 13 } 14 }
代码段-6
对静态域来说,实际上,就是代码段-3。
单重检查模式这种情况是可能发生的。例如最近开发的一个特性,通过工厂模式返回一个HttpClient的包装对象(该类是用来向一个固定的系统发送消息的,因此IP,端口,鉴权信息全都是固定的,全局只有一个对象就够了,客户端调用时也不用填写对端系统信息)。
包装类对象延迟初始化。包装类的作用只是包装了一个第三方HttpClient,发送消息,返回响应消息,中间封装了一些操作,减少客户端的调用代码而已。对于客户端来说,这个对象不存储共享数据,使用后也没有存储起来,因此是允许重复初始化域的。
以上是关于多线程场景下延迟初始化的策略的主要内容,如果未能解决你的问题,请参考以下文章