前言

Java中的锁有很多不同类型，每一个类型的锁在不同的场景中可以发挥更好的性能。

悲观锁 VS 乐观锁

乐观锁是在操作共享资源时，总是认为会成功。所以在操作共享资源时不需要加锁，只有在更新资源的时候会去确认资源在之前是否已经被其他线程更新过，如果被更新过，那么就会重试或者报错，否则就将自己的数据写入。

悲观锁是在操作共享资源时，总是认为会失败。所以在操作共享资源时，首先要进行加锁，确保自己是一定可以获取资源时，才会去进行相应的操作，否则将会挂起。

乐观锁和悲观锁被用在不同的场景中：

乐观锁更多是用于写少读多的场景，因为读操作是不会对资源造成污染的，可以不需要加锁。
悲观锁更多是用于写多读少的场景，因为写操作是需要获取锁的，一次只能有一个线程进行写操作，如果写操作多的话，使用乐观锁将会浪费大量的CPU资源，因为大量的CPU时间尝试写操作从而导致大量的空转。

乐观锁在Java中最常用的操作是CAS自旋算法，而该算法被大量用于原子类的操作中。

悲观锁在Java中最常用的操作就是synchronized关键字和Lock的子类。

在Java中，可以这么使用乐观锁：

// 创建一个原子类的Integer类型
AtomicInteger integer = new AtomicInteger();
// 加1操作
int res = integer.getAndIncrement();
复制代码

我们创建了一个AtomicInteger类型的对象，然后对该对象执行了getAndIncrement方法，该方法的作用是先获取值然后再自增1。

自增操作的内部就是使用CAS算法，也就是无锁的操作。

CAS算法的步骤：CAS算法需要使用三个值，分别为期望值、实际值、新值。假如integer现在为0，现在需要进行自增操作

首先获取integer目前的值，为0，这个值被称为期望值
接着根据该对象在内存中的偏移量，获取内存中存储的值，这个值被称为实际值
对比期望值与实际值。
如果相等，则表示没有其他线程修改过该变量的值，那么就可以使用新值去进行修改。
如果不相等，则表示存在其他线程修改过该变量的值，那么就放弃此次操作。
如果失败了则从步骤1重新开始执行。

除了第1步之外，剩下的2，3，4，5步骤是一个原子操作，通过CPU的cmpxchg指令完成。如果不能保证是原子操作的话，将不能保证在获取完内存中的值后，是否会有其他线程去修改该内存中的值。

我们通过Java的源代码来看CAS的具体实现过程：

通过源码发现，实际是调用了unsafe对象的一个方法来实现的，unsafe对象是属于Unsafe这个类。该类的作用是可以获取到对象中指定变量在内存中的偏移量的值。这个类似于C语言中的指针操作，直接通过指针获取指定内存中的值。该类对于一般的开发人员是不可以使用的，只有JDK内部的开发人员可以使用，因为指针操作是不安全的，开发人员必须小心使用才能保证不会破坏内存中的数据，而对于部分使用Java的程序员来说，并没有这方面的知识储备，所以oracle才不开放使用（猜的）。如果想要使用的话，可以通过反射来使用。

我们可以看到 getAndAddInt方法中，var5就是期望值、var2是偏移量、var5 + var4是新值。通过一个 while循环，直到成功才会退出循环，否则将会一直重试。

CAS的缺点也是很明显的：

ABA问题：假设线程1获取到的期望值为A，然后被其他线程修改为B，接着又被其他线程修改为A，此时线程1去获取实际值依然是A，但是该值却是被修改过的。通过ABA问题对于程序来说都不会造成太大的影响，如果需要解决该问题的话，可以使用一个带有版本号的值，每次执行CAS时，还会对比该版本号，只有版本号一致，才认为该值没有被修改过。Java也提供了一个AtomicStampedReference来解决ABA问题，此时值的修改就会变为A1 -> B2 -> A3
循环开销：如果CAS自旋长时间不成功的话，将会消耗大量的CPU时间。
只能保证单个变量的原子操作：每一次的CAS都只能对一个变量起作用，如果需要同时使用CAS修改多个变量的值，CAS就无法保证原子性了。Java中提供了AtomicReference类将多个变量都集中在一起，只要把多个变量都放入到AtomicReference的对象中就可以实现多个变量原子性的CAS操作。

在Java中，可以这么使用悲观锁：

