Java之锁的分类、原理及实例

·  阅读 699

一、Java之锁的分类

Java并行编程中经常听说各种锁的术语,如偏向锁、自旋锁、乐观锁等等,但是这些锁之间有什么关系呢,锁到底是怎么分类的呢?根据锁的分类规则分为以下7大类,分段锁是一种锁的设计,并不是一种具体的锁。

  • 偏向锁/轻量级锁/重量级锁
  • 可重入锁/非可重入锁
  • 共享锁/独占锁
  • 公平锁/非公平锁
  • 悲观锁/乐观锁
  • 自旋锁/非自旋锁
  • 可中断锁/不可中断锁
  • 分段锁

下面我们逐一介绍每一类锁的原理和对应的实例。

二、Java之锁的原理

1.偏向锁/轻量级锁/重量级锁

这三种锁指的是synchronized锁的状态,Java1.6之前是基于重量级锁,Java1.6之后对synchronized进行了优化,为了减少获取和释放锁带来的性能消耗,引入了偏向锁、轻量级锁以及锁的升级机制。在介绍Java锁之前,先认识一下Java的对象结构。
在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。其中MarkWord属于对象头的一部分,主要用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等,这部分数据的长度在32位和64位的虚拟机(未开启压缩指针)中分别为32bit和64bit。MarkWord的最后2bit是锁状态标志,对象所处的状态决定了MarkWord存储的内容。

标志位状态存储内容
01未锁定对象哈希码、对象分代年龄
11GC标记空(不需要记录信息)
00轻量级锁定指向锁记录的指针
10膨胀(重量级锁定)执行重量级锁定的指针
01可偏向偏向线程ID、偏向时间戳、对象分代年龄
  • 偏向锁: 是Java1.6引入的锁的优化。是在只有一个线程执行同步代码块时,使用CAS操作在对象头部信息中写入拿到锁的线程ID/锁级别等信息。
  • 轻量级锁: 是指当锁是偏向锁时,被另一个线程所访问,偏向锁就会升级为轻量级锁,在很多情况下,synchronized 中的代码是被多个线程交替执行的,而不是同时执行的,即并不存在实际的竞争,或只有短时间的锁竞争,利用 CAS 操作解决,其他线程会通过自旋的形式尝试获取锁,不会阻塞,提高了性能。
  • 重量级锁: 是互斥锁,利用操作系统的同步机制实现的,开销相对较大。当多个线程直接有实际竞争,且锁竞争时间长时,轻量级锁不能满足需求,锁就会膨胀为重量级锁。重量级锁会让其他申请却获取不到锁的线程进入阻塞状态。 锁的升级:无锁-->偏向锁-->轻量级锁-->重量级锁

综上,偏向锁的性能最好,是只有一个线程执行同步代码块,当存在多个线程交替执行时,轻量级锁利用CAS操作和线程自旋获取锁,性能中等,当多个线程存在实际竞争时,重量级锁会把获取不到锁的线程阻塞,性能最差。

2.可重入锁/非可重入锁

在同一个线程中,外层方法获取锁之后,在进入内层方法时会自动获取锁则为可重入锁,进入内层方法时需要重新获取锁的为不可重入锁。如下代码,当某线程执行方法methodA()时,获取到对象锁,当执行方法methodB时,不需要重新获取锁。可重入锁的一个好处是可一定程度避免死锁。

synchronized void methodA() {
    // 省略同步代码
    .....
    methodB();
}
synchronized void methodB() {
  // 省略同步代码
  ......
}
复制代码

3.共享锁/独占锁

  • 共享锁: 同一把锁可以被多个线程同时获得。
  • 独占锁: 同一把锁只能同时被一个线程获得。

读写锁是共享锁和独占锁很好的例子。读锁是共享锁,可以保证并发读。写锁是独占锁,只能同时被一个线程获取。

