Java五种单例模式与线程安全

懒汉式程序员

顾名思义,lazy loading(延迟加载,一说懒加载),在须要的时候才建立单例对象,而不是随着软件系统的运行或者当类被加载器加载的时候就建立。当单例类的建立或者单例对象的存在会消耗比较多的资源,经常采用lazy loading策略。这样作的一个明显好处是提升了软件系统的效率,节约内存资源。下面咱们看看最简单的懒汉单例模式:安全

代码1-1多线程

?ide

1函数

2性能

3测试

4spa

5.net

6线程

7

8

9

10

11

12

13

14

15

16

public class Singleton {

    private static Singleton singleton = null;    //私有的、类型为Singleton自身的静态成员变量

     

    //构造方法被设为私有,防止外部使用new来建立对象,破坏单例

    private Singleton(){

        System.out.println("构造函数被调用");

    }

     

    //公有的静态方法,供外部调用来获取单例对象

    public static Singleton getInstance(){

        if(singleton == null){    //第一次调用该方法时,建立对象。

            singleton = new Singleton();

        }

        return singleton;

    }

}

 

在单线程环境下,屡次调用getInstance()方法得到的Singleton对象均为同一个对象,单例模式实现成功。然而,在更多时候,软件系统工做于多线程环境下,所以不得不考虑线程安全的问题。

现有多线程测试程序以下:

代码1-2

?

1

2

3

4

5

6

7

8

9

10

public class TestThread {

    public static void main(String[] args) {

        Runnable run = () -> Singleton.getInstance();    //建立实现了Runnable接口的匿名类

 

        for(int i = 0; i < 50; i++){

            Thread thread = new Thread(run);

            thread.start();

        }

    }

}

 

代码中先建立了一个实现了Runnable接口的匿名类对象run,而后用for循环建立并启动50个线程,其中一次运行结果以下:

?

1

2

3

4

构造函数被调用

构造函数被调用

构造函数被调用

构造函数被调用

 

 

显然,Singleton的构造方法不止一次被调用,也就是说,Singleton存在四个实例对象,这违背了单例模式的初衷。这个实验说明,简单的懒汉式在多线程环境下不是线程安全的。有人提出在getInstance()方法上同步锁,可是锁住一整个方法可能粒度过大,不利于效率。既然锁方法不太好,那么锁代码呢?下面咱们再看看两个例子:

代码1-3

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

public class Singleton {

    private static Singleton singleton = null;    

     

    private Singleton(){

        System.out.println("构造函数被调用");

    }

     

    public static Singleton getInstance(){

        if(singleton == null){

            synchronized(Singleton.class){

                singleton = new Singleton();

            }

        }

        return singleton;

    }

}

 

代码段1-3的getInstance()方法里,在判空语句后上锁,把singleton = new Singleton()语句锁住了,这样作看似解决了线程安全问题,其实否则。设现有线程A和B,在t1时刻线程A和B均已经过判空语句但都未取得锁资源;t2时刻时,A先取得锁资源进入临界区(被锁的代码块),执行new操做建立实例对象,而后退出临界区,释放锁资源。t3时刻,B取得被A释放的锁资源进入临界区,执行new操做建立实例对象,而后退出临界区,释放锁资源。明显地,Singleton被实例化两次。因此,如代码段1-3这样写也不能保证线程安全。

代码1-4

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

public class Singleton {

    private static Singleton singleton = null;    

     

    private Singleton(){

        System.out.println("构造函数被调用");

    }

     

    public static Singleton getInstance(){

            synchronized(Singleton.class){

                if(singleton == null){

                singleton = new Singleton();

            }

        }

        return singleton;

    }

}

 

    代码段1-4把代码锁放在了判空语句前,这样作避免了代码段1-3的问题,然而这样作相似于在方法签名上加上synchronized关键字,会影响程序效率。由于当有多个线程几乎同时访问getInstance方法时,多个线程必须有次序地进入方法内,这样致使了若干个线程须要耗费等待进入临界区(被锁住的代码块)的时间。基于此,有人提出了双重校验锁式。

 

 

双重校验锁DCL(double checked locking)

双重校验锁式(也有人把双重校验锁式和懒汉式归为一类)分别在代码锁先后进行判空校验,避免了多个有机会进入临界区的线程都建立对象,同时也避免了代码段1-4后来线程在先来线程建立对象后但仍未退出临界区的状况下等待。双重校验锁代码以下:

代码2-1

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

public class Singleton{

        private volatile static Singleton singleton = null;    //注意此处加上了volatile关键字

     

    private Singleton(){

        System.out.println("构造函数被调用");

    }

     

    public static Singleton getInstance(){

        if(singleton == null){

            synchronized(Singleton.class){

                if(singleton == null){

                    singleton = new Singleton();

                    //return singleton;    //有人提议在此处进行一次返回

                }

                //return singleton;    //也有人提议在此处进行一次返回

            }

        }

        return singleton;

    }

}

 

