线程安全与锁优化

最新推荐文章于 2022-01-15 11:59:06 发布

小锴的学习笔记

最新推荐文章于 2022-01-15 11:59:06 发布

阅读量120

点赞数

分类专栏： JVM 文章标签： JVM

本文链接：https://blog.csdn.net/qq_40925525/article/details/103051418

版权

JVM 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

线程安全与锁优化

并发处理的广泛应用是使得Amdahl定律代替摩尔定律成为计算机性能发展源动力的根本原因,也是人类"压榨"计算机运算能力的最有力武器.

软件行业发展初期,程序编写都是以算法为核心的,程序员会把数据和过程分别作为独立的部分来考虑,数据代表问题空间中的客体,程序代码则用于处理这些数据,这种思维方式直接站在计算机的角度去抽象问题和解决问题,称为面向过程的编程思想.

与此相对的是,面向对象的编程思想是站在现实世界的角度去抽象和解决问题,它把数据和行为都看做是对象的一部分,这样可以让程序员能以符合现实世界的思维方式来编写和组织程序.

线程安全

"当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象是线程安全的"这个定义比较严格和严谨.在大多数场景中,我们都会将这个定义弱化一些.如果把"调用这个对象的行为"限定为"单次调用",我们就可以称它是线程安全的了.

Java语言中的线程安全

我们可以将Java语言中各种操作共享的数据分为以下5类:

不可变.
绝对线程安全.
相对线程安全.
线程兼容.
线程对立.

不可变的对象一定是线程安全的,只要一个不可变对象被正确的构建出来(没有this引用逃逸),那其外部的可见状态永远也不会改变.如果共享数据时一个基本数据类型,那么只要定义时使用final关键字修饰它就可以保证它是不可变的.如果共享数据是一个对象,那就需要保证对象的行为不会对其状态产生任何影响才行.保证对象行为不影响自己状态的途径有很多种,其中最简单的就是把对象中带有状态的变量都声明为final,这样在构造函数结束之后,它就是不可变的.

绝对线程安全完全满足开头所述关于线程安全的定义,这个定义其实很严格,要满足需要付出很大代价,甚至有时候是不切实际的代价,在Java API中标注自己是线程安全的类,大多数都不是绝对的线程安全.如果不在方法调用端做额外的同步措施的话,代码仍然是不安全的.

相对线程安全就是我们通常意义上所讲的线程安全,它需要保证对这个对象单独的操作是线程安全的,我们在调用的时候不需要做额外的保障措施,但是对于一些特定顺序的连续调用,就可能需要在调用端使用额外的同步手段来保证调用的正确性.

线程兼容是指对象本身并不是线程安全的,但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用.如ArrayList和HashMap等.

线程对立是指无论调用端是否采取了同步措施,都无法在多线程环境中并发使用的代码.

线程安全的实现方法

代码编写如何实现线程安全和虚拟机如何实现同步和锁,相对而言这里会更偏重后者一些.

互斥同步

互斥同步是常见的一种并发正确性保障手段.同步是指在多个线程并发访问共享数据时,保证共享数据在同一时刻只被一个(或者是一些,使用信号量的时候)线程使用.而互斥是实现同步的一种手段,临界区,互斥量和信号量都是主要的互斥实现方式.互斥是因,同步是果;互斥是方法,同步是目的.

Java中,最基本的互斥同步手段就是synchronized关键字,如果Java程序中的synchronized明确指定了对象参数,那就使用这个对象的reference作为锁对象;如果没有明确指定,那就根据synchronized修饰的是实例方法还是类方法,去取对应的对象实例或Class对象来作为锁对象.

synchronized对同一条线程来说是可重入的.同步块在已进入的线程执行完之前,会阻塞后面其他线程的进入.如果要阻塞或唤醒一个线程,都需要从用户态转换到核心态中.虚拟机会进行一些优化,譬如在通知操作系统阻塞线程之前加入一段自旋等待过程,避免频繁地切入到核心态之中.

juc包中的重入锁(ReentrantLock)也可以实现同步,也具备可重入的特性,相比synchronized,它增加了一些高级功能,主要有:

等待可中断.
可实现公平锁.
锁可以绑定多个条件.

等待可中断是指当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他事情.适用于处理执行时间非常长的同步块.

公平锁是指多个线程在等待同一个锁时,必须按照申请锁的时间顺序来依次获得锁.ReentrantLock默认情况下也是非公平的,但可以通过构造函数要求使用公平锁.

锁绑定多个条件是指一个ReentrantLock对象可以同时绑定多个Condition对象,只需要多次调用newCondition()方法即可.

如果需要使用上述功能,选用ReentrantLock是一个很好的选择.

非阻塞同步

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题,因此这种同步也称为阻塞同步.同步互斥属于一种悲观的并发策略,总是认为只要不去做正确的同步措施,那就肯定会出现问题,无论共享数据是否真的会出现竞争,它都要进行加锁等操作.