共享锁和独占锁是通过AQS来实现, AQS提供了独占锁和共享锁必须实现的方法,具有独占锁功能的子类,它必须实现tryAcquire、tryRelease、isHeldExclusively等;共享锁功能的子类,必须实现tryAcquireShared和tryReleaseShared等方法,带有Shared后缀的方法都是支持共享锁加锁的语义。

  • AQS(AbstractQueuedSynchronizer): 是java.util.concurrent.locks包下基础的抽象类,提供了Java锁的基础框架。下面介绍一下AQS中关键的数据结构。
    • AQS中维护了一个共享状态state。1)state使用volatile修饰保证线程间内存可见性;2)getState()和setState()方法采用final修饰,禁止AQS子类重写;3)compareAndSetState()方法采用乐观锁思想的CAS算法,使用final修饰的禁止子类重写。
      // 源码
       private volatile int state;
       
       protected final int getState() {	
       	return state;	
      }
      
      protected final void setState(int newState) {	
          state = newState;	
      }
      
      protected final boolean compareAndSetState(int expect, int update) {	
          // See below for intrinsics setup to support this	
          return unsafe.compareAndSwapInt(this, stateOffset, expect, update);	
      }
      复制代码
    • CLH队列(Craig, Landin, and Hagersten locks) 是AQS中FIFO的双向队列,其内部通过节点head和tail记录队首和队尾元素,队列元素类型为Node。AQS利用CLH队列完成同步状态state的管理。当前线程获取同步状态失败时,AQS则会将该线程等待状态等信息构造成一个节点(Node)并将其加入到CLH同步队列,同时会阻塞当前线程,当同步状态释放时,会把首节点唤醒(公平锁),使其再次尝试获取同步状态。
      • 入队列: tail指向新节点、新节点的prev指向当前最后的节点,当前最后一个节点的next指向当前节点。
      • 出队列: 节点的线程释放同步状态后,将会唤醒它的后继节点(next),而后继节点将会在获取同步状态成功时将自己设置为首节点。
    • Node 是AQS的静态内部类,表示一个线程,它保存着线程的引用(thread)、状态(waitStatus)、前驱节点(prev)、后继节点(next),condition队列的后续节点(nextWaiter)。
      // AQS静态内部类 Node
      static final class Node {
          ......
          /** 线程的状态:
          * SIGNAL-表示后续节点需要唤醒。当前节点的后续节点的线程通过park被阻塞了,当前节点在释放或取消通过unpark解除其阻塞;
          * CANCELLED-取消状态。当前节点因为的线程因为超时或中断被取消;
          * CONDITION-等待状态。当前节点在condition队列中;
          * PROPAGATE-传播状态,共享锁的释放。此状态是为了优化锁的竞争,使队列中的线程一个一个的被唤醒;
          * 0-一般为节点的初始状态。
          */
          volatile int waitStatus; 
       
          volatile Node prev;
          
          volatile Node next;
          
          volatile Thread thread;
          
          Node nextWaiter;
          ......
      }
      复制代码
    • ConditionObject: 是AQS的内部类,实现了Condition接口,为AQS提供条件变量的支持。synchronized控制同步时,可以配合Object的wait(),notify(),notifyAll() 系列方法实现等待/通知模式。而Lock呢?提供了条件Condition接口,配合await(),signal(),signalAll() 等方法实现等待/通知机制。
    public class ConditionObject implements Condition {
     /** First node of condition queue. */
     private transient Node firstWaiter;
     /** Last node of condition queue. */
     private transient Node lastWaiter;
    }
    复制代码
  1. 调用Condition的signal方法不代表线程可以马上执行,signal方法的作用是将线程所在的节点从等待队列中移除,然后加入到同步队列中,线程的执行始终都需要根据同步状态(即线程是否占有锁)。
  2. ConditionObject对象都维护了一个单独的等待队列,AQS所维护的CLH队列是同步队列,它们节点类型相同,都是Node。

4.公平锁/非公平锁

  • 公平锁: 指多个线程按照申请锁的顺序来获取锁。会造成性能低下,大量的时间花费在线程调度上。
  • 非公平锁: 指多个线程获取锁的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程优先获取锁。有可能,会造成优先级反转或者饥饿现象。优点是提高了响应速度,不用把大量时间花费在线程调度上,而是花费在执行代码上。

