线程安全与锁优化

线程安全与锁优化

线程安全

当多个线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替运行,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那这个对象是线程安全的

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

Java语言中的线程安全

我们把Java语言中各种操作共享的数据分为以下5类:不可变,绝对线程安全,相对线程安全,线程兼容和线程对立

不可变

不可变的对象一定是线程安全的,如果共享数据是一个基本数据类型,那么只要在定义时使用final关键字修饰就可以保证它是不可变的。如果共享数据是一个对象,那就需要保证对象的行为不会对其状态产生影响才行。保证对象行为不影响自己的状态的途径有很多种,其中最简单的就是把对象中带有状态的变量都声明为final,如Integer,它通过将内部状态变量value定义为final来保障状态不变

Java API中符合不可变要求的类型,除了String,还有枚举类型,Number的部分子类,如Long和Double等数值包装类型,BigInteger和BigDecimal等大数据类型

绝对线程安全

绝对的线程安全完全满足上面给出的线程安全的定义,不管运行环境如下,调用者都不需要进行额外的同步措施,在Java中标注自己是线程安全的类,大多数都不是绝对的线程安全

相对线程安全

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

Java中大部分线程安全类都属于这种类型,如Vector,HashTable,Collections的synchronizedCollection()方法保证的集合等

线程兼容

线程兼容是指对象本身并不是线程安全的,但是可以通过在调用端正确使用同步手段来保证对象在并发的环境中可以安全地使用,我们平常说一个类不是线程安全的,绝大多数指的就是这一种情况

Java中大部分类都属于线程兼容,如ArrayList和HashMap等

线程对立

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

线程安全的实现方法

互斥同步

同步指多个线程并发访问共享数据时,保证共享数据在同一时刻只被一个线程使用(信号量机制下可以被一些使用)。互斥是实现同步的一种手段,临界区(Critical Section),互斥量(Mutex)和信号量(Semaphore)都是主要的互斥实现方式,互斥是因,同步是果,互斥是方法,同步是目的

Java中最基本的互斥同步手段是synchronized关键字,编译后会在同步块前后形成monitorenter和monitorexit字节码指令,这两个字节码指令都需要一个reference类型的参数来指明要锁定和解锁的对象。如果程序中synchronized明确指定了对象参数,那就是这个对象的reference;如果没有明确指定,那就根据synchronized修饰的是实例方法还是类方法,去取对应的对象实例或Class对象来作为锁对象

在执行monitorenter指令时,首先尝试获取对象的锁。如果这个对象没被锁定,或者当前线程已经拥有那个对象的锁,把锁计数器加1,相应地,执行monitorexit指令时把锁计数器减1,当计数器为0,锁就被释放。如果获取对象锁失败,那当前线程就要阻塞等待,直到对象锁被另外一个线程释放为止

synchronized同步块对同一条线程是可重入的,不会自己把自己锁死,其次,同步块在已进入线程执行完之前,会阻塞后面其他线程的进入。Java的线程是映射到OS的原生线程上的,如果要阻塞或唤醒一个线程,都需要OS来帮忙完成,这就需要从用户态转换到核心态中,因此需要耗费很多的处理器时间。对于代码简单的同步块(如synchronized修饰的getter和setter),状态转换消耗的时间可能比用户代码执行的时间还要长。所以synchronized关键字是Java语言的一个重量级的操作。在确实有必要的情况下才使用它,虚拟机本身也会进行一些优化,譬如在通知OS阻塞线程前加入一段自旋等待过程,避免频繁进入到核心态中

除了synchronized关键字,我们还可以使用java.util.concurrent的重入锁ReentrantLock来实现同步,基本用法上它们是类似的,只是代码写法上有些出入,一个表现为API层面的互斥锁(lock()和unlock()配合try/finally语句块完成),另一个表现为原生语法层面的互斥锁

不过,相比synchronized,ReentrantLock增加了一些高级功能:等待可中断,可实现公平锁,以及锁可以绑定多个条件

  • 等待可中断指当持有锁的线程长期不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他事情
  • 公平锁指多个线程在等待同一个锁时,必须按照申请锁的时间顺序来依次获得锁,synchronized的锁是非公平的,默认情况下ReentrantLock也是非公平的,但可以通过带布尔值的构造函数要求公平锁
  • 锁绑定多个条件指一个ReentrantLock对象可以同时绑定多个Condition对象,而在synchronized中,锁对象的wait()和notify()或notifyAll()可以实现一个隐含的条件,如果要和多于一个条件关联,就不得不额外添加一个锁,而ReentrantLock只需要多次调用newCondition()方法即可

非阻塞同步

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

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

我们需要操作和冲突检测这两个步骤具备原子性,只能靠硬件来完成它们的原子性,硬件保证一个从语义上来说需要多次操作的行为只通过一条处理器指令就能完成,这类指令常用的有:

  • 测试并设置(Test-and-Set)
  • 获取并增加(Fetch-and-Increment)
  • 交换(Swap)
  • 比较并交换(Compare-and-Swap,下文称CAS)
  • 加载链接/条件存储(Load-Linked/Store-Conditional,下文称LL/SC)

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

JDK 1.5后提供CAS操作,该操作由sun.misc.Unsafe类的compareAndSwapInt()和compareAndSwapLong()等几个方法包装提供,Unsafe类只能通过其他Java API来间接使用,如concurrent包的整数原子类(AtomicInteger),其中的compareAndSet()和getAndIncrement()等方法都用了Unsafe类的CAS操作

