多线程场景下延迟初始化的策略

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,发送消息,返回响应消息,中间封装了一些操作,减少客户端的调用代码而已。对于客户端来说,这个对象不存储共享数据,使用后也没有存储起来,因此是允许重复初始化域的。

posted @ 2016-11-19 23:01  kingsleylam  阅读(1165)  评论(0编辑  收藏