JAVA-初步认识-第十三章-单例模式涉及的多线程问题

Posted 照破山河万朵

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JAVA-初步认识-第十三章-单例模式涉及的多线程问题相关的知识,希望对你有一定的参考价值。

一.

单例设计模式之前在谈论的时候,有一部分涉及线程的问题,因此只讲述了一半。现在将其重新描述一下。

单例分为两种表现形式,懒汉和饿汉。

二. 

多线程下的单例:饿汉式

懒汉式(延迟加载单例设计模式)

什么时候用到这个对象,再加载它。这个例子并不准备运行,知道就可以。

现在准备将其结合到多线程基础上来,来思考另外一部分内容,叫在多线程情况下,有没有安全隐患。

 如果上图的getInstance()方法加入到run方法当中,意味着它将被多线程所执行。多线程执行的时候,涉及到了共享数据(return s),也就是说s是共享数据。它存不存在安全问题呢?它不存在,因为它只有一句,谁来都是返回,都是同一个地址,这是不存在的。而且这里的s已经被final了,固定不变了。这个是没有太大问题的,这是所说的饿汉式。

现在再看一下懒汉式,如果getInsatance放到了run方法当中,就意味着可以被多线程所执行,它有没有安全隐患呢?

我们分析,getInstance方法体中的语句作为多线程运行代码的话,在代码当中有没有共享数据?有的,s就是。有没有多条操作s的语句?有的。

有没有安全问题,验证一下就知道了,不准备通过运行验证,直接分析。核心在于同步的问题。

线程0进来了,s==null么,满足。这时线程0被切换走了,也就是失去了cpu执行权。线程1就进来了,判断s==null么?满足,线程1也切换走了。(这可能么?是可能的,符合cpu随意切换) 这时,0线程获得执行权了,执行了,现在s有对象了,返回了。紧跟着,1线程获取了执行权,根本就不用判断了,直接s=new Single();这时内存中两个对象了,无法保证对象的唯一性了,这就是问题。

问题分析完了,现在怎么解决?

加同步即可。加上synchronized关键字后,第一个线程进来,s是空。即使该线程失去执行权,其他线程也进不来,等到该线程睡醒得到执行权后,继续执行下面的语句,new对象,返回值,最后退出。第二个线程接着进来,一判断s不为空,没事直接拿取这个s就可以了。这就解决问题了。线程安全问题,加了一个synchronized解决了。还没完,多线程在访问的时候,只要有第一个线程进来,它就创建对象了,其他线程过来拿这个对象的时候,它们都要判断锁。在判断s==null之前,还要多判断一下锁。因此,每次拿这个对象前,都要判断这个锁(可能和一定要执行getInstance方法有关),效率比较低。因此,我们说加同步解决线程安全问题,但是降低了效率。为了提高效率,我们准备把代码进行一下改写。

按照以前的写法,synchronized()的括号里写this,但是这里不行。这里是静态的,无法通过该类创建对象,只能是Single.class。

有人说getClass行不行,这不行。写this.getClass也不行,这是一回事。因为getClass方法是非静态的。

用同步代码块和同步函数有区别么?没区别,线程进来后,还是要判断锁,synchronized(Single.class)。

现在修改一下程序,

相当于在进行锁的判断前,先进行了一步判断筛选。

怎么理解呢?视频中是这样设计的,0线程和1线程同时位于synchronized语句前面,if第一次判断的后面。0线程进入同步代码块之后,无论是保有cpu的执行权,还是失去cpu的执行权,1线程都进不来。0线程创建完对象退出后,1线程进来经过判断不符合直接退出。而其它线程在进入getInstance函数后,由于if的第一次判断就不满足,就不用执行同步代码块了,提高了效率。(难道就没有更多的线程集中在synchronized的前面么?这样一来效率就没有提高多少了)

这种双重判断的形式,来解决懒汉式的安全问题和效率问题。这样对比下来,写饿汉式更好,更简单。

面试的时候,会集中在懒汉式。

一般来说,同步函数的锁是this,但是静态函数的锁就不是。

 

以上是关于JAVA-初步认识-第十三章-单例模式涉及的多线程问题的主要内容,如果未能解决你的问题,请参考以下文章

JAVA-初步认识-第十三章-同步的前提

JAVA-初步认识-第十三章-死锁示例

JAVA-初步认识-第十二章-JVM中的多线程分析

“全栈2019”Java多线程第十三章:线程组ThreadGroup详解

JAVA-初步认识-第十二章-多线程运行图解

JAVA学习第二十五课(多线程)- 单例设计模式涉及的多线程问题