首页 > Java > java教程 > 正文

并发中单例模式的详细介绍(附代码)

不言
发布: 2019-04-13 11:59:25
转载
2605 人浏览过

本篇文章给大家带来的内容是关于并发中单例模式的详细介绍(附代码),有一定的参考价值,有需要的朋友可以参考一下,希望对你有所帮助。

消耗内存最严重的对象创建过程,必须对其进行约束,作为创建型模式的单例模式(Singleton),始终保持应用程序中某一个实例有且仅有一个,可以很显著的提升程序性能。

以下将探讨singleton的四种实现方式.
 单线程下的Singleton的稳定性是极好的,可分为两大类:
登录后复制

1.Eager(饿汉型): 类加载时立即创建对象。

public class EagerSingleton {
    //1. 类加载时就立即产生实例对象,通过设置静态变量被外界获取
    //2. 并使用private保证封装安全性
    private static EagerSingleton eagerSingleton  = new EagerSingleton();
    
    //3. 通过构造方法的私有化,不允许外部直接创建对象,确保单例的安全性
    private EagerSingleton(){
    }
    public static EagerSingleton getEagerSingleton(){
        return eagerSingleton;
    }
登录后复制

2.Lazy(懒汉型):类加载时没有立即创建对象,等到第一个用户获取才进行实例化。

public class LazySingleton {
    //1. 类加载时并没有创建唯一实例
    private static LazySingleton lazySingleton;
    
    private LazySingleton() {
    }
        
    //2、提供一个获取实例的静态方法
    public static LazySingleton getLazySingleton() {
        if (lazySingleton == null) {
            lazySingleton = new LazySingleton();
        } 
        return lazySingleton;
    }
登录后复制

就性能方面而言,LazySingleton 明显优于 EagerSingleton ,若类的加载需要耗费大量的资源(e.g. 读取大文件信息),那么LazySingleton 的优势显而易见。但通过阅读代码,很容易发现一个致命问题。多线程间如何保持安全性?

下面将对多线程并发问题进行解析:

解决该问题的关键在于两方面:1.同步;  2.性能;

1、首先我们来解决同步问题 : 为什么会产生同步异常的问题呢?以一个经典例子作为解释:
有线程A,线程B同时调用getLazySingleton()获取实例,A调用时判断instance为null,正准备进行初始化时,突然A线程被挂起了,此时对象并未实例化成功,更糟的事随后发生,B线程被运行了,他也判断了instance为null,此时A,B都进入了实例化阶段,这样就产生了两个实例,破坏单例原则。

如何解救呢?
作为一个java的开发者,对synchronized一定不陌生,提到多线程,大部分人想到的都是他(JDK6后,他的性能提升巨大,解决简单并发,非常适用)。

那就让我们用synchronized来尝试解决吧:

//由synchronized进行同步加锁
public synchronized static LazySingleton getLazySingleton() {
        if (lazySingleton == null) {
            lazySingleton = new LazySingleton();
        } 
        return lazySingleton;
    }
登录后复制

如此同步问题看似解决,但是作为一个开发者,最重要的是性能的保障,使用synchronized有利有弊,由于加锁操作,代码段被加上悲观锁,只有等一个请求完成,下个请求才能进入执行。通常加上synchronized关键字的代码片会比同等量级的代码慢上几倍,这是我们不愿见到的。那如何避免这一问题呢?在java对synchronized的定义里有这样的建议:越迟使用synchronized,性能越优(细化锁)。

###### 2.因此,我们需要开始解决性能的问题了。按照synchronized优化: ######

public class DoubleCheckLockSingleton {
    //使用volatile保证每次取值不是从缓存中取,而是从真正对应的内存地址中取.(下文解释)
    private static volatile DoubleCheckLockSingleton doubleCheckLockSingleton;
    
    private DoubleCheckLockSingleton(){
        
    }
    
    public static DoubleCheckLockSingleton getDoubleCheckLockSingleton(){
        //配置双重检查锁(下文解释)
        if(doubleCheckLockSingleton == null){
            synchronized (DoubleCheckLockSingleton.class) {
                if(doubleCheckLockSingleton == null){
                    doubleCheckLockSingleton = new DoubleCheckLockSingleton();
                }
            }
        }
        return doubleCheckLockSingleton;
    }
}
登录后复制

上述源码就是经典的volatile关键字(JDK1.5 后重生)+双重检查锁(DoubleCheck),最大程度的优化了sychronized带来的性能开销。下面将为大家解释volatile与DoubleCheck。

1.volatile

是在JDK1.5后才正式被实现使用的,之前的版本只是定义了该关键字,未有具体实现。若想理解volatile就必须对JVM自身的内存管理有些许了解:

1.1 遵循着摩尔定律,内存的读写速度已远不能满足CPU,因此现代计算机引入了在CPU上添加高速缓存的机制,由缓存预读取内存的值,并暂存于缓存中,通过计算,再更新内存中的相应值。

**1.2** 而JVM模仿PC的这一做法,在内存中划分了自己的**工作内存**,该部分内存作用与高速缓存一致,很显著的提高JVM工作效率,但凡事都有利有弊,这一做法也导致工作内存与其他内存通信时容易导致传输上的问题。volatile的一个功能就是强制的从内存中读取最新的值,避免缓存与内存不一致的状况。

1.3 volatile的另一个功能也是和JVM相关,即JVM会通过自身的判断,将源码的执行顺序重排,保证指令流水线连贯性,以达到最优的执行方案。这种做法提高了性能,但对DoubleCheck却会产生意想外的结果,两线程可能互相干扰。而volatile提供了happens-before guarantee(写优先于读),使对象不被干扰,保证安全的稳定性。

2.DoubleCheck

这是现代编程的遗留,假设进入同步块之后,对象已被实例化,此时需再次进行判断。

当然还有一种官方推荐的单例实现方法

由于类的构造在定义中已是原子性的,因此上述的各种问题都不会再产生,是一种很好的单例实现方式,推荐使用。

//使用内部类进行单例构造
public class NestedClassSingleton {
    private NestedClassSingleton(){
        
    }
    private static class SingletonHolder{
        private static final NestedClassSingleton nestedClassSingleton = new NestedClassSingleton();
    }
    public static NestedClassSingleton getNestedClassSingleton(){
        return SingletonHolder.nestedClassSingleton;
    }
}
登录后复制

以上是并发中单例模式的详细介绍(附代码)的详细内容。更多信息请关注PHP中文网其他相关文章!

相关标签:
来源:segmentfault.com
本站声明
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
作者最新文章
最新问题
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责声明 Sitemap
PHP中文网:公益在线PHP培训,帮助PHP学习者快速成长!