// 隐式加锁
// synchronized同步方法
public synchronized void test(){}

// synchronized同步块
public void test(){
    synchronized{
        
    }
}

// 显示加锁
ReentrantLock lock = new ReentrantLock();
public void test(){
    // 加锁
    lock.lock();
    
    // 释放锁
    lock.unlock();
}
复制代码

在Java中，这两种加锁方式是比较常见的。悲观锁每次只有一个线程可以获得锁，获得锁后就可以执行临界区中的代码，其他线程如果要进入临界区，只能等待持有锁的线程释放锁，然后才会有机会获得锁，并执行临界区代码。

自旋锁 VS 自适应自旋锁

自旋锁是线程在遇到需要阻塞等待锁的时候，并不会马上进行阻塞，而是自旋获取锁，如果可以获得锁，那么就不需要进行阻塞挂起，如果自旋一定时间或次数还是没有获得锁，才进行阻塞挂起。

要了解自旋锁的目的首先要知道阻塞和唤醒Java线程是需要切换CPU状态来完成的，发生阻塞或者唤醒线程的系统调用导致CPU从用户态切换为核心态时，是需要消耗较多CPU资源的。如果我们让线程先自旋一定次数或时间，在这段时间如果能够获取到锁，那么就会减少CPU状态的切换，从而避免了线程切换的开销。

在许多场景下，同步资源的锁定时间都是很短的，为了这很短的时间从而增加了保存现场和恢复现场的开销是得不偿失的。

自旋锁也是存在缺点的，它不能代替阻塞。自旋虽然避免了线程切换带来的开销，但同时也增加了CPU执行的时间。在自旋的这段时间中，CPU的资源是白白消耗了的，如果锁持有的时间是很短的情况下，自旋的效果是很好的，但是如果长时间自旋得不到结果，那么就会导致过多的CPU资源被消耗掉，所以，线程不能无限制的自旋下去，而是要限制自旋的次数，当达到自旋次数限制的时候就要进行阻塞。在Java中，默认的自旋次数为10次。

JVM中可以通过设置-XX:+UseSpinning开启自旋锁，JDK6之后，默认是开启的。

JVM中可以通过设置-XX:PreBlockSpin来设置自旋次数。默认是10次。

在JDK6中，Java团队又为自旋锁增加了自适应，变为了自适应自旋锁，也就是自旋锁的次数（时间）不再是固定的了。而是根据上一个持有该锁的线程的自旋次数（时间）和状态来决定的，如果上一个线程刚刚通过自旋获得了锁，并且该线程还在运行中，那么JVM认为此次自旋的也是可以成功的，所以会适当的延长自旋时间，如果某一个自旋锁很少成功，那么JVM就会认为自旋的成功率很小，从而忽略自旋，直接进行阻塞。因为自旋所能获得的收益非常小，甚至可能是负收益。

自适应的自旋锁避免了因为长等待的锁也使用自旋锁，导致浪费了很多不必要的CPU资源的情况。

如果是短等待的锁的话，自旋带有的收益是很明显了，它避免了线程切换带来的开销。

公平锁 VS 非公平锁

公平锁是指线程成功获取锁的顺序按照线程申请获取锁的顺序进行，线程申请锁的时候会进入到一个队列中排队，每一次有线程申请获取锁都会排在队列的最末尾，排在最前面的线程首先获取锁，以此类推。

对于公平锁形象化的解释就是：有一个售票处，每个人都必须按照先后秩序排队购票，因为有管理员的存在，不会存在插队的情况，每个需要购票的用户都必须排在队伍的末尾，而且只有前面的顾客购票完成之后才可以去购票，否则只能等待。

非公平锁则存在一种插队的情况，但是插队也不是任何时候都可以插队的，只有在刚好前一个购票完成，后一个购票还未开始时，才可以进行插队。如果在前一个还未购票完成时，是无法进行插队的，只能正常排队。

非公平锁也不一定就是随机获取的，依然存在排队的情况，而且排队中的线程获取锁的情况是与公平锁一样的。不一样的只有线程在获取锁的时候是有机会直接获取到锁，而不需要等待已经在队列中的线程都获取完锁。

非公平锁的性能比公平锁的性能要高一些，因为它较少了线程切换的开销：

