Java中的锁

Java中的锁

锁是用来控制多个线程访问共享资源的方式，一个锁能够防止多个线程同时访问共享资源（有些锁也可以并发访问共享资源，读写锁）。

java.util.concurrent.locks包中包含以下内容：

Lock接口

在Java SE5之前都是靠synchronized关键字实现锁功能，而之后并发包新增了Lock接口以及实现类，使用时需要显示地获取和释放锁。Lock 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作。此实现允许更灵活的结构，可以具有差别很大的属性，可以支持多个相关的 Condition 对象。

不使用块结构锁就失去了使用synchronized 方法和语句时会出现的锁自动释放功能。在大多数情况下，应该使用以下语句：

    Lock l = ...;

     l.lock();

    try {

        // access the resource protected by this lock

    } finally {

        l.unlock();

    }

在finally块中释放锁，目的是保证锁能最终释放。不要将取锁写在try块中，因为在取锁时发生了异常会导致锁无故释放。

Lock接口定义了以下方法：

voidlock()，获取锁。

voidlockInterruptibly()，可中断地获取锁，和lock()不同的是该方法会响应中断，即在锁的获取中可以中断当前线程。

ConditionnewCondition()，获取等待通知组件，该组件和当前的锁绑定，当前线程只有获得了锁，才能调用该组件的wait()方法，调用后，会释放锁。

booleantryLock()，尝试非阻塞的获取锁，该方法调用后立即返回，如果能获取则返回true。

booleantryLock(long time, TimeUnit unit)，如果锁在给定的等待时间内空闲，并且当前线程未被中断，则获取锁。

voidunlock()，释放锁。

AQS队列同步器

AbstractQueuedSynchronizer抽象队列同步器，是用来构建锁或其他同步组件的基础框架。它使用了一个int成员变量表示同步状态，通过内置FIFO队列来完成资源获取线程的排队工作。AQS提供三个（原子式）方法（getState()、setState(int newState)、compareAndSetState(int expect, intupdate)[使用CAS(CompareAndSwap)设置当前状态，保证方法的原子性]）来保证状态的改变是安全的。

继承AQS子类推荐被定义自定义同步组件的静态内部类，同步器自身没有实现任何同步接口。同步器面向使用者时，它定义了接口，隐藏了实现细节；同步器面向实现者时，它简化了锁的实现方式，屏蔽了同步状态管理、线程排队、等待唤醒等底层操作。

 

同步器提供的模板方法基本上分为3类：独占式获取与释放同步状态、共享式获取与释放同步状态、查询同步对列中的等待线程情况。

独占式

同一时刻只能有一个线程获取到锁，而其他线程只能处于同步队列中等待。

在独占锁中，获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中进行自旋。移出队列（或停止自旋）的条件是前驱节点为头节点并且获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

下面给出一个示例实现一个自定义同步组件。直接使用Lock接口即可。

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.AbstractQueuedSynchronizer;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;

/**
 * Created by SunLin on 2018.3.15
 */
public class MyMutex implements Lock {
    /**
     * 静态内部类，自定义同步组件
     */
    private static class Sync extends AbstractQueuedSynchronizer{
        //是否处于占用状态
        protected boolean isHeldExclusively(){
            return getState()==1;
        }
        //状态为0时获取锁
        public boolean tryAcquire(int acquires){
            if(compareAndSetState(0,1)){
               setExclusiveOwnerThread(Thread.currentThread());
                return true;
            }
            return false;
        }
        //释放锁，将状态设置为0
        protected boolean tryRelease(int releases){
            if (getState()==0) throw new IllegalMonitorStateException();
            setExclusiveOwnerThread(null);
            setState(0);
            return true;
        }
        //返回一个Condition，每个condition都包含了一个condition队列
        Condition newCondition(){
            return new ConditionObject();
        }
    }

    /**
     * 将操作代理到Sync上即可
     */
    private final Sync sync = new Sync();
    @Override
    public void lock() {sync.acquire(1);}

    @Override
    public void lockInterruptibly() throws InterruptedException {
        sync.acquireInterruptibly(1);
    }

    @Override
    public boolean tryLock() {return sync.tryAcquire(1);}

    @Override
    public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
        return sync.tryAcquireNanos(1,unit.toNanos(timeout));
    }
   
    @Override
    public void unlock() {sync.release(1);}

    @Override
    public Condition newCondition() {return sync.newCondition();}

    public boolean isLocked(){return sync.isHeldExclusively();}
   
    public boolean hasQueueThreads(){return sync.hasQueuedThreads();}

}

共享式

共享式获取与独占式获取最主要的区别再约同一时刻能否有多个线程同时获取到同步状态。比如对文件的读操作，所有读操作都可达，而写操作被阻塞，而写操作则必须是独占式。通过调用同步器的acquireShared(int arg)方法可以共享式地获取同步状态。当返回值>=0时，表示能够获取到同步状态。releaseShared(intarg)方法释放同步状态，释放状态后会唤醒后续处于等待状态的节点。

 

这里只介绍一些概念上的理解，有一个AQS的详解，介绍的不错https://www.cnblogs.com/waterystone/p/4920797.html

重入锁ReentrantLock

顾名思义就是支持重进入的锁，支持一个线程对资源的重复加锁，同时支持获取锁时的公平性选择。例如前面的例子，如果一个线程lock()获得锁后再次lock()则会被自己阻塞，因为tryAcquire()没有考虑占有锁的线程再次申请锁。而synchronized关键字隐式支持重入锁。

ReentrantLock()创建一个 ReentrantLock 的实例，默认非公平锁。

public ReentrantLock() {
    sync = new NonfairSync();
}