公平锁的实现方式:

ReentrantLock lock=new ReentrantLock(true);//true表示获取公平锁
复制代码

非公平锁的实现方式:

ReentrantLock lock=new ReentrantLock();//默认是非公平锁
ReentrantLock lock=new ReentrantLock(false);
复制代码

ReentrantLock源码:FairSync和NonfairSync是ReentrantLock类中的两个静态内部类,它们都继承了Sync,Sync也是ReentrantLock类中的一个静态内部类,继承了上一节中的AQS。

// 同步器,用于实现所有的同步机制,比如公平/非公平
private final Sync sync; 
abstract static class Sync extends AbstractQueuedSynchronizer {
  /**
   * Performs non-fair tryLock.  tryAcquire is implemented in
   * subclasses, but both need nonfair try for trylock method.
   */
  @ReservedStackAccess
  final boolean nonfairTryAcquire(int acquires) {
      final Thread current = Thread.currentThread(); // 获取当前线程
      int c = getState(); // 获取锁的状态,0表示没有被其他线程获取
      if (c == 0) {
          if (compareAndSetState(0, acquires)) { // 利用CAS更新锁状态
              setExclusiveOwnerThread(current); // 设置锁的持有者为当前线程
              return true;
          }
      }
      else if (current == getExclusiveOwnerThread()) { // 重入锁的实现
          int nextc = c + acquires;
          if (nextc < 0) // overflow
              throw new Error("Maximum lock count exceeded");
          setState(nextc);
          return true;
      }
      return false;
  }
......
}
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

// 非公平锁
static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;
    protected final boolean tryAcquire(int acquires) {
        return nonfairTryAcquire(acquires); // 父类中的方法
    }
}
// 公平锁
static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;
    /**
     * Fair version of tryAcquire.  Don't grant access unless
     * recursive call or no waiters or is first.
     */
    @ReservedStackAccess
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();  // 获取当前线程
        int c = getState(); // 获取锁的状态,0表示没有被其他线程获取
        if (c == 0) {
            if (!hasQueuedPredecessors() && // 判断存在等待时间更长的线程,没有返回false(当前线程获取到锁,判断当前队列中是否有先驱节点,有则返回true)
                compareAndSetState(0, acquires)) { // 利用CAS更新锁状态
                setExclusiveOwnerThread(current); // 设置锁的持有者为当前线程
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) { // 重入锁的实现
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}
复制代码

5.悲观锁/乐观锁

  • 悲观锁: 认为对于同一个数据的并发操作,一定会发生修改的,即使没有修改,也会认为修改。因此对于同一份数据的并发操作,悲观锁采取加锁的形式。适合写操作较多的场景。
  • 乐观锁: 认为对于同一个数据的并发操作,是不会发生修改的,在更新数据时,会采用尝试更新,通常使用CAS自旋实现数据更新。乐观的认为,不加锁的并发操作是没有事情的。适合读操作较多的场景。

悲观锁的实现方式: 利用Java中的各种锁;
乐观锁的实现方式: 1)CAS算法;2)版本号机制。

  • CAS算法(compare and swap): 是一种非阻塞无锁算法,在线程开启的时候,会从主存中为每个线程拷贝一个变量副本到各自的运行环境中,CAS算法中包含三个参数(V,E,N),V表示要更新的变量(也就是从主存中拷贝过来的值)、E表示预期的值、N表示新值。如果内存位置V的值与预期原值E相等,那么处理器会自动将该位置值更新为新值N,否则处理器不做任何操作。 当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新变量的值,而其它线程都失败,失败的线程并不会被挂起,而是被告知这次竞争中失败,并可以再次尝试。Java1.5中新增的java.util.concurrent包就是建立在CAS之上的,在Lock实现中有CAS改变state变量,在atomic包中的实现类也几乎都是用CAS实现。
    • 缺点: 1)循环时间太长;2)只能保证一个共享变量原子操作;3)会出现ABA问题。
    • 优点: 是CPU指令级的操作,只有一步原子操作,所以非常快。而且CAS避免了请求操作系统来裁定锁的问题,直接在CPU内部就搞定了。
  • 版本号机制: 一般在数据表中加上一个版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读到的version值与当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。

