深入理解Java虚拟机 ch13 线程安全和锁优化 读书笔记

part 5 高效并发

  本部分是本书的最后一个部分,分两个章节。其中,第12章讲Java并发处理的基础——Java内存模型。从物理机模型出发,分析其设计思路和问题,引入Java内存模型以及其针对并发的设计细节。最后,说明了Java中多线程的实现,线程调度以及线程状态转换图。

  第13章则是讲并发的正确性——线程安全和高效性——锁优化。正确性是前提,高效性是追求。本章的内容是建立在Java内存模型基础上的。

ch13 线程安全和锁优化

  Java的并发性大多是通过多线程来实现的。上一章讲述了ava并发处理的基础——Java内存模型以及Java线程的有关知识。本章则在上章内容的基础上真正去实现高效并发。本章涉及两个主题,并发的正确性——线程安全和高效型——锁优化。

一 线程安全

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

  这个定义比较严谨,它要求线程安全的代码都必须具备一个特征:代码本身封装了所有必要的正确性保障手段(如互斥同步等),令调用者无须关心多线程的问题,更无须自己采取任何措施来保证多线程的正确调用。

1.1 Java语言中的线程安全

  我们这里讨论的线程安全,就限定于多个线程之间存在共享数据访问这个前提,因为如果一段代码根本不会与其他线程共享数据,那么其肯定为线程安全的,参照上章的先行发生原则。

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

1.不可变

  在Java语言中,不可变(Immutable)的对象一定是线程安全的,无论是对象的方法实现还是方法的调用者,都不需要再采取任何的线程安全保障措施。“不可变”带来的安全性是最简单和最纯粹的。

  Java语言中,如果共享数据是一个基本数据类型,那么只要在定义时使用final关键字修饰它就可以保证它是不可变的。如果共享数据是一个对象,那就需要保证对象的行为不会对其状态产生任何影响才行(因为Java不像C++有const可以保证其对象本身不可变,只能靠对象内部实现)。

  保证对象行为不影响自己状态的途径有很多种,其中最简单的就是把对象中带有状态的字段都声明为final,这样在构造函数结束之后,它就是不可变的。比如String类,Integer类等等。

2.绝对线程安全

  这里的绝对线程安全是指满足上述Goetz定义的线程安全。在这里,作者并未给出绝对线程安全的例子,只是指出在Java API中标注自己是线程安全的类,大多数都不是绝对的线程安全。由此可以看出,绝对线程安全的定义是很严格的。作者用的Vector的示例去说明Java中的线程安全类并非绝对安全的,然而在JDK1.8和Eclipse IDE情况下,可以正常运行,这里便不贴代码了。

3.相对线程安全

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

  在Java语言中,大部分的线程安全类都属于这种类型,例如Vector、HashTable、Collections的synchronizedCollection()方法包装的集合等。

4.线程兼容

  线程兼容是指对象本身并不是线程安全的,但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中可以安全地使用,我们平常说一个类不是线程安全的,绝大多数时候指的是这一种情况。Java API中大部分的类都是属于线程兼容的,如与前面的Vector和HashTable相对应的集合类ArrayList和HashMap等。

5.线程对立

  线程对立是指无论调用端是否采取了同步措施,都无法在多线程环境中并发使用的代码。由于Java语言天生就具备多线程特性,线程对立这种排斥多线程的代码是很少出现的,而且通常都是有害的,应当尽量避免。这种情况很少,一般不会遇到,可忽略。

  上述所讲的五种类型的共享数据,除了第二种和第五种,其他三种都有对应的例证。其中,第五种一般不会遇到,第三种可能已经被优化为第二种。在现实编程时,还是很容易进行对照验证的。

1.2 线程安全的三个实现方法

  实现线程安全从虚拟机的角度来说就是同步与锁机制。通过了解在虚拟机层次是如何实现线程安全,可以帮助更好的写出线程安全的代码来。下面介绍实现线程安全的三个方法。

