java基础总结(九十)--性能：Lock的锁之优化

墨蓝 2022-10-31 04:27 156阅读 0赞

[原文链接][Link 1]

## **Lock / synchronized** ##

Lock锁的基本操作是通过乐观锁实现的，由于Lock锁也会在阻塞时被挂起，依然属于悲观锁

synchronizedLock实现方式JVM层实现Java底层代码实现锁的获取JVM隐式获取lock() / tryLock() / tryLock(timeout, unit) / lockInterruptibly()锁的释放JVM隐式释放unlock()锁的类型非公平锁、可重入非公平锁/公平锁、可重入锁的状态不可中断可中断锁的性能高并发下会升级为重量级锁更稳定

## **实现原理** ##

1.  Lock锁是基于Java实现的锁，Lock是一个接口

*  常见的实现类：ReentrantLock、ReentrantReadWriteLock，都是依赖AbstractQueuedSynchronizer（AQS）实现

1.  AQS中包含了一个基于链表实现的等待队列（即CLH队列），用于存储所有阻塞的线程
2.  AQS中有一个state变量，该变量对ReentrantLock来说表示加锁状态
3.  AQS中的CLH队列的所有操作均通过CAS操作实现的

![e0523f82941178a8107b0d10e397536a.png][]

## **锁分离优化** ##

**ReentrantReadWriteLock**

1.  ReentrantLock是一个独占锁，同一时间只允许一个线程访问
2.  ReentrantReadWriteLock允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问

*  ReentrantReadWriteLock内部维护了两把锁，一把用于读操作的ReadLock，一把用于写操作的WriteLock

1.  ReentrantReadWriteLock如何保证共享资源的原子性？ReentrantReadWriteLock也是基于AQS实现的

*  自定义同步器（继承AQS）需要在同步状态state上维护多个读线程和一个写线程的状态
 *  ReentrantReadWriteLock利用了高低位，来实现一个整型控制两种状态的功能
 *  将同步状态state切分为两部分，高16位表示读，低16位表示写

**获取写锁**

1.  一个线程尝试获取写锁时，会先判断同步状态state是否为0

*  如果state为0，说明暂时没有其他线程获取锁
 *  如果state不为0，说明其它线程获取了锁

1.  当state不为0时，会再去判断同步状态state的低16位（w）是否为0

*  如果w为0，说明其它线程获取了读锁，此时直接进入CLH队列进行阻塞等待（因为读锁与写锁互斥）
 *  如果w不为0，说明有线程获取了写锁，此时要判断是不是当前线程获取了写锁
 *  如果不是，进入CLH队列进行阻塞等待
 *  如果是，就应该判断当前线程获取写锁是否超过最大次数，如果超过，抛出异常，否则更新同步状态state

![599c09eb884a6701cd0d10331cf83da8.png][]

**获取读锁**

1.  一个线程尝试获取读锁时，同样会先判断同步状态state是否为0

*  如果state为0，说明暂时没有其他线程获取锁，此时需要判断是否需要阻塞
 *  如果需要阻塞，则进入CLH队列进行阻塞等待
 *  如果不需要阻塞，则CAS更新state为读状态
 *  如果state不为0，说明其它线程获取了锁

1.  当state不为0时，会同步判断同步状态state的低16位

*  如果存在写锁，直接进入CLH阻塞队列
 *  反之，判断当前线程是否应该被阻塞，如果不应该被阻塞则尝试CAS同步状态，获取成功更新同步锁为读状态

![500f6da7836dd6f2d3074221979d82c2.png][]

**StampedLock**

**1**.ReentrantReadWriteLock被很好地应用在读多写少的并发场景中，但会存在写线程饥饿的问题

*  Java 8引入StampedLock解决了这个问题

**2.**StampedLock不是基于AQS实现的，但实现原理与AQS类似，都是基于队列和锁状态

3.StampedLock有三种模式：写、悲观读、乐观读，StampedLock在获取锁时会返回一个票据stamp

**4.**一个写线程获取写锁的过程中，首先是通过writeLock获取一个票据stamp（表示锁的版本）

*  WriteLock是一个独占锁，同时只能有一个线程可以获取WriteLock
 *  当一个线程获取WriteLock后，其他请求的线程必须等待
 *  当没有其他线程持有读锁或者写锁时才可以获得WriteLock

**5.**一个读线程获取读锁的过程中，首先会通过tryOptimisticRead获取一个票据stamp

*  如果当前没有线程持有写锁，会返回一个非0的stamp
 *  然后调用validate验证之前调用tryOptimisticRead返回的stamp在当前是否有其他线程持有了写锁
 *  如果是，那么validate返回0，升级为悲观锁

**6.**相对于ReentrantReadWriteLock，StampedLock获取读锁只使用了与或操作进行校验，不涉及CAS操作

*  即使第一次乐观锁获取失败，也会马上升级为悲观锁，可以避免一直进行CAS操作而带来的CPU性能消耗问题

**7.**但StampedLock并没有被广泛使用，有几个主要原因

*  StampedLock的功能仅仅只是**ReadWriteLock的子集**
 *  StampedLock**不支持重入！**！
 *  StampedLock的**悲观读锁、写锁都不支持条件变量（不符合管程模型）**

public class Point {
     private double x, y;
     private final StampedLock lock = new StampedLock();
     public void move(double deltaX, double deltaY) {
     // 获取写锁
     long stamp = lock.writeLock();
     try {
     x += deltaX;
     y += deltaY;
     } finally {
     // 释放写锁
     lock.unlockWrite(stamp);
     }
     }
     double distanceFromOrigin() {
     // 乐观读
     long stamp = lock.tryOptimisticRead();
     // 拷贝变量
     double currentX = x, currentY = y;
     // 判断读期间是否有写操作
     if (!lock.validate(stamp)) {
     // 升级为悲观读
     stamp = lock.readLock();
     try {
     currentX = x;
     currentY = y;
     } finally {
     lock.unlockRead(stamp);
     }
     }
     return Math.sqrt(currentX * currentX + currentY + currentY);
     }
    }

## **小结** ##

**1.**不管使用**synchronized同步锁**还是**Lock同步锁**，只要存在**锁竞争**就会产生**线程阻塞**，导致**线程频繁切换**，增加**性能消耗**

**2.**优化锁的关键：**降低锁竞争**

*  synchronized同步锁：**减少锁粒度**、**减少锁占用时间**
 *  Lock同步锁：**锁分离**

我是小架，

我们下篇文章见！

[Link 1]: https://zhuanlan.zhihu.com/p/82857579
[e0523f82941178a8107b0d10e397536a.png]: /images/20221024/8c53a1b3ac44490db01202dd97c31137.png
[599c09eb884a6701cd0d10331cf83da8.png]: /images/20221024/5739f9054029488a882b2a3146c6106c.png
[500f6da7836dd6f2d3074221979d82c2.png]: /images/20221024/32d907fbfa6e46b4be20465eb2fb8cb5.png