经屡次试验说明,双重校验锁式是线程安全的。然而,在JDK1.5之前,DCL是不稳定的,有时也可能建立多个实例,在1.5之后开始提供volatile关键字修饰变量来达到稳定效果。

 

 

饿汉式

单例模式的饿汉式,在定义自身类型的成员变量时就将其实例化,使得在Singleton单例类被系统(姑且这么说)加载时就已经被实例化出一个单例对象,从而一劳永逸地避免了线程安全的问题。代码以下:

代码3-1

?

1

2

3

4

5

6

7

8

9

10

11

public class Singleton{

        private static Singleton singleton = new Singleton();    //在定义变量时就将其实例化

     

    private Singleton(){

        System.out.println("构造函数被调用");

    }

     

    public static Singleton getInstance(){

        return singleton;

    }

}

 

使用多线程测试代码1-2进行测试,单例模式成功实现。

我想应该有朋友对饿汉式单例在什么时候被实例化感兴趣。能够编写以下简单测试代码:

代码3-2

?

1

2

3

4

5

public class TestThread {

    public static void main(String[] args) {

        Class.forName("Singleton");

    }

}

 

运行这段代码后能够看到控制台有“构造函数被调用”字符串输出,说明在ClassLoader加载Singleton类时,饿汉式单例就被建立。

虽然饿汉式单例是线程安全的,但也有其不足之处。饿汉式单例在类被加载时就建立单例对象而且长驻内存,无论你需不须要它;若是单例类占用的资源比较多,就会下降资源利用率以及程序的运行效率。有一种更高级的单例模式则很好地解决了这个问题——静态内部类。

 

 

IoDH(Initialization Demand Holder)——经过静态内部类实现线程安全的单例模式

静态内部类式在Singleton类内部定义了一个静态的内部类,在该内部类里建立Singleton的单例对象。咱们先看代码:

代码4-1

?

1

2

3

4

5

6

7

8

9

10

11

12

13

public class Singleton {

    private Singleton(){

        System.out.println("构造函数被调用");

    }

     

    public static Singleton getInstance(){

        return SingletonHolder.instance;

    }

     

    private static class SingletonHolder{

        private static Singleton instance = new Singleton();

    }

}

 

静态内部类式和饿汉式同样,一样利用了ClassLoader的机制保证了线程安全;不一样的是,饿汉式在Singleton类被加载时(从代码段3-2的Class.forName可见)就建立了一个实例对象,而静态内部类即便Singleton类被加载也不会建立单例对象,除非调用里面的getInstance()方法。由于当Singleton类被加载时,其静态内部类SingletonHolder没有被主动使用。只有当调用getInstance方法时,才会装载SingletonHolder类,从而实例化单例对象。

这样,经过静态内部类的方法就实现了lazy loading,很好地将懒汉式和饿汉式结合起来,既实现延迟加载,保证系统性能,也能保证线程安全。

 

然而,对于上述四种方式的单例模式,若是你的Singleton类实现了Serializable序列化接口,那么可能会被序列化生成多个实例,由于readObject()方法一直返回一个新的对象:

?

1

2

3

4

5

6

ByteArrayOutputStream baos  = new ByteArrayOutputStream();

ObjectOutputStream oos = new ObjectOutputStream(baos);

oos.writeObject(singleton);

  

ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(baos.toByteArray()));

Singleton singleton=  (Singleton) ois.readObject();

 

这种状况能够经过在Singleton类添加readResolve()方法来解决:

?

1

2

3

4

private Object readResolve() {

        System.out.println("readResolve()被调用");

        return getInstance();

}

 

可是这种解决方案虽解决了序列化的问题,可是没法避免被反射。下面还有一种枚举单例,写法简单,还能够避免序列化、反射的问题。

 

 

枚举单例

上面说到的静态内部类方式不失为一个高级的单例模式实现。但若是开发要求更严格一些,好比你的Singleton类实现了序列化,又或者想避免经过反射来破解单例模式的话,单例模式还能够有另外一种形式。那就是枚举单例。枚举类型在JDK1.5被引进。这种方式也是《Effective Java》做者Josh Bloch 提倡的方式,它不只能避免多线程的问题,并且还能防止反序列化从新建立新的对象、防止被反射攻击。代码以下:

代码5-1

?

1

2

3

4

5

6

7

8

9

10

11

public enum EnumSingleton {

    INSTANCE{

        @Override

        protected void work() {

            System.out.println("你好,是我!");

        }

         

    };

     

    protected abstract void work();    //单例须要进行操做(也能够不写成抽象方法)

}

 

在外部,能够经过EnumSingleton.INSTANCE.work()来调用work方法。默认的枚举实例的建立是线程安全的,可是实例内的各类方法则须要程序员来保证线程安全。总的来讲,使用枚举单例模式,有三个好处:1.实例的建立线程安全,确保单例。2.防止被反射建立多个实例。3.没有序列化的问题。

相关文章
相关标签/搜索