设计模式原则 —— 单例模式,自以及如何实现线程安全

c++常见面试题:

讲讲两种单例模式 ?两种如何实现线程安全的?

1.饿汉式

步骤:
1.新建一个类,提供私有构造器
2.使用构造器声明当前对象实例成员
3.声明public static的返回当前类对象的方法
4.要在方法中使用私有对象

 我们知道,类加载的方式是按需加载,且加载一次。因此,在上述单例类被加载时,就会实例化一个对象并交给自己的引用,供系统使用;而且,由于这个类在整个生命周期中只会被加载一次,因此只会创建一个实例,即能够充分保证单例。

为什么说饿汉式单例天生就是线程安全的?

 我们已经在上面提到,类加载的方式是按需加载,且只加载一次。因此,在上述单例类被加载时,就会实例化一个对象并交给自己的引用,供系统使用。换句话说,在线程访问单例对象之前就已经创建好了。再加上,由于一个类在整个生命周期中只会被加载一次,因此该单例类只会创建一个实例,也就是说,线程每次都只能也必定只可以拿到这个唯一的对象。因此就说,饿汉式单例天生就是线程安全的。 

懒汉式

步骤与饿汉式相同,存在两个小细节上的不同。

我们从懒汉式单例可以看到,单例实例被延迟加载,即只有在真正使用的时候才会实例化一个对象并交给自己的引用。 

如何区分饿汉式和懒汉式?
饿汉式:在声明实例成员的时候就造好对象。
懒汉式:在调用方法时才造对象。

对比一下两者的不同:
饿汉式:对象加载时间长;线程安全。
懒汉式:延迟了对象的加载;目前这种写法线程不安全,例如三个线程几乎同时第一次调用这个方法返回Bank类的实例,这时instance是null,三个线程都进入了if,最后在内存中生成了三个Bank实例,违反了单例原则。

如何解决懒汉模式中的线程不安全问题?

单例模式与双重检查(Double-Check idiom)

 使用双重检测同步延迟加载去创建单例的做法是一个非常优秀的做法,其不但保证了单例,而且切实提高了程序运行效率,对应的代码清单如下:

如上述代码所示,为了在保证单例的前提下提高运行效率,我们需要对 singleton3 进行第二次检查,目的是避开过多的同步(因为这里的同步只需在第一次创建实例时才同步,一旦创建成功,以后获取实例时就不需要同步获取锁了)。这种做法无疑是优秀的,但是我们必须注意一点:必须使用volatile关键字修饰单例引用。 

同步延迟加载 — 使用内部类实现延迟加载

如上述代码所示,我们可以使用内部类实现线程安全的懒汉式单例,这种方式也是一种效率比较高的做法,它与饿汉式单例的区别就是:这种方式不但是线程安全的,还是延迟加载的,真正做到了用时才初始化。

  当客户端调用getSingleton5()方法时,会触发Holder类的初始化。由于singleton5是Hold的类成员变量,因此在JVM调用Holder类的类构造器对其进行初始化时,虚拟机会保证一个类的类构造器在多线程环境中被正确的加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的类构造器,其他线程都需要阻塞等待,直到活动线程执行方法完毕。在这种情形下,其他线程虽然会被阻塞,但如果执行类构造器方法的那条线程退出后,其他线程在唤醒之后不会再次进入/执行类构造器,因为 在同一个类加载器下,一个类型只会被初始化一次,因此就保证了单例。

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值