ReentrantLock(boolean fair)创建一个具有给定公平策略的 ReentrantLock，true为公平锁。

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

重进入

线程再次获取锁时，锁需要识别获取锁的线程是否为当前占有锁的线程，如果是，则再次成功获取。线程重复n次获取锁，随后第n次释放锁后，其他线程才可以获取。

比如在非公平锁中：

final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        if (compareAndSetState(0, acquires)) {
            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;
}

该方法增加了再次获取同步状态的处理逻辑，通过判断当前线程是否为获取锁的线程来决定获取操作是否成功，如果是同一线程，则将同步状态值增加并返回true表示同步状态成功。

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

在tryRelease(intreleases)中，前n-1次必须返回false，只有同步状态为0时，将占有线程设置为null，并返回true，表示释放成功。

公平锁

公平锁表示先请求一定是先被满足的FIFO。

步骤大概如下：获取一次锁数量。如果锁数量为0，如果当前线程是等待队列中的头节点，基于CAS尝试将state（锁数量）从0设置为1一次，如果设置成功，设置当前线程为独占锁的线程；如果锁数量不为0或者当前线程不是等待队列中的头节点或者上边的尝试又失败了，查看当前线程是不是已经是独占锁的线程了，如果是，则将当前的锁数量+1；如果不是，则将该线程封装在一个Node内，并加入到等待队列中去。等待被其前一个线程节点唤醒。

非公平锁

非公平锁可能使线程“饥饿”。公平锁保证了锁的获取按照FIFO原则，而代价是大量的线程切换。但非公平锁可能造成“饥饿”，但极少的线程切换保证了吞吐量。

大致步骤如下：基于CAS尝试将state（锁数量）从0设置为1。如果设置成功，设置当前线程为独占锁的线程；如果设置失败，还会再获取一次锁数量。如果锁数量为0，再基于CAS尝试将state（锁数量）从0设置为1一次，如果设置成功，设置当前线程为独占锁的线程；如果锁数量不为0或者上边的尝试又失败了，查看当前线程是不是已经是独占锁的线程了，如果是，则将当前的锁数量+1；如果不是，则将该线程封装在一个Node内，并加入到等待队列中去。等待被其前一个线程节点唤醒。

 

读写锁

前面的锁都是排他锁，而读写锁在同一时刻允许多个读线程访问，但是写线程依然是单独占用资源。读写锁维护了一对锁，一个读锁一个写锁，并发性得到很大的提升。Java并发包提供读写锁的实现是ReentrantReadWriteLock，在原有的公平性选择和重入锁的基础上，还增加了读锁。

悲观锁和乐观锁

悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。再比如Java里面的同步原语synchronized关键字的实现也是悲观锁。

乐观锁：顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提供的乐观锁。在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。

CAS介绍

CAS（Compare and Swap）是乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。　　　

CAS 操作中包含三个操作数—— 需要读写的内存位置（V）、进行比较的预期原值（A）和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配，那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。（在 CAS 的一些特殊情况下将仅返回 CAS 是否成功，而不提取当前值。）CAS 有效地说明了“ 我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。 ”这其实和乐观锁的冲突检查+数据更新的原理是一样的。

CAS自旋就是要么是期望的值然后更新计算后的值，要么不是期望的值，再返回新值后用新值去计算然后再去CAS操作（不成功继续如此）。

乐观锁是一种思想。CAS是这种思想的一种实现方式。

在JDK1.5 中新增 java.util.concurrent (J.U.C)就是建立在CAS之上的。相对于对于 synchronized 这种阻塞算法，CAS是非阻塞算法的一种常见实现。所以J.U.C在性能上有了很大的提升。

CAS与Synchronized的使用情景：　　　

1、对于资源竞争较少（线程冲突较轻）的情况，使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源；而CAS基于硬件实现，不需要进入内核，不需要切换线程，操作自旋几率较少，因此可以获得更高的性能。

2、对于资源竞争严重（线程冲突严重）的情况，CAS自旋的概率会比较大，从而浪费更多的CPU资源，效率低于synchronized。

CAS缺点：

1.       ABA问题。因为CAS需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是A，变成了B，又变成了A，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A。从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。

2.       循环时间长开销大。自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销。如果JVM能支持处理器提供的pause指令那么效率会有一定的提升，pause指令有两个作用，第一它可以延迟流水线执行指令（de-pipeline），使CPU不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起CPU流水线被清空（CPUpipeline flush），从而提高CPU的执行效率。

3.       只能保证一个共享变量的原子操作。当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i＝2,j=a，合并一下ij=2a，然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行CAS操作。

synchronized在jdk1.6之后，已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列，基本思路是自旋后阻塞，竞争切换后继续竞争锁，稍微牺牲了公平性，但获得了高吞吐量。在线程冲突较少的情况下，可以获得和CAS类似的性能；而线程冲突严重的情况下，性能远高于CAS。

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如下：

Condition接口

Object对象，都拥有一组监视器方法，wait()、notify()、notifyAll()，这些方法与synchronized同步关键字配合，可实现等待/通知模式。Condition接口提供了相似的功能。获取一个Condition必须通过Lock的newCondition()方法。使用方法见http://blog.csdn.net/qq407388356/article/details/78535703。

Conditionobject是同步器AQS的内部类。每个Condition对象都包含着一个队列（即等待该对象的队列），该队列是一个FIFO队列，每个节点都包含一个线程引用，即等待的线程。

await()方法会使当前线程进入等待队列并释放锁，该方法返回时当前线程一定是获得了锁。

signal()方法将会唤醒在等待队列中等待时间最长的节点（首节点），在唤醒之前移到同步队列中。

signalAll()方法相当于对等待队列中的每一个节点均执行signal()方法。