深入理解锁的实现原理（二）

前言：最近这段时比较忙，抽空写的这篇总结，该篇文章是继上一篇深入理解锁的实现原理（一）的补充，希望能对大家有所帮助~

Reentrantlock锁的实现原理：
基于AQS实现定义源码：

public abstract class AbstractQueuedSynchronizer extends
    AbstractOwnableSynchronizer implements java.io.Serializable {  
    //等待队列的头节点    
    private transient volatile Node head;    
    //等待队列的尾节点    
    private transient volatile Node tail;    
    //同步状态    
    private volatile int state;    
    protected final int getState() { 
      return state;
    }    

  protected final void setState(int newState) { 
      state = newState;
    }    
  ...
}

AQS的实现原理：
队列同步器AbstractQueueSynchronized，是用来构建锁或者其他同步组件的基础架构，内部使用一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，其中内部状态state，等待队列的头结点head和尾节点tail都是通过volatile修饰来保证多线程之间的可见。子类重写tryAcquire和tryRelease方法通过CAS指令修改状态变量state

概述：AQS内部会保存一个状态变量state，通过CAS修改该变量的值，修改成功的线程表示获取到该锁，没有修改成功，或者发现状态state已经是加锁状态，则通过一个Waiter对象封装线程，添加到等待队列中，并挂起等待被唤醒内置FIFO队列：
源码如下：

static final class Node {        
    static final Node SHARED = new Node();        
    static final Node EXCLUSIVE = null;        
    static final int CANCELLED =  1;        
    static final int SIGNAL    = -1;        
    static final int CONDITION = -2;        
    static final int PROPAGATE = -3;        
    volatile int waitStatus;       
    volatile Node prev;        
    volatile Node next;        
    volatile Thread thread;        
    Node nextWaiter;       
     ...    
 }

解析：
第一个默认是head节点，是一个空节点，可以理解成代表当前持有锁的线程，每当有线程竞争失败，都是插入到队列的尾节点，tail节点始终指向队列中的最后一个元素。每个节点中，除了存储了当前线程，前后节点的引用以外，还有一个waitStatus变量，用于描述节点当前的状态。多线程并发执行时，队列中会有多个节点存在，这个waitStatus其实代表对应线程的状态：有的线程可能获取锁因为某些原因放弃竞争；有的线程在等待满足条件，满足之后才能执行等等。一共有4中状态：

CANCELLED 取消状态
SIGNAL 等待触发状态
CONDITION 等待条件状态
PROPAGATE 状态需要向后传播

等待队列是FIFO先进先出，只有前一个节点的状态为SIGNAL时，当前节点的线程才能被挂起。

线程获取锁的过程：

线程A执行CAS执行成功，state值被修改并返回true，线程A继续执行。
线程A执行CAS指令失败，说明线程B也在执行CAS指令且成功，这种情况下线程A会执行步骤3。
生成新Node节点node，并通过CAS指令插入到等待队列的队尾（同一时刻可能会有多个Node节点插入到等待队列中），如果tail节点为空，则将head节点指向一个空节点（代表线程B）
node插入到队尾后，该线程不会立马挂起，会进行自旋操作。因为在node的插入过程，线程B（即之前没有阻塞的线程）可能已经执行完成，所以要判断该node的前一个节点pred是否为head节点（代表线程B），如果pred == head，表明当前节点是队列中第一个“有效的”节点，因此再次尝试tryAcquire获取锁，
4.1 如果成功获取到锁，表明线程B已经执行完成，线程A不需要挂起。
4.2. 如果获取失败，表示线程B还未完成，至少还未修改state值。进行步骤5。
前面我们已经说过只有前一个节点pred的线程状态为SIGNAL时，当前节点的线程才能被挂起。
5.1. 如果pred的waitStatus == 0，则通过CAS指令修改waitStatus为Node.SIGNAL。
5.2. 如果pred的waitStatus > 0，表明pred的线程状态CANCELLED，需从队列中删除。
5.3. 如果pred的waitStatus为Node.SIGNAL，则通过LockSupport.park()方法把线程A挂起，并等待被唤醒，被唤醒后进入步骤6
线程每次被唤醒时，都要进行中断检测，如果发现当前线程被中断，那么抛出InterruptedException并退出循环。从无限循环的代码可以看出，并不是被唤醒的线程一定能获得锁，必须调用tryAccquire重新竞争，因为锁是非公平的，有可能被新加入的线程获得，从而导致刚被唤醒的线程再次被阻塞，这个细节充分体现了“非公平”的精髓

线程释放锁的过程：

如果头结点head的waitStatus值为-1，则用CAS指令重置为0；
找到waitStatus值小于0的节点s，通过LockSupport.unpark(s.thread)唤醒线程。

CAS的实现原理：
Compare and Swap，比较并替换，通过unsafe类的compareAndSwap方法实现。

Unsafe，是CAS的核心类，由于Java方法无法直接访问底层系统，需要通过本地（native）方法来访问，Unsafe相当于一个后门，基于该类可以直接操作特定内存的数据。
Unsafe类中的compareAndSwap方法：

public final native boolean compareAndSwapInt(
  Object paramObject, long paramLong, int paramInt1, int paramInt2);

各参数的含义：

paramObject：要修改的对象
paramLong：对象中要修改变量的偏移量
paramInt1：修改之前的值
paramInt2：预想修改后的值

系统级别上的实现：

Linux x86：Atomin::cmpxchg方法源码如下：

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, 
  jint compare_value) {
  int mp = os::is_MP();
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    : "=a" (exchange_value)
                    : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                    : "cc", "memory");
  return exchange_value;
}