对于公平锁而言，只要队列中存在等待的线程，那么当前线程就必定会被阻塞挂起，等待唤醒。
对于非公平锁而言，如果队列中存在等待的线程，在获取锁的时候，会先尝试是否可以成功获取到锁，如果能够成功，则避免了线程切换的开销。如果失败了，则依然要被阻塞挂起，等待唤醒，再获取锁资源。

在Java中，ReentrantLock提供了公平锁和非公平锁。

public class ReentrantLock implements Lock{
    public ReentrantLock() {
        sync = new NonfairSync();
    }
    
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }
}
复制代码

ReentrantLock默认是为非公平锁，可以通过给构造函数传递true来显示指定获得公平锁。

可重入锁 VS 不可重入锁

可重入锁是指已经获取了指定锁资源的线程，在未释放指定锁资源的情况下，再次获取该指定的锁资源的时候不会发生阻塞。更加通俗的讲就是在外层代码已经获取了锁资源的情况下，在内层代码中依然可以获取到相同的锁资源。Java中的ReentrantLock、synchronized都是可重入锁。可重入锁在一定程序上避免了死锁的发生。

可重入锁：每个顾客在买票的时候，管理员允许了每一个锁跟每一个顾客的多个取票票据绑定，顾客可以在取完一次票后，可以不放弃锁，继续选择将锁与其他票据绑定去取票。

但如果是不可重入锁的话，管理员只允许每一个锁与每个顾客的一个取票票据绑定。那么顾客就不能在取完一个票后继续取票，因为锁还未归还给管理员，另外一个票据还无法与锁绑定。此时，就会发生死锁。

不可重入锁：在主流程中已经获得了锁，如果想要在子流程中再次获取该锁，是无法获取的，并且会发生死锁，因为子流程一直在等待主流程释放锁，而主流程因为子流程没有执行完，并不会释放锁。

我们可以想象一下如果synchronized是非可重入锁的话会怎么样：

public class Test {
    public synchronized void firstStep(){
    }

    public synchronized void secondStep(){
    }
}

复制代码

对于这个示例，如果在firstStep方法中调用secondStep方法的话，就会发生死锁。这样，我们在编写代码的时候，发生死锁的几率就会很大，因为这两个方法的锁都是同一个对象。

共享锁 VS 独占锁

共享锁是对于同一个锁，可以有多个线程同时获得锁；

独占锁则是每次只有一个线程可以获得锁，其他线程需要获得该锁，则需要等待获得锁的线程释放锁才有机会。

在ReentrantReadWriteLock中则同时使用了共享锁和独占锁。其中，共享锁用于读操作、独占锁用于写操作。

因为读操作是使用共享锁，所以可以支持高效的并发读操作。而对于读写、写写、写读操作，为了数据的一致性，都是必须互斥的。因为读锁和写锁的分离，相比于一般的互斥锁，有较大的性能提升。

我们直接看ReentrantReadWriteLock中是如何通过AQS来实现读锁和写锁共存的：