1.2.1 互斥同步

  首先需要说明,互斥同步里,同步是目的,互斥是手段;也就是通过互斥的方式实现同步。

  同步:多个线程共享数据时,保证共享数据在同一个时刻只被一个(或是一些,使用信号量时)线程使用。

  互斥:实现同步的手段,主要有临界区互斥量信号量等手段。

  Java中,实现互斥同步的方案有两种,一种是synchronized关键字,为原生语法层面的互斥锁;另一个是concurrent包中的ReentrantLock(可重入锁),为API层面的互斥锁。一般情况下,使用synchronized关键字即可,但涉及ReentrantLock独有的三个高级特性时,应选用ReentrantLock

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

  2. 公平锁是指多个线程在等待同一个锁时,必须按照申请锁的时间顺序来依次获得锁;而非公平锁则不保证这一点,在锁被释放时,任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非公平的,ReentrantLock默认情况下也是非公平的,但可以通过带布尔值的构造函数要求使用公平锁。

  3. 锁绑定多个条件是指一个ReentrantLock对象可以同时绑定多个Condition对象,而在synchronized中,锁对象的wait()和notify()或notifyAll()方法可以实现一个隐含的条件,如果要和多于一个的条件关联的时候,就不得不额外地添加一个锁,而ReentrantLock则无须这样做,只需要多次调用newCondition() 方法即可。

  需要说明的是,互斥同步在实现时,会阻塞其他线程的实现,而阻塞和唤醒的过程都涉及到状态转换,很耗时。该方法是重量级同步措施,也是锁优化的一个重点。

1.2.2 非阻塞同步

  互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能问题,因此这种同步也称为阻塞同步。从处理问题的方式上说,互斥同步属于一种悲观的并发策略,总是认为只要不去做正确的同步措施(例如加锁),那就肯定会出现问题,无论共享数据是否真的会出现竞争,它都要进行加锁、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要唤醒等操作。

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

  在这里,需要操作冲突检测这两个步骤具备原子性。如果使用互斥同步来保证就失去意义了,所以只能靠硬件来完成这件事情,硬件保证一个从语义上看起来需要多次操作的行为只通过一条处理器指令就能完成,这类指令常用的有:

  1. 测试并设置(Test-and-Set)

  2. 获取并增加(Fetch-and-Increment)

  3. 交换(Swap)

  4. 比较并交换(Compare-and-Swap,CAS)

  5. 加载链接/条件存储(Load-Linked/Store-Conditional)

  其中,后面的两条是现代处理器新增的,而且这两条指令的目的和功能是类似的。Java正是通过CAS操作实现了非阻塞同步。CAS指令需要有3个操作数,分别是内存位置(在Java中可以简单理解为变量的内存地址,用V表示)、旧的预期值(用A表示)和新值(用B表示)。CAS指令执行时,当且仅当V符合旧预期值A时,处理器用新值B更新V的值,否则它就不执行更新,但是无论是否更新了V的值,都会返回V的旧值,上述的处理过程是一个原子操作。

  尽管CAS看起来很美,但显然这种操作无法涵盖互斥同步的所有使用场景,并且CAS从语义上来说并不是完美的,存在这样的一个逻辑漏洞:如果一个变量V初次读取的时候是A值,并且在准备赋值的时候检查到它仍然为A值,那我们就能说它的值没有被其他线程改变过了吗?如果在这段期间它的值曾经被改成了B,后来又被改回为A,那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的ABA问题。如果需要解决ABA问题,改用传统的互斥同步可能会比原子类更高效。

