J.U.C体系进阶（二）：juc-locks 锁框架

Java - J.U.C体系进阶

作者：Kerwin

邮箱：806857264@qq.com

说到做到，就是我的忍道！

juc-locks 锁框架

接口说明

Lock接口

类型	名称
void	lock()
void	lockInterruptibly ()
Condition	newCondition()
boolean	tryClock()
boolean	tryClock(Long time, TimeUnit unit)
void	unlock()

lock()方法类似于使用synchronized关键字加锁，如果锁不可用，出于线程调度目的，将禁用当前线程，并且在获得锁之前，该线程将一直处于休眠状态。

lockInterruptibly()方法顾名思义，就是如果锁不可用，那么当前正在等待的线程是可以被中断的，这比synchronized关键字更加灵活。

Condition接口

可以看做是Obejct类的wait()、notify()、notifyAll()方法的替代品，与Lock配合使用

核心方法 -> awit() signal() signalAll()

ReadWriteLock接口

核心方法 -> readLock() writeLock() 获取读锁和写锁，注意除非使用Java8新锁，否则读读不互斥，读写是互斥的

ReentrantLock类使用

---

ReentrantLock的使用非常简单,Demo如下：

/***
 * TestDemo
 * @author 柯贤铭
 * @date   2019年4月22日
 * @email  806857264@qq.com
 */
public class ReadWriteLockTest {

	private static final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
	private static final WriteLock writeLock = readWriteLock.writeLock();
	private static final ReadLock readLock = readWriteLock.readLock();
	private static final ExecutorService pool = Executors.newFixedThreadPool(50);

	private static int surplusTickets = 100;// 余票量
	private static int surplusThread = 500;// 统计进程执行量，在进程都执行完毕后才关闭主线程

	/**
	 * 运行多线程，进行模拟抢票，并计算执行时间
	 */
	public static void main(String[] args) {
		Date beginTime = new Date();
		for (int i = 0; i < surplusThread; i++) {
			final int runNum = i;
			pool.execute(new Runnable() {
				public void run() {
					boolean getted = takeTicket();

					String gettedMsg = "";
					if (getted) {
						gettedMsg = "has getted";
					} else {
						gettedMsg = "not getted";
					}
					System.out.println("thread " + runNum + " " + gettedMsg + ", remain: " + surplusTickets
							+ ", line up:" + surplusThread + "..");
				}
			});
		}

		while (surplusThread >= 30) {
			sleep(100);
		}

		Date overTime = new Date();
		System.out.println("take times:" + (overTime.getTime() - beginTime.getTime()) + " millis.");
	}

	/**
	 * 查询当前的余票量
	 */
	private static int nowSurplus() {
		readLock.lock();
		int s = surplusTickets;
		sleep(30);// 模拟复杂业务
		readLock.unlock();
		return s;
	}

	/**
	 * 拿出一张票
	 */
	private static boolean takeTicket() {
		writeLock.lock();
		boolean result = false;

		if (nowSurplus() > 0) {
			surplusTickets -= 1;
			result = true;
		}

		surplusThread -= 1;
		writeLock.unlock();
		return result;
	}

