单例模式中的懒汉式以及线程安全性问题

先看代码:

package com.roocon.thread.t5;

public class Singleton2 {

    private Singleton2(){

    }

    private static Singleton2 instance;

    public static Singleton2 getInstance(){
        if(instance == null) {//1:读取instance的值
            instance = new Singleton2();//2: 实例化instance
        }
        return instance;
    }

}
package com.roocon.thread.t5;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class MultiThreadMain {
    public static void main(String[] args) {
        ExecutorService threadPool = Executors.newFixedThreadPool(20);
        for (int i = 0; i< 20; i++) {
            threadPool.execute(new Runnable() {
                @Override
                public void run() {
                    System.out.println(Thread.currentThread().getName()+":"+Singleton2.getInstance());
                }
            });
        }
     threadPool.shutdown();
} }

运行结果:

pool-1-thread-4:[email protected]
pool-1-thread-14:[email protected]
pool-1-thread-10:[email protected]
pool-1-thread-8:[email protected]
pool-1-thread-5:[email protected]
pool-1-thread-12:[email protected]
pool-1-thread-1:[email protected]
pool-1-thread-9:[email protected]
pool-1-thread-6:[email protected]
pool-1-thread-2:[email protected]
pool-1-thread-16:[email protected]
pool-1-thread-3:[email protected]
pool-1-thread-17:[email protected]
pool-1-thread-13:[email protected]
pool-1-thread-18:[email protected]
pool-1-thread-7:[email protected]
pool-1-thread-20:[email protected]
pool-1-thread-11:[email protected]
pool-1-thread-15:[email protected]
pool-1-thread-19:[email protected]

发现,有个实例是[email protected],也就说明,返回的不是同一个实例。这就是所谓的线程安全问题。

解释原因:对于以上代码注释部分,如果此时有两个线程,线程A执行到1处,读取了instance为null,然后cpu就被线程B抢去了,此时,线程A还没有对instance进行实例化。

因此,线程B读取instance时仍然为null,于是,它对instance进行实例化了。然后,cpu就被线程A抢去了。此时,线程A由于已经读取了instance的值并且认为它为null,所以,

再次对instance进行实例化。所以,线程A和线程B返回的不是同一个实例。

那么,如何解决呢?

1.在方法前面加synchronized修饰。这样肯定不会再有线程安全问题。

package com.roocon.thread.t5;

public class Singleton2 {

    private Singleton2(){

    }

    private static Singleton2 instance;

    public static synchronized Singleton2 getInstance(){
        if(instance == null) {//1
            instance = new Singleton2();//2
        }
        return instance;
    }

}

但是,这种解决方式,假如有100个线程同时执行,那么,每次去执行getInstance方法时都要先获得锁再去执行方法体,如果没有锁,就要等待,耗时长,感觉像是变成了串行处理。因此,尝试其他更好的处理方式。

2. 加同步代码块,减少锁的颗粒大小。我们只对可能出现线程安全的代码进行同步代码块的处理。

package com.roocon.thread.t5;

public class Singleton2 {

    private Singleton2(){

    }

    private static Singleton2 instance;

    public static synchronized Singleton2 getInstance(){
        if(instance == null) {
            synchronized (Singleton2.class){
                instance = new Singleton2();
            }
        }
        return instance;
    }

}

但是,这样处理就没有问题了吗?同样的原理,线程A和线程B,线程A读取instance值为null,此时cpu被线程B抢去了,线程B再来判断instance值为null,于是,它开始执行同步代码块中的代码,对instance进行实例化。此时,线程A获得cpu,由于线程A之前已经判断instance值为null,于是开始执行它后面的同步代码块代码。它也会去对instance进行实例化。

这样就导致了还是会创建两个不一样的实例。

那么,如何解决上面的问题。

很简单,在同步代码块中instance实例化之前进行判断,如果instance为null,才对其进行实例化。这样,就能保证instance只会实例化一次了。也就是所谓的双重检查加锁机制。

再次分析上面的场景:

线程A和线程B,线程A读取instance值为null,此时cpu被线程B抢去了,线程B再来判断instance值为null。于是,它开始执行同步代码块代码,对instance进行了实例化。这是线程A获得cpu执行权,当线程A去执行同步代码块中的代码时,它再去判断instance的值,由于线程B执行完后已经将这个共享资源instance实例化了,所以instance不再为null,所以,线程A就不会再次实行实例化代码了。

package com.roocon.thread.t5;

public class Singleton2 {

    private Singleton2(){

    }

    private static Singleton2 instance;

    public static synchronized Singleton2 getInstance(){
        if(instance == null) {
            synchronized (Singleton2.class){
                if (instance == null){
                    instance = new Singleton2();
                }
            }
        }
        return instance;
    }

}

但是,双重检查加锁并不代码百分百一定没有线程安全问题了。因为,这里会涉及到一个指令重排序问题。以上代码其实可以总结为下面的步骤:

1.申请一块内存空间;

2.如果instance为null,在这块空间里实例化对象;

3.instance的引用指向这块空间地址;

指令重排序存在的问题是:

对于以上步骤,指令重排序很有可能不是按上面123步骤依次执行的。比如,先执行1申请一块内存空间,然后执行3步骤,instance的引用去指向刚刚申请的内存空间地址,那么,当它再去执行2步骤,判断instance时,由于instance已经指向了某一地址,它就不会再为null了,因此,也就不会实例化对象了。这就是所谓的指令重排序安全问题。那么,如何解决这个问题呢?

加上volatile关键字,因为volatile可以禁止指令重排序。

package com.roocon.thread.t5;

public class Singleton2 {