随着硬件指令集的发展,我们有了另外一个选择:基于冲突检测的乐观并发策略,通俗的说,就是先进行操作,如果没有其他线程争用共享数据,那操作就成功了;如果共享数据有争用,产生了冲突,那就再采取其他补偿措施(如不断重试),这种乐观的并发策略的许多实现都不需要把线程挂起,因此这种同步操作称为非阻塞同步.

硬件保证从一个语义上看来需要多次操作的行为只通过一条处理器指令就能完成,这类指令常用的有:

测试并设置
获取并增加
交换
比较并交换(CAS)

CAS指令需要有3个操作数,分别是内存位置(V),旧的预期值(A)和新值(B).CAS指令执行时,当且仅当V符合预期值A时,处理器用新值B更新V的值,否则它就不执行更新,但是无论是否更新了V的值,都会返回V的旧值.这个处理过程是一个原子操作.

CAS的逻辑漏洞:如果一个变量V初次读取的时候是A值,并且在准备赋值的时候检查到它仍然为A值,那我们就能说它的值没有被其他线程改变过了吗?如果在这段期间它的值曾经被改成了B,后来又被改回A,那CAS操作就会误认为它从来没有被改变过.这个漏洞称为CAS的"ABA"问题.

可以通过控制变量的版本来保证CAS的正确性.

大部分情况下ABA问题不会影响程序并发的正确性,如果需要解决ABA问题,改用传统的互斥同步可能会比原子类更高效.

无同步方案

要保证线程安全,并不是一定就要进行同步,有一些代码天生就是线程安全的.

可重入代码:这种代码也叫纯代码,可以在代码执行的任何时刻中断它,转而去执行另外一段代码(包括递归调用它本身),而在控制权返回后,原来的程序不会出现任何错误.

可重入代码的特征:不依赖存储在堆上的数据和公用的系统资源,用到的状态量都由参数中传入,不调用非可重入的方法等.

判断代码是否具备可重入性:如果一个方法,它的返回结果是可以预测的,只要输入了相同的数据,就都能返回相同的结果,那它就满足可重入性的要求,当然也就是线程安全的.

线程本地存储:如果一段代码中所需要的数据必须与其他代码共享,那就看看这些共享数据的代码是否能保证在同一个线程中执行?如果能保证,我们就可以把共享数据的可见范围限制在同一个线程之内,这样,无须同步也能保证线程之间不出现数据争用的问题.

可以通过java.lang.ThreadLocal类来实现线程本地存储的功能.每一个线程的Thread对象中都有一个ThreadLocalMap对象,这个对象存储了一组以ThreadLocal.threadLocalHashCode为键,以本地线程变量为值的K-V值对.ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口,每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值,使用这个值就可以在线程K-V值对中找回对应的本地线程变量.

锁优化

自旋锁与自适应自旋

在许多应用上,共享数据的锁定状态只会持续很短的一段时间,为了这段时间去挂起和恢复线程并不值得.如果物理机器有一个以上的处理器,能让两个或以上的线程同时并行执行,我们就可以让后面请求锁的那个线程"稍等一下",但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁.为了让线程等待,我们只需让线程执行一个忙循环(自旋),这项技术就是所谓的自旋锁.

自旋等待本身虽然避免了线程切换的开销,但它是要占用处理器时间的,如果锁被占用的时间很短,自旋等待的效果就会非常好,反之,如果锁被占用的时间很长,那么自旋的线程只会白白消耗处理器资源.反而会带来性能上的浪费.

自适应的自旋锁意味着自旋的时间不再固定了,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定.如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行中,那么虚拟机就会认为这次自旋也很有可能再次成功,进而它将允许自旋等待持续相对更长的时间.如果对于某个锁,自旋很少成功获得过,那在以后要获取这个锁时将可能省略掉自旋过程,以避免浪费处理器资源.JDK1.6中默认开启.

锁消除

锁消除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除.锁消除的主要判定依据来源于逃逸分析的数据支持.

锁粗化

原则上,我们在编写代码的时候,总是推荐将同步块的作用范围限制的尽量小,只在共享数据的实际作用域中才进行同步,这样是为了使得需要同步的操作数量尽可能变小,如果存在锁竞争,那等待锁的线程也能尽快拿到锁.

大部分情况下,上面的原则都是正确的,但是如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中的,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗.

如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁,将会把加锁同步的范围扩展(粗化)到整个操作序列的外部,这样就只需要加锁一次就可以了.

轻量级锁

轻量级锁能提升程序同步性能的依据是"对于绝大部分的锁,在整个同步周期内都是不存在竞争的",这是一个经验数据,如果没有竞争,轻量级锁使用CAS操作避免了使用互斥量的开销,但如果存在锁竞争,除了互斥量的开销外,还额外发生了CAS操作,因此在有竞争的情况下,轻量级锁会比传统的重量级锁更慢.