	/**
	 * 睡觉觉
	 */
	private static void sleep(int millis) {
		try {
			Thread.sleep(millis);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

说明: 关键点就在获取其读锁和写锁上，为什么要区分?

因为读写互斥，读读不互斥，所以如果不分清楚的话就会让只读操作性能大大下降

另外: 在频繁互斥情况下，其实Lock的性能和synchronized是一样的

但这仅限于在PC端（用新型编译器和虚拟机），如果是在安卓端，synchronized会慢十几倍

LockSupport工具类

---

Doug Lea 的神作concurrent包是基于AQS (AbstractQueuedSynchronizer)框架，AQS框架借助于两个类：Unsafe(提供CAS操作)和LockSupport(提供park/unpark操作)。因此，LockSupport可谓构建concurrent包的基础之一。理解concurrent包，就从这里开始。

归根结底，LockSupport调用的Unsafe中的native代码：

public native void unpark(Thread jthread);
public native void park(boolean isAbsolute, long time);

两个函数声明清楚地说明了操作对象：

park函数是将当前Thread阻塞，而unpark函数则是将另一个Thread唤醒。

与Object类的wait/notify机制相比，park/unpark有两个优点：

• 以thread为操作对象更符合阻塞线程的直观定义；
• 操作更精准，可以准确地唤醒某一个线程（notify随机唤醒一个线程，notifyAll唤醒所有等待的线程），增加了灵活性

举个例子，假设现在需要实现一种FIFO类型的独占锁，可以把这种锁看成是ReentrantLock的公平锁简单版本，且是不可重入的，就是说当一个线程获得锁后，其它等待线程以FIFO的调度方式等待获取锁 ：

public class FIFOMutex {
    private final AtomicBoolean locked = new AtomicBoolean(false);
    private final Queue<Thread> waiters = new ConcurrentLinkedQueue<Thread>();

    public void lock() {
        Thread current = Thread.currentThread();
        waiters.add(current);

        // 如果当前线程不在队首，或锁已被占用，则当前线程阻塞
        // NOTE：这个判断的意图其实就是：锁必须由队首元素拿到
        while (waiters.peek() != current || !locked.compareAndSet(false, true)) {
            LockSupport.park(this);
        }
        waiters.remove(); // 删除队首元素
    }

    public void unlock() {
        locked.set(false);
        LockSupport.unpark(waiters.peek());
    }
}

测试代码：

public class Main {
    public static void main(String[] args) throws InterruptedException {
        FIFOMutex mutex = new FIFOMutex();
        MyThread a1 = new MyThread("a1", mutex);
        MyThread a2 = new MyThread("a2", mutex);
        MyThread a3 = new MyThread("a3", mutex);

        a1.start();
        a2.start();
        a3.start();

        a1.join();
        a2.join();
        a3.join();

        assert MyThread.count == 300;
        System.out.print("Finished");
    }
}

class MyThread extends Thread {
    private String name;
    private FIFOMutex mutex;
    public static int count;

    public MyThread(String name, FIFOMutex mutex) {
        this.name = name;
        this.mutex = mutex;
    }

    @Override
    public void run() {
        for (int i = 0; i < 100; i++) {
            mutex.lock();
            count++;
            System.out.println("name:" + name + "  count:" + count);
            mutex.unlock();
        }
    }
}

park方法的调用一般要方法一个循环判断体里面。

如上述示例中的：

while (waiters.peek() != current || !locked.compareAndSet(false, true)) {
    LockSupport.park(this);
}

之所以这样做，是为了防止线程被唤醒后，不进行判断而意外继续向下执行，这其实是一种的多线程设计模式-Guarded Suspension

AbstractQueuedSynchronizer抽象类

AbstractQueuedSynchronizer抽象类是整个JUC体系的核心，一两句话说不清，如果仅限于使用JUC的话，其实也不用看，如果想知道源码层的话，推荐以下几个博文：

• 概述
• CLH lock queue和自旋锁
• LockSupport源码
• AbstractQueuedSynchronizer源码分析

核心：抽象类采用模板方法模式主要解决何时，何线程，在何状态下 -> acquire和release的问题 获取资源与释放资源

StampedLock Java8新型锁

ReentrantReadWriteLock锁具有读写锁，问题在于ReentrantReadWriteLock使得多个读线程同时持有读锁（只要写锁未被占用），而写锁是独占的 ，很容易造成写锁获取不到资源

解决的必要问题：读锁采用乐观锁机制，非常类似于无锁的操作,使得乐观锁完全不会阻塞写线程，但是API稍微复杂，因此使用时需要注意

StampedLock的主要特点概括一下，有以下几点：

所有获取锁的方法，都返回一个邮戳（Stamp），Stamp为0表示获取失败，其余都表示成功；

所有释放锁的方法，都需要一个邮戳（Stamp），这个Stamp必须是和成功获取锁时得到的Stamp一致；

StampedLock是不可重入的；（如果一个线程已经持有了写锁，再去获取写锁的话就会造成死锁）

StampedLock有三种访问模式：

①Reading（读模式）：功能和ReentrantReadWriteLock的读锁类似

②Writing（写模式）：功能和ReentrantReadWriteLock的写锁类似

③Optimistic reading（乐观读模式）：这是一种优化的读模式。

StampedLock支持读锁和写锁的相互转换

我们知道RRW中，当线程获取到写锁后，可以降级为读锁，但是读锁是不能直接升级为写锁的。

StampedLock提供了读锁和写锁相互转换的功能，使得该类支持更多的应用场景。

无论写锁还是读锁，都不支持Conditon等待

/***
 * TestStampedLock
 * @author 柯贤铭
 * @date   2019年4月22日
 * @email  806857264@qq.com
 */
public class TestStampedLock {

	// StampedLock锁
	private static final StampedLock sLock = new StampedLock();

	// 模拟500张票
	private static Integer total  = 500;

	// 模拟100个人
	private static Integer person = 100;

	private static final ExecutorService pool = Executors.newFixedThreadPool(person);

	private static final CountDownLatch LATCH = new CountDownLatch(person);

	public static void main(String[] args) throws InterruptedException {
		Long start = System.currentTimeMillis();
		for (int i = 0; i < person; i++) {
			final Integer index = i;
			pool.execute(new Runnable() {
				@Override
				public void run() {
					Integer sheng = TestStampedLock.read();
					if (sheng >= 1) {
						try {
							boolean flag = TestStampedLock.buy();
							if (flag) {
								System.out.println("线程 " + index + "买到了");
							} else {
								System.out.println("线程 " + index + "no no no");
							}
						} catch (InterruptedException e) {
							e.printStackTrace();
						}
					} else {
						System.out.println("线程 " + index + "no no no");
					}
					LATCH.countDown();
				}
			});
		}
		LATCH.await();
		Long end = System.currentTimeMillis();
		System.out.println("一共耗时: " + (end - start));
	}

	/**
	 * 读剩余还有几张票
	 * @return
	 */
	private static Integer read () {
		Long stamp = sLock.tryOptimisticRead();
		Integer piao = total;
		if (!sLock.validate(stamp)) {
			stamp = sLock.readLock();
			try {
				piao = total;
			} finally {
				sLock.unlockRead(stamp);
			}
		}
		return piao;
	}

	/***
	 * 买票
	 * @throws InterruptedException
	 */
	private static boolean  buy () throws InterruptedException {
		Long stamp = sLock.writeLock();
		// 模拟复杂操作
		Thread.sleep(30);
		try {
			if (total >= 1) {
				total--;
				return true;
			}
		} finally {
			sLock.unlockWrite(stamp);
		}
		return false;
	}
}

StampedLock乐观锁操作必要步骤：

// 注意：StampedLock的必要操作流程
// 唯一需要注意的地方就是乐观读锁的地方 - 官方Demo
double distanceFormOrigin() {//只读方法
    //试图尝试一次乐观读 返回一个类似于时间戳的邮戳整数stamp
    long stamp = s1.tryOptimisticRead();
    //读取x和y的值,这时候我们并不确定x和y是否是一致的
    double currentX = x, currentY = y;
    //判断这个stamp是否在读过程发生期间被修改过,如果stamp没有被修改过,责任无这次读取时有效的,因此就可以直接return了,反之,如果stamp是不可用的,则意味着在读取的过程中,可能被其他线程改写了数据,因此,有可能出现脏读,如果如果出现这种情况,我们可以像CAS操作那样在一个死循环中一直使用乐观锁,知道成功为止
    if (!s1.validate(stamp)) {
        //也可以升级锁的级别,这里我们升级乐观锁的级别,将乐观锁变为悲观锁, 如果当前对象正在被修改,则读锁的申请可能导致线程挂起.
        stamp = s1.readLock();
        try {
            currentX = x;
            currentY = y;
        } finally {
            s1.unlockRead(stamp);//退出临界区,释放读锁
        }
    }
    return Math.sqrt(currentX * currentX + currentY * currentY);
}