【JVM】线程安全与锁优化
《Java Concurrency In Practice》
中Brian Goetz
:当多个线程访问同一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替执行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获取正确的结果,那这个对象就是线程安全的。
但这个定义很严格,一般情况下很难达到这种要求。
Java语言中的线程安全
讨论线程安全,就限定于多个线程之间存在共享数据的访问这个前提,因为如果一段代码根本不会与其他线程进行共享数据,那么从线程安全的角度看,程序是串行执行还是多线程执行对它来说是完全没有区别的。
按照线程安全的安全程度由强至弱的顺序,可以将Java语言中的各种操作共享的数据分为以下5类。
-
不可变
不可变(Immutable)对象一定是线程安全的,无需采取任何线程安全保障措施。 -
对一个基本数据类型,使用final关键字修饰,它就是不可变的。
-
对一个对象,则需要保证对象的行为不会对其状态产生任何影响:保证对象行为不影响自己状态的最简单的途径就是把对象中带有状态的变量都声明为final。
在Java API中符合不可变要求的类型有:String
、枚举类型、java.lang.Number
的部分子类(Long
和Double
等数值包装类,BigInteger
和BigDecimal
等大数据类型,但AtomicInteger
和AtomicLong
并非不可变)。 -
绝对线程安全
绝对安全的线程的类,完全符合Brian Goetz
的定义,但在Java API中标注自己是线程安全的类,大多数都不是绝对的线程安全,如Vector。 -
相对线程安全
是通常意义上的线程安全,它需要保证对这个对象单独的操作是线程安全的,在调用的时候不需要做额外的保证措施。但是对于一些特定顺序的连续调用,就可能需要在调用端使用额外的同步手段来保证调用的正确性。
在Java语言中,大部分线程安全类都属于这种类型,如Vector
、HashTable
、Collections
的synchronizedCollection()
方法包装的集合等。 -
线程兼容
线程兼容是指对象本身不是线程安全的,但是可以通过在调用端正确地使用同步手段来保证对象在并发环境中是可以安全使用的。Java API中的大部分的类都是属于线程兼容的,如ArrayList和HashMap等。 -
线程对立
线程对立是指无论调用端是否采取了同步措施,都无法在多线程环境中使用的代码。线程对立这种排斥多线程的代码是很少出现的,通常都是有害的,应当避免。如Thread
类的suspend()
和resume()
方法。如果两个线程同时持有一个线程对象,两个线程并发对该线程对象执行suspend()
和resume()
方法,无论是否采用了同步,都存在死锁风险。
线程安全的实现方法
如何实现线程安全与代码编写有很大关系,理解虚拟机提供的同步和锁机制对编写线程安全的代码很重要。
同步概念
同步是指在多个线程并发访问共享数据时,保证共享数据在同一个时刻只被一个(或者是一些,使用信号量的时候)线程使用。
1、互斥同步(阻塞同步)
互斥是实现同步的一种手段,而互斥的实现方式主要有临界区、互斥量、信号量。
-
synchronized关键字
-
synchronized关键字是最基本的互斥同步手段。
-
synchronized关键字编译后会在同步块的前后分别形成monitorenter和monitorexit字节码指令。这两个字节码都需要一个reference类型的参数指明要锁定和解锁的对象。如果在代码中指定synchronized的对象参数,那就是这个对象的reference。如果没有明确指定,就根据synchronized修饰的是实例方法还是类方法,取对应的对象实例或Class对象来作为锁对象。
-
在执行monitorenter指令时,首先尝试获取对象的锁,如果该对象没被锁定或者当前线程已经拥有了该对象的锁,就把锁的计数器加1;在执行monitorexit的时候,会将锁计数器减1,当计数器为0时,锁就被释放。如果获取对象锁失败,当前线程就会阻塞等待,直到对象锁被另外一个线程释放。
-
synchronized对同一个线程是可重入的,不会出现自己将自己锁死的现象。
-
同步块在已进入的线程执行完之前,会阻塞后面的线程的进入。
-
synchronized是重量级的操作:Java线程是映射到操作系统的原生线程之上的,阻塞或唤醒一个线程都需要操作系统的帮助,这就需要从用户态转换到核心态中,因此状态转换会耗费很多处理器时间,这个时间可能比用户代码执行的时间还长。
-
虚拟机会进行一些优化:在通知操作系统阻塞线程之前加入一段自旋等待过程,避免频繁地切入到核心态中。
-
重入锁ReentrantLock
和synchronized相比,重入锁ReentrantLock的高级功能有: -
等待可中断:当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他的事情,这点对处理执行时间非常长的同步块很有帮助。
-
可实现公平锁:公平锁是指在多个线程等待同一个锁时,必须按照申请锁的顺序来依次获得锁;非公平锁则不保证这一点,在锁被释放时,任何一个等待锁的线程都有机会获得锁。ReentrantLock默认是非公平,可通过
public ReentrantLock(boolean fair)
使用公平锁。 -
锁可以绑定多个条件:一个
ReentrantLock
对象可以同时绑定多个Condition
对象。而synchronized
中,锁对象的wait()
和notify()
或notifyAll()
方法可以实现一个隐含的条件,如果要和多个条件关联的时候,就必须额外添加一个锁。而ReentrantLock
只需要多次调用newCondition()
即可。
synchronized
和ReentrantLock
性能:在JDK1.6及以上,synchronized
和ReentrantLock
性能基本持平,虚拟机在未来的性能改进中会更偏向于原生的synchronized
,在synchronized
可以实现需求的情况下,优先考虑使用synchronized
。
互斥同步最主要的问题是进行线程阻塞和唤醒时带来的性能问题,这种同步也称为阻塞同步Blocking Synchronization
。从处理问题的方式来说,互斥同步属于一种悲观的并发策略:总是认为只要不去做正确的同步措施(加锁),那就肯定会出问题。无论共享数据是否真的会出现竞争,它都进行加锁、用户态核心态转换、维护锁计数器、检查是否有被阻塞的线程需要唤醒等操作。
2、非阻塞同步
非阻塞同步是一种基于冲突检测的乐观并发策略的同步操作:先进行操作,如果没有其他线程争用共享数据,那操作就成功;如果共享数据有争用,产生了冲突,就在采取其他的补偿措施(比如不断的重试,直到成功)。这种乐观并发策略的很多实现都不需要把线程挂起,因此称为非阻塞同步。
乐观并发策略需要硬件指令集的发展,因为上述过程中的操作和冲突检测这两个步骤需要具备原子性,而这种原子性保证如果使用互斥手段实现就失去意义,所以只能靠硬件通过一条处理器指令来完成这种从语义上看起来需要多次操作的行为。这里的非阻塞同步进行的操作主要涉及CAS(Compare And Swap)
这条指令。使用该指令完成的操作具备原子性,称为CAS操作。
比较并交换(compare and swap, CAS),是原子操作的一种,可用于在多线程编程中实现不被打断的数据交换操作,从而避免多线程同时改写某一数据时由于执行顺序不确定性以及中断的不可预知性产生的数据不一致问题。 该操作通过将内存中的值与指定数据进行比较,当数值一样时将内存中的数据替换为新的值。
CAS指令执行时,需要3个操作数:内存位置(V)、旧的预期值(A)、新值(B)。当且仅当V符合旧预期值A时,处理器用新值B更新V的值,否则它就不执行更新。但是无论是否更新了V的值,都会返回V的旧值。
小例子来理解CAS操作(参考:JAVA并发编程学习笔记之CAS操作):
如下操作:
if(a==5) { //①
a++; //②
}
假如某线程A要执行上述代码,在执行完①之后,执行②之前,有可能另外线程会修改a的值,
所以①②这个整体的操作时线程不安全的,
如果采用加锁的方法,只需要在①②外加上synchronized即可。
但CAS的思想可以用如下代码表示:
int expect = a; //expect即a的旧值
if(a.compareAndSet(expect,a+1)) {
doSomeThing1();
}
在JDK1.5之后,Java程序中才可以使用CAS操作:sun.misc.Unsafe
类里面的compareAndSwapInt()
和compareAndSwapLong()
等方法包装提供。但该类不能由用户程序的类调用(除非使用反射)。java.util.concurrent
包中的AtomicInteger
等原子类的一些方法都使用了Unsafe
类的CAS操作。
CAS的逻辑漏洞——ABA问题:如果一个变量V初次读取的时候是A值,并且在准备赋值的时候检查到它仍然为A值,此时并不能说它的值没有被其他线程修改过,有可能在这期间它的值先被改成了B,后又被改为了A,而CAS操作就会认为它从来没有改变过。大部分情况下ABA情况不会影响程序并发的正确性,如果需要解决ABA问题(JDK通过引入AtomicStampedReference
来保证CAS的正确性),改用传统的互斥手段可能会比原子类更高效。
3、无同步方案
如果一个方法本来就不涉及共享数据,那它就无须任何同步措施。
(个人理解就是变量线程私有化)
-
可重入代码
可重入代码的特征:不依赖存储在堆上的数据和公用的系统资源、用到的状态量都由参数传入、不调用非可重入的方法等。
判断代码是否具有可重入性:对于一个方法,如果输入了相同的数据,就都能返回相同的结果,那它就满足可重入性的要求,也是线程安全的。 -
线程本地存储
通过ThreadLocal类来实现线程本地存储的功能。
锁优化
锁优化技术(HotSpot虚拟机而言)包括适应性自旋、锁消除、锁粗化、轻量级锁和偏向锁等。这些技术都是为了在线程之间更高效地共享数据以及解决竞争问题,从而提高程序效率。
-
自旋锁与自适应自旋
在互斥同步的时候,为了消除线程切换带来的性能消耗,让等待锁的线程执行一个忙循环(自旋),而不放弃处理器的执行时间,看看持有锁的线程是否很快就会释放锁。这就是自旋锁。
自旋等待虽然避免了线程切换的开销,但如果锁被占用很长时间,自旋的线程只会白白浪费处理器资源,所以自旋等待的时间要有一定限度。如果自旋超过了限定的次数仍然没有成功获得锁,就使用传统的方式挂起线程。自旋默认的次数是10,可以通过参数-XX:PreBlockSpin
更改。
JDK1.6中引入了自适应的自旋锁:自旋时间不固定,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行,那么虚拟机就会认为这次自旋也很有可能再次成功,并将自旋等待时间延长。如果对于某个锁,自旋很少成功,那么在之后获取该锁时可能会放弃不自旋直接挂起线程。
-
锁消除
锁消除是指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判断依据来源于逃逸分析的数据支持,如果判断在一段代码中,堆上的所有数据都不会逃逸出去从而被其他线程访问到,那就可以把它们当做栈上数据对待,认为它们是线程私有的,同步加锁就无需进行。
这种情况主要是一些Java API中类自己的同步的消除,因为一般在编写代码时都会清除哪些数据存在竞争。 -
锁粗化
原则上,在编写代码时,总是应该将同步块的作用范围限制得尽量小,以便使需要同步的操作数量尽可能变小,如果存在锁竞争,那等待锁的线程也能尽快拿到锁。
但是,如果一系列的连续动作都对同一对象反复加锁和解锁,甚至加锁操作时出现在循环体中的,那即使没有线程竞争,频繁地进行互斥同步操作也会导致不必要的性能损耗,比如连续的append()
方法。 -
轻量级锁
轻量级锁是JDK1.6中加入的新型锁机制。轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用操作系统互斥量产生的性能消耗。
理解轻量级锁必须从HotSpot虚拟机中的对象的对象头的信息开始。关于对象头尤其是对象头中Mark World
的内容可以参考对象的创建、内存布局、访问定位。</br>
轻量级锁的加锁过程:在代码进入同步块的时候,如果此对象没有被锁定(标志位为01),虚拟机首先在当前线程的栈帧中创建一个空间(称为锁记录Lock Record
),用于存储锁对象目前的Mark World
的拷贝。然后,虚拟机将使用CAS操作尝试将对象的Mark World
更新为指向锁空间的指针,如果更新成功,那么这个线程就拥有了该对象的锁,并且对象Mark World
的锁标志位将变为00,即表示此对象处于轻量级锁定状态。如果更新失败,虚拟机首先会检查对象的Mark World
是否指向当前线程的栈帧,如果是,说明当前线程已经拥有了该对象的锁,就可以直接进入同步块,如果不是,说明这个锁对象已经被其他线程占用了。如果有两个以上线程争用同一个锁,轻量级锁就不再有效,就要膨胀为重量级锁,锁标志位变为10。</br>
轻量级锁的解锁过程:如果对象的Mark World
仍然指向着线程的锁记录,就用CAS操作把对象当前的Mark World
和线程中复制的Mark World
的拷贝替换回来,如果替换成功,整个同步过程就结束。如果失败,说明其他线程尝试过获取锁,就需要在释放锁的时候,唤醒被挂起的线程。</br>
轻量级锁提升程序同步性能的依据是:对于绝大部分的锁,在整个同步周期内都不存在竞争。但如果存在锁竞争,依然会使用重量级锁,还额外发生了CAS操作,因此在有竞争的情况下,轻量级锁比传统的重量级锁更慢。 -
偏向锁
偏向锁是JDL1.6引入的锁优化技术,它比轻量级锁更进一步:在无竞争的情况下,把整个同步都消除掉,连CAS操作也不做。
偏向锁中的“偏向”是指锁偏向于第一个获取它的线程,如果在接下来的执行过程中,该锁没有被其他的线程获取,则持有偏向锁的线程永远不需要同步。
偏向锁的原理:当锁对象第一次被线程获取的时候,虚拟机将Mark World
的标志位设为偏向模式(01),同时使用CAS操作将获取到该锁的线程ID记录在Mark World
之中。如果CAS操作成功,持有偏向锁的线程以后每次进入这个锁的同步块时,虚拟机都不再进行任何同步操作。当有另外的线程尝试获取该锁时,偏向模式就结束了。此时,根据锁对象目前是否处于被锁定的状态,撤销偏向后恢复到未锁定或者轻量级锁的状态。后续的操作就如同轻量级锁那样执行。
偏向锁可以提高带有同步但无竞争的程序性能,是一个带有效益权衡(Trade Off)性质的优化,它并不一定总是对程序运行有利。如果程序中总是被多个不同的线程访问,那偏向模式就是多余的。
内容摘抄自《深入理解Java虚拟机》