Windows x86：

inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
    int mp = os::isMP(); //判断是否是多处理器
    _asm {
        mov edx, dest
        mov ecx, exchange_value
        mov eax, compare_value
        LOCK_IF_MP(mp)
        cmpxchg dword ptr [edx], ecx
    }
}

// Adding a lock prefix to an instruction on MP machine
// VC++ doesn't like the lock prefix to be on a single line
// so we can't insert a label after the lock prefix.
// By emitting a lock prefix, we can define a label after it.
#define LOCK_IF_MP(mp) __asm cmp mp, 0  \
                       __asm je L0      \
                       __asm _emit 0xF0 \
                       __asm L0:

LOCK_IF_MP根据当前系统是否为多核处理器决定是否为cmpxchg指令添加lock前缀。

如果是多处理器，为cmpxchg指令添加lock前缀。
反之，就省略lock前缀。（单处理器会不需要lock前缀提供的内存屏障效果）

CAS存在的问题：ABA问题
问题：如果变量V初次读取的时候是A，并且在准备赋值的时候检查到它仍然是A，那能说明它的值没有被其他线程修改过了吗？

如果在这段期间曾经被改成B，然后又改回A，那CAS操作就会误认为它从来没有被修改过。针对这种情况，java并发包中提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。

Reentrantlock非公平锁的实现：
在非公平锁中，每当线程执行lock方法时，都尝试利用CAS把state从0设置为1
竞争过程：

线程A和B同时执行CAS指令，假设线程A成功，线程B失败，则表明线程A成功获取锁，并把同步器中的exclusiveOwnerThread设置为线程A。
竞争失败的线程B，在nonfairTryAcquire方法中，会再次尝试获取锁，Doug lea会在多处尝试重新获取锁，应该是在这段时间如果线程A释放锁，线程B就可以直接获取锁而不用挂起。完

公平锁的实现：
在公平锁中，每当线程执行lock方法时，如果同步器的队列中有线程在等待，则直接加入到队列中.

条件变量Condition：
源码如下：

public class ConditionObject implements Condition, java.io.Serializable {
    /** First node of condition queue. */
    private transient Node firstWaiter;
    /** Last node of condition queue. */
    private transient Node lastWaiter;
    public final void signal() {}
    public final void signalAll() {}
    public final void awaitUninterruptibly() {}  
    public final void await() throws InterruptedException {}
}

Synchronized中，所有的线程都在同一个object的条件队列上等待。而ReentrantLock中，每个condition都维护了一个条件队列。
每一个Lock可以有任意数据的Condition对象，Condition是与Lock绑定的，所以就有Lock的公平性特性：如果是公平锁，线程为按照FIFO的顺序从Condition.await中释放，如果是非公平锁，那么后续的锁竞争就不保证FIFO顺序了。
Condition接口定义的方法，await对应于Object.wait，signal对应于Object.notify，signalAll对应于Object.notifyAll。特别说明的是Condition的接口改变名称就是为了避免与Object中的wait/notify/notifyAll的语义和使用上混淆。

await实现逻辑：

将线程A加入到条件等待队列中，如果最后一个节点是取消状态，则从对列中删除。
线程A释放锁，实质上是线程A修改AQS的状态state为0，并唤醒AQS等待队列中的线程B，线程B被唤醒后，尝试获取锁，接下去的过程就不重复说明了。
线程A释放锁并唤醒线程B之后，如果线程A不在AQS的同步队列中，线程A将通过LockSupport.park进行挂起操作。
随后，线程A等待被唤醒，当线程A被唤醒时，会通过acquireQueued方法竞争锁，如果失败，继续挂起。如果成功，线程A从await位置恢复。

signal实现逻辑：

接着上述场景，线程B执行了signal方法，取出条件队列中的第一个非CANCELLED节点线程，即线程A。另外，signalAll就是唤醒条件队列中所有非CANCELLED节点线程。遇到CANCELLED线程就需要将其从队列中删除。
通过CAS修改线程A的waitStatus为0，表示该节点已经不是等待条件状态，并将线程A插入到AQS的等待队列中。
唤醒线程A，线程A和别的线程进行锁的竞争。

总结：

ReentrantLock提供了内置锁类似的功能和内存语义。
此外，ReetrantLock还提供了其它功能，包括定时的锁等待、可中断的锁等待、公平性、以及实现非块结构的加锁、Condition，对线程的等待和唤醒等操作更加灵活，一个ReentrantLock可以有多个Condition实例，所以更有扩展性，不过ReetrantLock需要显示的获取锁，并在finally中释放锁，否则后果很严重。
ReentrantLock在性能上似乎优于Synchronized，其中在jdk1.6中略有胜出，在1.5中是远远胜出。那么为什么不放弃内置锁，并在新代码中都使用ReetrantLock？
在java1.5中，内置锁与ReentrantLock相比有例外一个优点：在线程转储中能给出在哪些调用帧中获得了哪些锁，并能够检测和识别发生死锁的线程。Reentrant的非块状特性任然意味着，获取锁的操作不能与特定的栈帧关联起来，而内置锁却可以。
因为内置锁时JVM的内置属性，所以未来更可能提升synchronized而不是ReentrantLock的性能。例如对线程封闭的锁对象消除优化，通过增加锁粒度来消除内置锁的同步。

参考资料：《并发编程的艺术》、博客

深入理解锁的实现原理（二）

你可能感兴趣的:(深入理解锁的实现原理（二）)