    private Singleton2(){

    }

    private static volatile Singleton2 instance;

    public static synchronized Singleton2 getInstance(){
        if(instance == null) {
            synchronized (Singleton2.class){
                if (instance == null){
                    instance = new Singleton2();
                }
            }
        }
        return instance;
    }

}
时间: 2024-08-30 15:57:49

单例模式中的懒汉式以及线程安全性问题的相关文章

Java中primitive type的线程安全性

Java中primite type,如char,integer,bool之类的,它们的读写操作都是atomic的,但是有几个例外: long和double类型不是atomic的,因为long和double都是8字节的,而在32位的CPU上,其机器字长为32位,操作8个字节需要多个指令操作. ++i或者i++,因为要先读后写,也是多步操作. 这些情况下,需要使用AutomicInteger,AutomicLong. 同时,java中的reference的读写也是automic的,虽然referen

关于java中final关键字与线程安全性

在Java5中,final关键字是非常重要而事实上却经常被忽视其作为同步的作用.本质上讲,final能够做出如下保证:当你创建一个对象时,使用final关键字能够使得另一个线程不会访问到处于"部分创建"的对象,否则是会可能发生的.这是 因为,当用作对象的一个属性时,final有着如下的语义: 当构造函数结束时,final类型的值是被保证其他线程访问该对象时,它们的值是可见的 为什么是必须的 使用final是所谓的安全发布(safe publication)的一种方式,这里,发布(pub

单例模式的线程安全性

单例模式是设计模式中比较简单的一种.适合于一个类只有一个实例的情况,比如窗口管理器,打印缓冲池和文件系统, 它们都是原型的例子.典型的情况是,那些对象的类型被遍及一个软件系统的不同对象访问,因此需要一个全局的访问 指针,这便是众所周知的单例模式的应用. 经典的单例模式有三种,懒汉式.饿汉式和懒汉式单例模式改进式 "懒汉式"是在你真正用到的时候才去建这个单例对象,所以是线程不安全的 懒汉式如果在创建实例对象时不加上synchronized则会导致对对象的访问不是线程安全的.   测试懒汉

单例模式的写法和线程安全性的讨论

//饿汉模式:单例模式,就是无论用不用,什么时候用,在类加载的时候就实例化一个这个类的对象 //然后等到使用的时候,就是使用同一个实例对象 //好处:在多线程的环境下使用这种方法,可以避免多线程带来的冲突.与之相对应的是,懒汉模式(按需实例化) class Singleton1{ private Singleton1(){} private static Singleton1 s1 = new Singleton1(); public static Singleton1 getSingleton

单例模式:Qt本身就提供了专门的宏 Q_GLOBAL_STATIC 通过这个宏不但定义简单,还可以获得线程安全性

标题起的是有点大 主要是工作和学习中,遇到些朋友,怎么说呢,代码不够Qt化 可能是由于他们一开始接触的是 Java MFC 吧 接触 Qt 7个年头了 希望我的系列文章能抛砖引玉吧 单例模式 很多人洋洋洒洒写了一大堆 比如这里 http://xtuer.github.io/qtbook-singleton/ 比如这里 http://m.blog.csdn.net/Fei_Liu/article/details/69218935 但是Qt本身就提供了专门的宏 Q_GLOBAL_STATIC 通过这

一天一个设计模式——(Singleton)单例模式(线程安全性)

一.模式说明 有时候,我们希望在应用程序中,仅生成某个类的一个实例,这时候需要用到单例模式. 二.模式类图 三.模式中的角色 Singleton角色,该模式中仅有的一个角色,该角色有一个返回唯一实例的getInstance方法,该方法总是返回同一个实例: 四.代码示例 单例模式比较简单,要实现单例模式只需保证三点: 私有化类的构造函数: 在类中创建类的对象: 提供获取对象的公有方法: package com.designpattern.cn.singletonpattern; public cl

单例模式中的线程安全(延迟加载)

设计模式中常用的单例模式,在jvm中可以保证该对象只有一个实例存在.这样对于一些特别大的对象,可以很好的节省资源.由于省去了new,所以节省了gc消耗.同时,对于一些核心系统逻辑,可以能要一个对象实例来控制会省去很多麻烦. 单例模式,如果不考虑多线程,则可以如下创建 public class Singleton { /* 持有私有静态实例,防止被引用,此处赋值为null,目的是实现延迟加载 */ private static Singleton instance = null; /* 私有构造方

Java线程安全性中的对象发布和逸出

发布(Publish)和逸出(Escape)这两个概念倒是第一次听说,不过它在实际当中却十分常见,这和Java并发编程的线程安全性就很大的关系. 什么是发布?简单来说就是提供一个对象的引用给作用域之外的代码.比如return一个对象,或者作为参数传递到其他类的方法中. 什么是逸出?如果一个类还没有构造结束就已经提供给了外部代码一个对象引用即发布了该对象,此时叫做对象逸出,对象的逸出会破坏线程的安全性. 概念我们知道了,可我们要关注什么地方呢?我们要关注的时候就是逸出问题,在不该发布该对象的地方就

Spring中如何获取request的方法汇总及其线程安全性分析

前言 本文将介绍在Spring MVC开发的web系统中,获取request对象的几种方法,并讨论其线程安全性.下面话不多说了,来一起看看详细的介绍吧. 概述 在使用Spring MVC开发Web系统时,经常需要在处理请求时使用request对象,比如获取客户端ip地址.请求的url.header中的属性(如cookie.授权信息).body中的数据等.由于在Spring MVC中,处理请求的Controller.Service等对象都是单例的,因此获取request对象时最需要注意的问题,便是