JVM线程安全与锁优化

Posted 天道酬勤

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM线程安全与锁优化相关的知识,希望对你有一定的参考价值。

线程安全

《Java Concurrency In Practice》的作者Brian Goetz对线程安全的定义:当多个线程访问一个对象时,如果不用老驴这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象是线程安全的。

Java语言中的线程安全

按照线程安全的“安全程度”由强至弱排序,可以将Java语言中各种操作共享的数据分为5类:不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

  1. 不可变

    在Java语言中,不可变的对象一定是线程安全的,无论是对象的方法实现还是方法的调用者,都不需要再采取任何的线程安全保障措施。如果共享数据是一个基本数据类型,那么只要在定义时使用final关键字修饰就可以保证是不可变的。如果共享的是一个对象,那就需要保证对象的行为不会对其状态产生任何影响才行,例如java.lang.String类。

  2. 绝对线程安全

    绝对的线程安全完全满足Brian Goetz给出的线程安全的定义,一个类要达到“不管运行时环境如何,调用者都不需要任何额外的同步措施”通常需要付出很大的。甚至是不切实际的代价。

  3. 相对线程安全

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

  4. 线程兼容

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

  5. 线程对立

    线程对立是指无论调用端是否采取了同步措施,都无法在多线程环境中并发使用的代码。例如:Thread类的suspend()方法和resume()方法,如果有两个线程同时持有一个线程对象,一个尝试中断线程,另一个尝试恢复线程,如果并发执行的话,无论调用时是否进行了同步,目标线程都存在死锁的风险。

线程安全的实现方法

  • 互斥同步

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

    在Java中,最基本的互斥同步手段就是synchronized关键字,synchronized关键字经过编译之后,会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令,这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象。在虚拟机规范对monitorenter和monitorexit的行为描述中,synchronized同步块对同一条线程来说是可重入的,不会出现自己把自己锁死的问题。同步块在已进入的线程执行完之前,会阻塞后面其他线程的进入。

    除了synchronized之外,还可以使用java.util.concurrent包中的重入锁(ReentrantLock)来实现同步。相比synchronized相比,ReentrantLock增加了一些高级功能,主要有3项:等待可中断、可实现公平锁、以及锁可以绑定多个条件。

    • 等待可中断是指当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他事情,可中断特性对处理执行时间非常长的同步块有帮助。
    • 公平锁是指多个线程在等待同一个锁时,必须按照申请锁的时间顺序来依次获得锁;而非公平锁则不保证这一点,在锁被释放时,任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的,ReentrantLock默认情况下也是非公平的,但可以通过带有布尔值的构造函数要求使用公平锁。
    • 锁绑定多个条件是指一个ReentrantLock对象可以同时绑定多个Condition对象,而在synchronized中,锁对象的wait()和notify()或notifyAll()方法可以实现一个隐含的条件,如果要和多余一个的条件关联的时候,就不得不额外地添加一个锁,而ReentrantLock则无需这样做,只需要多次调用newCondition()方法即可。
  • 非阻塞同步

    互斥同步最主要地问题就是进行线程阻塞和唤醒所带来地性能问题,因此这种同步也成为阻塞同步。随着硬件指令集地发展,我们有了另外一种选择,基于冲突检测的乐观并发策略,通俗的说,就是先进行操作,如果没有其他线程争用共享数据,那操作就成功了;如果共享数据有争用,产生了冲突,那就再采取其他的补偿措施,这种乐观的并发策略的许多实现都不需要把线程挂起,因此这种同步操作称为非阻塞同步。

    CAS指令:
    CAS指令需要有3个操作数,分别是内存位置(在Java中可以简单理解为变量的内存地址、用V表示)、旧的预期值(用A表示)和新值(用B表示)。CAS指令执行时,当且仅当V符合旧预期值A时,处理器用新值B更新V的值,否则它就不执行更新,但是无论是否更新了V的值,都会返回V的旧值,这个处理过程是一个原子操作。

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

  • 无同步方案

    如果一个方法本来就不涉及共享数据,那它自然就无须任何同步措施去保证正确性,因此会有一些代码天生就是线程安全的。

    • 可重入代码

      如果一个方法,它的返回结果是可预测的,只要输入了相同的数据,就都能返回相同的结果,那它就满足可重入的要求,就是线程安全的。

    • 线程本地存储

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

锁优化

自旋锁与自适应锁

互斥同步对性能影响最大的是阻塞的实现,挂起线程和恢复线程的操作都需要转入内核态中完成,这些操作给系统的并发性能带来了很大的压力。同时,虚拟机的开发团队也注意到在许多应用上,共享数据的锁定状态只会持续很短的一段时间,为了这段时间去挂起和恢复线程并不值得。如果物理机器上有一个以上的处理器,能让两个或以上的线程同时并行执行,我们就可以让后面的请求锁的那个线程“稍等一下”,但不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁。为了让线程等待,我们只需要让线程执行一个忙循环,这项技术就是所谓的自旋锁。

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

锁消除

锁消除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除。

锁粗化

原则上,在编写代码的时候,总是推荐将同步块的作用范围限制得尽量小——只在共享数据的实际作用域中才进行同步,这样是为了使得需要同步的操作数量尽可能变小,如果存在锁竞争,那等待的线程也能尽快拿到锁。大部分情况下,这个原则是正确的,但是如果一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗。如果虚拟机探测到有这样一串零碎的操作都对同一个对象加锁,将会把锁同步范围扩展(粗化)到整个操作序列的外部。

以上是关于JVM线程安全与锁优化的主要内容,如果未能解决你的问题,请参考以下文章

JVM学习记录-线程安全与锁优化

JVM学习记录-线程安全与锁优化

JVM:线程安全与锁优化(十三)

线程安全与锁优化

线程安全与锁优化

线程安全与锁优化