Java性能 -- Lock优化

Lock / synchronized

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

实现原理

1. Lock锁是基于Java实现的锁，Lock是一个接口
   • 常见的实现类：ReentrantLock、ReentrantReadWriteLock，都是依赖AbstractQueuedSynchronizer（AQS）实现
2. AQS中包含了一个基于链表实现的等待队列（即CLH队列），用于存储所有阻塞的线程
3. AQS中有一个state变量，该变量对ReentrantLock来说表示加锁状态
4. AQS中的CLH队列的所有操作均通过CAS操作实现的

锁分离优化

ReentrantReadWriteLock

1. ReentrantLock是一个独占锁，同一时间只允许一个线程访问
2. ReentrantReadWriteLock允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问
   • ReentrantReadWriteLock内部维护了两把锁，一把用于读操作的ReadLock，一把用于写操作的WriteLock
3. ReentrantReadWriteLock如何保证共享资源的原子性？ReentrantReadWriteLock也是基于AQS实现的
   • 自定义同步器（继承AQS）需要在同步状态state上维护多个读线程和一个写线程的状态
   • ReentrantReadWriteLock利用了高低位，来实现一个整型控制两种状态的功能
     • 将同步状态state切分为两部分，高16位表示读，低16位表示写

获取写锁

1. 一个线程尝试获取写锁时，会先判断同步状态state是否为0
   • 如果state为0，说明暂时没有其他线程获取锁
   • 如果state不为0，说明其它线程获取了锁
2. 当state不为0时，会再去判断同步状态state的低16位（w）是否为0
   • 如果w为0，说明其它线程获取了读锁，此时直接进入CLH队列进行阻塞等待（因为读锁与写锁互斥）
   • 如果w不为0，说明有线程获取了写锁，此时要判断是不是当前线程获取了写锁
     • 如果不是，进入CLH队列进行阻塞等待
     • 如果是，就应该判断当前线程获取写锁是否超过最大次数，如果超过，抛出异常，否则更新同步状态state

获取读锁

1. 一个线程尝试获取读锁时，同样会先判断同步状态state是否为0
   • 如果state为0，说明暂时没有其他线程获取锁，此时需要判断是否需要阻塞
     • 如果需要阻塞，则进入CLH队列进行阻塞等待
     • 如果不需要阻塞，则CAS更新state为读状态
   • 如果state不为0，说明其它线程获取了锁
2. 当state不为0时，会同步判断同步状态state的低16位
   • 如果存在写锁，直接进入CLH阻塞队列
   • 反之，判断当前线程是否应该被阻塞，如果不应该被阻塞则尝试CAS同步状态，获取成功更新同步锁为读状态

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的悲观读锁、写锁都不支持条件变量（不符合管程模型）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

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同步锁：锁分离

最后，我是小架

我们下篇文章见！

Java性能 -- Lock优化

原文：https://www.cnblogs.com/sevencutekk/p/11534159.html