public class ReentrantReadWriteLock
        implements ReadWriteLock, java.io.Serializable {
    private static final long serialVersionUID = -6992448646407690164L;
    /** Inner class providing readlock */
    private final ReentrantReadWriteLock.ReadLock readerLock;
    /** Inner class providing writelock */
    private final ReentrantReadWriteLock.WriteLock writerLock;
    /** Performs all synchronization mechanics */
    final Sync sync;

    /**
     * Creates a new {@code ReentrantReadWriteLock} with
     * default (nonfair) ordering properties.
     */
    public ReentrantReadWriteLock() {
        this(false);
    }

    /**
     * Creates a new {@code ReentrantReadWriteLock} with
     * the given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantReadWriteLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
        readerLock = new ReadLock(this);
        writerLock = new WriteLock(this);
    }
}
复制代码

我们可以看到类中里面存在一个ReadLock和一个WriteLock，而这两个类实现了Lock接口，也就是真正的锁是由这两个类来实现的。

我们可以看到这两个类里面都有Sync类成员，该类则继承了AQS。Sync类才是真正的锁。

在ReentrantReadWriteLock中将锁的状态切分为了两种状态，其中高16位表示读锁的个数，低16位表示写锁的个数。

我们直接看写锁的加锁代码：

final boolean tryWriteLock() {
    Thread current = Thread.currentThread(); // 获取当前线程
    int c = getState(); // 获取锁的状态
    if (c != 0) { // 判断是否存在线程获取了锁
        int w = exclusiveCount(c); // 获取占有独占锁的线程数量
        if (w == 0 || current != getExclusiveOwnerThread()) // 存在读锁或者占有独占锁的线程不是当前线程，则失败
            return false;
        if (w == MAX_COUNT) // 如果可重入的独占锁数量饱和，则失败
            throw new Error("Maximum lock count exceeded");
    }
    if (!compareAndSetState(c, c + 1)) // 设置写锁的状态。因为写锁是低16位，所以直接加1即可
        return false;
    setExclusiveOwnerThread(current); // 设置当前占有独占锁的线程
    return true; // 成功
}
复制代码

如果存在读锁、或者当前线程不等于独占锁的线程，则返回失败
如果锁的数量已经饱和，返回失败。读锁和写锁最大可重入的锁数量均为65535
如果上面皆为失败，则使用CAS设置写锁的状态，设置独占锁的线程为当前线程。

写锁除了是独占锁这个条件之外，还添加了一个判断是否存在读锁的条件，如果存在读锁，则加锁失败。这是为了保证写锁期间的修改，对于正在运行的读锁的线程来说必须是可见的。如果允许在读锁期间，写锁也可以被获取，那么在当前正在运行的读线程就无法感知到写线程的操作，从而造成读写不一致的情况。

我们接着来看读锁的加锁代码：

final boolean tryReadLock() {
    Thread current = Thread.currentThread(); \\ 获取当前线程
    for (;;) { \\ 无限循环
        int c = getState(); \\ 获取当前锁状态 
        if (exclusiveCount(c) != 0 &&  \\ 如果存在写锁并且占用写锁的线程不是当前线程，则返回失败
            getExclusiveOwnerThread() != current)
            return false;
        int r = sharedCount(c); \\ 获取共享锁的数量
        if (r == MAX_COUNT) \\ 确定锁的数量未饱和
            throw new Error("Maximum lock count exceeded");
        if (compareAndSetState(c, c + SHARED_UNIT)) { // 后面就是添加读锁的个数
            if (r == 0) {
                firstReader = current;
                firstReaderHoldCount = 1;
            } else if (firstReader == current) {
                firstReaderHoldCount++;
            } else {
                HoldCounter rh = cachedHoldCounter;
                if (rh == null || rh.tid != getThreadId(current))
                    cachedHoldCounter = rh = readHolds.get();
                else if (rh.count == 0)
                    readHolds.set(rh);
                rh.count++;
            }
            return true;
        }
    }
}
复制代码

如果其他线程中已经持有了写锁，那么当前线程获取读锁失败
如果读锁的数量已经饱和，那么获取读锁失败
增加读锁的状态、成功获取读锁。

每次读锁的释放都会减少读状态。只有读读的状态是共享的，只有存在着写锁相关的操作，那么就都是互斥的。

无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁

要理解Java中的锁对象，那么Java对象头结构就必须得了解清楚。

Java的对象头包括两部分内容：

Mark Word : 默认存储对象的HashCode，分代年龄和锁标志位信息。但是会根据对象的锁状态，从而改变这部分的内容。如下图所示。
Klass Point : 指向类型的指针，用于确定该对象是属于哪个类的实例

锁的级别目前有四级：有低至高分别是：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁

锁只能升级，不能降级。也就是不能从轻量级锁变为偏向锁状态等等，但是只要对象释放了锁，那么就会恢复到无锁状态，到时候就又要从无锁状态开始，慢慢升级。

无锁

无锁就是没有对资源进行锁定，所有的线程都可以对资源进行访问和修改，但是只有一个线程可以成功。

其实CAS就是无锁的一样实现方式，但是无锁并不能替代锁，因为无锁的弊端也是很明显的，我们只有在某些场景下才能使用无锁。

偏向锁

偏向锁的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。

偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不去做了。偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

如果锁总是由同一个线程获得，不存在多线程竞争，那么偏向锁的效果将会非常明显，因为它消除了获取锁的代价。

当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为01，把偏向模式设置为1，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁，解锁及对Mark Word的更新操作等）

一旦出现另外一个线程去尝试获取这个锁的情况，偏向锁模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向，撤销后标志位恢复到未锁定或者轻量级锁定的状态，后续的同步操作就按照轻量级锁那样去执行。

假设一个对象刚开始实例化的时候，还没有任何线程持有该对象的锁，此时它是可以被偏向的。如果此时有一个线程来获取该对象的锁，它会偏向该线程，设置对象为偏向模式，并用CAS操作去设置对象的Mark Word，将Thread Id设置为获取该对象锁的线程的ID。如果该线程下次再来获取该对象的锁时就无需再进行CAS操作了，直接对比Mark Word中的Thread ID即可。

如果有第二个线程来获取该对象的锁，因为偏向锁不会主动释放，所以第二个线程是可以看得到该锁的偏向模型，此时它会检测第一个线程是否还存活，如果已经死去了，则设置对象为无锁状态，重新进入偏向模式。

如果检测到第一个线程依然存活，则会去检测该线程的操作栈，检测该线程是否依然需要持有偏向锁，如果不需要，则设置对象为无锁状态，重新进入偏向模式。

如果检测到第一个线程依然存活，并且检测到该线程依然需要持有偏向锁，则会将该偏向锁升级为轻量级锁。

如果在轻量级锁期间，第一个线程持有锁，第二个线程自旋等待获取锁，一个新的第三个线程也来获取该锁，此时就会出现对象锁的竞争，则会将该轻量级锁升级为重量级锁，重量级锁会将除了使用该锁的线程之外，都阻塞等待，防止CPU资源浪费。

在偏向锁的状态下，对象头的Mark Word都存储了线程ID，那么它要如何恢复对象的哈希码呢？因为哈希码只会计算一次，计算过一次之后就应该保持该值不变。所以应该要有一个地方将该计算好的哈希码存储起来，在轻量级锁的状态下，该哈希码是存储栈的Displaced Mark Word中的，在重量级锁的状态下，对象头指向了重量级锁的位置，代表重量级锁的ObjectMonitor类中有字段记录非加锁状态下的Mark Word。

但是偏向锁并没有存储能够存储哈希码的地方，所以当一个对象已经计算过一次一致性哈希码后，它就再也无法进入偏向锁状态了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。

计算一致性哈希码是说调用Object::hashCode()、System:identityHashCode(Object)这两个方法，如果程序员重写了对象的hashCode()方法，那么就不会发生将锁膨胀为重量级锁的情况。

轻量级锁

轻量级锁是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就被称为重量级锁。不过，轻量级锁并不是用来替代重量级锁的，它的使用场景只是基于没有多线程竞争的条件下，减少传统重量级锁使用操作系统互斥量产生的性能损耗。

轻量级锁的工作过程：在代码即将进入同步块的时候，如果此同步对象没有被锁定（锁标记位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录的空间，用于存储锁对象目前的Mark Work的拷贝（官方为这份拷贝加了一个Displaced前缀，即Displaced Mark Word）。

然后，虚拟机将使用CAS操作尝试把对象的mark work更新为指向Lock Record的指针。如果这个更新动作成功了，即代表该线程拥有了这个对象的锁，并且对象Mark Word的锁标志位将转变为00，表示此对象处于轻量级锁定状态。

实质是将对象头中的前32bit复制到displaced hdr，owner存放的是对象头的地址，也就是指向对象头。然后对象头的前30bit存储存储指向栈帧中锁记录的地址空间。

如果更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了，否则就说明这个锁对象已经被其他线程抢占了。

如果出现了两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为10，此时Mark Word中存储的就是指向重量级锁的指针，后面等待的线程也必须进入阻塞状态。

轻量级锁的解锁过程也同样是通过CAS操作来进行的，如果对象的Mark Word仍然指向线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来。加入能够成功替换，那整个同步过程就顺利完成了；如果替换失败，则说明有其他线程尝试过获取此锁，就要在释放锁的同时，唤醒被挂起的线程。

如果没有竞争，轻量级锁便通过CAS操作成功避免了使用互斥量的开销；但如果确实存在竞争，除了互斥量的本身开销外，还额外发生了CAS操作的开销。因为在有竞争的情况下，轻量级锁反而会比传统的重量级锁更慢。

重量级锁

重量级锁就是我们平常说的互斥锁。

升级为重量级锁时，锁标志的状态值变为“10”，此时Mark Word中存储的是指向重量级锁的指针，此时等待锁的线程都会进入阻塞状态。

综上，偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作。而轻量级锁是通过用CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒而影响性能。重量级锁是将除了拥有锁的线程以外的线程都阻塞。

参考

不可不说的Java“锁”事
《深入理解Java虚拟机第三版》

Java中的重重“锁”事

前言