6.自旋锁/非自旋锁

自旋锁指尝试获取锁的线程不会立即阻塞或释放CPU,而是采用循环的方式去尝试获取锁,减少线程上下文切换的消耗,缺点是循环会消耗CPU。而非自旋锁如果拿不到锁,就直接放弃,加入等待队列、陷入阻塞等。

自旋锁是采用让当前线程不停地的在循环体内执行实现的,当循环的条件被其他线程改变时 才能进入临界区。当前线程不停地执行循环体,不进行线程状态的改变,所以响应速度更快。但当线程数不断增加时,性能下降明显,每个线程都需要执行,占用CPU时间。如果线程竞争不激烈,并且保持锁的时间短,适合使用自旋锁。

7.可中断锁/不可中断锁

如果线程A正在执行锁中的代码,线程B在等待获取该对象锁,如果等待时间过长,想让B去做其他事情,可以让线程B自己中断或者别的线程中断它。

在 Java 中,synchronized 关键字修饰的锁代表的是不可中断锁,一旦线程申请了锁,只能等到拿到锁以后才能进行其他的逻辑处理。而Lock是一种典型的可中断锁,例如使用 lockInterruptibly 方法在获取锁的过程中,突然不想获取了,那么也可以在中断之后去做其他的事情,不需要一直等到获取到锁才离开。ReentrantLock实现了Lock接口,实现的lockInterruptibly方法源码调用了sync.acquireInterruptibly,为AQS中的方法。

public void lockInterruptibly() throws InterruptedException {
    sync.acquireInterruptibly(1);
}
复制代码

8.分段锁

分段锁是一种锁的设计,在ConcurrentHashMap中,其并发的实现是通过粒度更小的分段锁以提高并发操作的效率。下面我们分析一下HashMap、Hastable、ConcurrentHashMap的源码,进一步理解分段锁出现的原因。

1)线程不安全的HashMap: 在多线程场景下,使用HashMap的put操作会出现数据不一致或死循环问题。为什么会出现这种情况呢?

  • put操作导致数据不一致

比如有两个线程A和B,线程A希望put一个key-value对到HashMap中,首先计算记录要插入的桶的位置,然后获取到该桶中的链表头节点,此时线程A的时间片用完了,而线程B被调度得以执行,线程B成功将记录put到了桶中。假设线程A计算出来的桶索引和线程B计算出来的桶索引是相同的,当线程B成功插入之后,线程A再次被调度运行时,它依然持有过期的链表头,继续执行put操作,以至于覆盖了线程B已经插入的记录,造成了数据不一致的行为。

  • put操作导致死循环问题

Java8对HashMap进行了优化,链表长度大于8时转换为红黑树的存储结构、resize优化等,但是依然是线程不安全的,为了简化分析,使用Java7的HashMap源码进行线程不安全分析。
HashMap的实现使用一个Node数组,每个数组项里面有一个链表的方式来实现,因为HashMap使用key的hashCode来寻找存储位置**(h&(length-1)),不同的key可能具有相同的hashCode,这时就出现哈希冲突了,也叫做哈希碰撞,为了解决哈希冲突,有开放地址方法和链地址方法。HashMap的使用了链地址方法**,也就是将哈希值一样的entry保存在同一个数组项里面,可以把一个数组项当做一个桶,桶里面装的entry的key的hashCode是一样的。

transient Node<K,V>[] table; //变量被transient修饰,变量将不再是对象持久化的一部分,该变量内容在序列化后无法获得访问
......
// Node: HashMap的静态内部类
static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    V value;
    Node<K,V> next;
    ......
}
复制代码