CAS操作常见的漏洞是”ABA”问题,即如果一个变量V初次读取的时候是A值,并且准备赋值时它仍然为A值,那也不能说明它就没有被改变过,因为它可能先被改成了B,再被改回A

无同步方案

要保证线程安全,不一定需要同步,同步只是保证共享数据争用时的正确性的手段,如果一个方法本来就不涉及共享数据,那它自然就无须任何同步措施去保证正确性,因此会有一些代码天生就是线程安全的,主要介绍其中两类

可重入代码:也叫纯代码,可以在代码执行的任何时刻中断它,转而去执行其他代码,而在控制权返回后,原来的程序不会出现任何错误。可冲入代码都是线程安全的。可重入代码有一些共同特征,如不依赖存储在堆上的数据和公用的系统资源,用到的状态量都由参数传入,不调用非可重入的方法等。如果一个方法,它的返回结果是可以预测的,只要输入相同的数据,都能返回相同的结果,那它就满足可重入性的要求,当然也是线程安全的

线程本地存储:如果一段代码所需要的数据必须与其他代码共享,那就看看这些共享数据的代码是否能保证在同一个线程中执行,如果能保证,我们就可以把共享数据的可见范围限制在同一个线程之内,这样,无须同步也能保证线程之间不出现数据争用的问题
符合这种特点的应用并不少见,大部分使用消息队列的架构模式都会将产品的消费过程尽量在一个线程中消费完,其中最重要的一个应用实例就是经典Web交互模型中的”一个请求对应一个服务器线程”的处理方式,这种处理方式广泛应用使得很多Web服务端应用都可以使用线程本地存储来解决线程安全问题

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

锁优化

自旋锁与自适应自旋

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

JDK 1.6引入自适应的自旋锁,自适应意味自旋的时间不再固定,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行中,那么虚拟机就会认为这次自旋也很有可能再次成功,进而它将允许自旋等待持续相对更长的时间,比如100个循环。另外,如果对于某个锁,自旋很少成功过,那在以后要获取这个锁时将可能省略掉自旋过程,以避免浪费处理器资源。有了自适应自旋,随着程序运行和性能监控信息的不断完善,虚拟机对程序锁的状况预测越来越准确

锁消除

锁消除指虚拟机即时编译器在运行时,对一些代码上要求同步,但是被检测到不可能存在共享数据竞争的锁进行消除,锁消除的主要判定依据来源于逃逸分析的数据支持,如果判断在一段代码上,堆上所有数据都不会逃逸出去从而被其他线程访问到,那就可以把它们当做栈上的数据对待,认为它们是线程私有的,同步加锁自然就无须进行(很多同步措施都不是程序员自己想要加入的,而是Java方法本身就有)

锁粗化

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

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

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

轻量级锁

轻量级锁是JDK 1.6之中加入的新型锁机制,传统的锁机制是重量级锁,轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,减少传统的重量级锁使用OS互斥量产生的性能消耗

要理解轻量级锁,必须要从HotSpot虚拟机的对象(对象头部分)的内存布局开始介绍。HotSpot虚拟机的对象头分为两部分信息,第一部分用于存储对象自身的运行时数据,如哈希吗,GC分带年龄等,这部分数据长度在32位和64位虚拟机中分别为32bit和64bit,官方称它为”Mark Word”,它是实现轻量级锁和偏向锁的关键。另外一部分用于存储指向方法区对象类型数据的指针,如果是数组对象的话,还会有一个额外的部分用于存储数组长度

在代码进入同步块的时候,如果此同步对象没有被锁定,虚拟机首先将在当前线程的栈帧中建立一个名为锁记录的空间,用于存储锁对象目前的Mark Word的拷贝,然后,虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针,如果这个操作成功了,那么这个线程就拥有了该对象的锁,并且对象的Mark Word的锁标志位转变为”00”,代表此对象处于轻量级锁定状态,如下图所示:

如果这个更新操作失败了,虚拟机首先检查对象的Mark Word是否指向当前线程的栈帧,如果只说明当前线程已经拥有这个锁,那就可以直接进入同步块继续执行,否则说明这个锁对象已经被其他线程抢占了。如果有两条以上的线程争用同一个锁,那轻量级锁就不再有效,要膨胀为重量级锁,锁标志状态值变为”10”,Mark Word中存储的就是指向重量级锁的指针,后面等待锁的线程也要进入阻塞状态

轻量级锁的加锁和解锁过程都是通过CAS操作来完成的

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

偏向锁

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

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

当锁对象第一次被线程获取的时候,虚拟机会把对象头的标志位设为”01”,即偏向模式,同时CAS操作把获取这个锁的线程的ID记录在对象的Mark Word中,如果CAS操作成功,持有偏向锁的线程以后每次进入这个锁相关的同步块时,虚拟机都可以不再进行任何同步操作

当有另外一个线程去尝试获取这个锁,偏向模式就结束,根据锁对象目前是否处于被锁定的状态,撤销偏向后恢复到未锁定或轻量级锁定的状态,后续同步操作就如上面的轻量级锁那样执行

偏向锁可以提高带有同步但无竞争的程序性能,同样是一个带有效益权衡性质的优化