1.2.3 无同步方案

  下面介绍两类无需任何同步措施就天生安全的代码:

  可重入代码:这种代码也叫做纯代码,可以在代码执行的任何时刻中断它,转而去执行另外一段代码(包括递归调用它本身),而在控制权返回后,原来的程序不会出现任何错误。相对线程安全来说,可重入性是更基本的特性,它可以保证线程安全,即所有的可重入的代码都是线程安全的,但是并非所有的线程安全的代码都是可重入的。

  可重入代码有一些共同的特征,例如不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数中传入、不调用非可重入的方法等。我们可以通过一个简单的原则来判断代码是否具备可重入性:如果一个方法,它的返回结果是可以预测的,只要输入了相同的数据,就都能返回相同的结果,那它就满足可重入性的要求,当然也就是线程安全的,如Math类的很多方法。

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

  符合这种特点的应用并不少见,大部分使用消费队列的架构模式(如“生产者-消费者”模式)都会将产品的消费过程尽量在一个线程中消费完,其中最重要的一个应用实例就是经典Web交互模型中的“一个请求对应一个服务器线程”(Thread-per-Request)的处理方式,这种处理方式的广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题。

  Java语言中,如果一个变量要被多线程访问,可以使用volatile关键字声明它为“易变的”;如果一个变量要被某个线程独享,可以通过java.lang.ThreadLocal类来实现线程本地存储的功能。每一个线程的Thread对象中都有一个ThreadLocalMap对象,这个对象存储了一组以ThreadLocal.threadLocalHashCode为键,以本地线程变量为值的K-V值对,ThreadLocal对象就是当前线程的ThreadLocalMap的访问入口,每一个ThreadLocal对象都包含了一个独一无二的threadLocalHashCode值,使用这个值就可以在线程K-V值对中找回对应的本地线程变量。

二 锁优化

  上一节讲到为了实现线程安全的同步措施。但是要知道,哪怕是非阻塞同步,与不同步比,都有着较大的性能损耗。本节的核心内容是如何以最小的代价实现线程安全;体现到实际,就是对已有的同步措施进行优化,以去除不必要的性能消耗。

  高效并发是从JDK 1.5到JDK 1.6的一个重要改进,HotSpot虚拟机开发团队在这个版本上花费了大量的精力去实现各种锁优化技术,这些技术都是为了在线程之间更高效地共享数据,以及解决竞争问题,从而提高程序的执行效率,下面将对这些技术进行一一讲解。

2.1 自旋锁和自适应锁

  自旋锁:在互斥同步时,为避免阻塞,让后申请锁的线程去等待而不是挂起。等待的方式是让该线程去执行一个忙循环(自旋),所以称为自旋锁。

  分析:避免了线程切换开销,但占用处理器时间。所以,自旋次数的设置很关键。设置不好反而会造成更大的性能损耗。这里默认是10次,可以自己根据需要修改。

  自适应锁:自适应锁的自旋次数由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。有了自适应自旋,随着程序运行和性能监控信息的不断完善,虚拟机对程序锁的状况预测就会越来越准确。

2.2 锁消除

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

  主要判定依据逃逸分析的数据支持。如果判断在一段代码中,堆上的所有数据都不会逃逸出去从而被其他线程访问到,那就可以把它们当做栈上数据对待,认为它们是线程私有的,同步加锁自然就无须进行。

  这里需要说明的是,很多同步措施是javac编译器自动添加的,比如String连接操作等。锁消除通过对这些同步进行消除,可以提高性能,避免不必要的浪费。

2.3锁粗化

  锁粗化:对一串零碎的操作都对同一个对象加锁这种现象,JVM将会把加锁同步的范围扩展(粗化)到整个操作序列的外部,即为锁粗化。

  应用场景:一系列的连续操作都对同一个对象反复加锁和解锁,甚至加锁操作是出现在循环体中的,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗。

2.4 轻量级锁

  轻量级锁:JDK1.6引入,在无多线程竞争的情况下,使用CAS操作去消除同步使用的互斥量

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

  至于实现方式,建议看书或其他博客,这里不再说明。

2.5 偏向锁

  偏向锁:JDK 1.6中引入;它的目的是消除数据在无竞争情况下的同步原语,进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量,那偏向锁就是在无竞争的情况下把整个同步都消除掉,连CAS操作都不做了。

  偏向锁的“偏”,就是偏心的“偏”、偏袒的“偏”,它的意思是这个锁会偏向于第一个获得它的线程,如果在接下来的执行过程中,该锁没有被其他的线程获取,则持有偏向锁的线程将永远不需要再进行同步。

  说明:偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡(Trade Off)性质的优化,也就是说,它并不一定总是对程序运行有利,如果程序中大多数的锁总是被多个不同的线程访问,那偏向模式就是多余的。在具体问题具体分析的前提下,有时候使用参数-XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。

你可能感兴趣的:(Java,Java虚拟机)