HashMap的数组的初始长度为16,loadFact为0.75,当数据记录超过阈值且发生哈希冲突时,HashMap将会进行扩容操作,每次都会变为原来大小的2倍,直到设定的最大值之后就无法再resize了。进行扩容,数组长度会发生变化,存储位置会重新计算 index = h&(length-1) 也可能会发生变化,先来看看transfer方法。

void transfer(Entry[] newTable, boolean rehash) {
    int newCapacity = newTable.length;
    for (Entry<K,V> e : table) {
        while(null != e) {
            Entry<K,V> next = e.next;  // 1
            if (rehash) {
                e.hash = null == e.key ? 0 : hash(e.key);
            }
            int i = indexFor(e.hash, newCapacity);
            e.next = newTable[i]; // 2
            newTable[i] = e;  // 3
            e = next;  // 4
        }
    }
}
复制代码

假设有一个长度为2的HashMap,[3,a]>[7,b]>[5,c]在索引为1的位置\color{red}{[3,a]->[7,b]->[5,c]在索引为1的位置},有两个线程A和B分别对该HashMap进行put操作,首先进行HashMap扩容,当线程执行到transfer方法中1的位置时,线程A的时间片用完,此时,e=[3,a],next=[7,b]\color{red}{e=[3,a],next=[7,b]}。线程B被调度运行,并且完成了HashMap的扩容操作,在扩容后的数组中[5,c]在索引为1的位置,[7,b]>[3,a]在索引3的位置\color{red}{[5,c]在索引为1的位置,[7,b]->[3,a]在索引3的位置}。此时线程A重新被调度继续执行,在线程A首先将[3,a]迁移到新数组,然后处理[7,b]之后,处理[7,b]的next,线程B扩容后已经把[7,b]的next指向了[3,a],[3,a][7,b]形成了循环链表,从而在获取数据遍历链表时形成死循环\color{red}{[3,a]和[7,b]形成了循环链表,从而在获取数据遍历链表时形成死循环}死循环的原因就在于在扩容时,执行transfer方法中的步骤2、3、4使用的是头插法,会造成链表的反转,进一步形成循环链表。

2)线程安全效率低的Hashtable: Hashtable使用synchronized来保证线程安全,但在线程竞争激烈时Hashtable的效率非常低。当一个线程访问Hashtable的同步方法时,其他线程访问Hashtable的同步方法时,可能会进入阻塞或轮询状态。既不能使用put方法添加元素,也不能使用get方法来获取元素。

3)线程安全的ConcurrentHashMap ConcurrentHashMap中的分段锁称为Segment,类似于HashMap(JDK7与JDK8中HashMap的实现)的结构,即内部拥有一个Entry数组,数组中的每个元素又是一个链表;同时又是一个ReentrantLock(Segment继承了ReentrantLock)。分段锁的设计目的是细化锁的粒度,当操作不需要更新整个数组的时候,就仅仅针对数组中的某个segment进行加锁操作。

// ConcurrentHashMap的静态内部类
static class Segment<K,V> extends ReentrantLock implements Serializable {

}
复制代码

当put元素的时候,并不是对整个HashMap进行加锁,而是先通过hashcode确定元素的分段位置,然后对这个分段进行加锁,所以当多线程put操作时,只要不是放在一个分段中,就可以实现真正的并行插入。但是,在统计size的时候,可就是获取hashmap全局信息的时候,就需要获取所有的分段锁才能统计。

三、Java之锁的实例

  • Synchronized: 是一种非公平,悲观,独享,互斥,可重入,重量级锁;
  • ReentrantLock: 是一种默认非公平但可实现公平的,悲观,独享,互斥,可重入,重量级锁。
  • ReentrantReadWriteLock: 是一种默认非公平但可实现公平的,悲观,写独享,读共享,读写,可重入,重量级锁,实现了ReadWriteLock接口,可以通过readLock()获取读锁,通过writeLock()获取写锁。
  • Semaphore: 是一种共享锁。Semaphore是一种计数信号量,用于管理一组资源,内部是基于AQS的共享模式。它相当于给线程规定一个量从而控制允许活动的线程数。
分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改