JUC-ReentrantLock与线程

        本篇来观察 ReentrantLock#lock()对线程状态的影响，在此之前，首先要明确的是：我们必须保证【多线程抢占锁】的动作是绝对接近【真正并发执行】的。

1. 方法

方法一

我们通常能够想到的测试方法如下：

/**
 * 注解 @Resource 的name取值来源于 Spring boot 的一个配置类
 * @see TaskExecutionAutoConfiguration#applicationTaskExecutor(TaskExecutorBuilder)
 */
@Resource(name = "applicationTaskExecutor")
private ThreadPoolTaskExecutor threadPoolTaskExecutor;

/**
 * 通过 Java visualVM dump线程快照查看线程状态，主要是分析{@link ReentrantLock#lock()}会让线程状态转换为waiting还是blocked。
 * 当然，通过ReentrantLock#lock()方法的逻辑来看，最终会调用{@link LockSupport#park()}方法，而此方法只会将线程状态变为waiting，而不是blocked。
 *
 * @param createThreadNum 要创建的线程数
 * @param millis          模拟子线程执行实际业务的耗时情况
 * @author youyehaoer
 */
public void lockStateTest(int createThreadNum, long millis) {
    String parentThreadName = Thread.currentThread().getName();
    ReentrantLock reentrantLock = new ReentrantLock();

    // 循环的将task交给线程池
    for (int i = 0; i < createThreadNum; i++) {
        this.threadPoolTaskExecutor.execute(() -> {
            // 抢占锁资源
            reentrantLock.lock();
            try {
                try {
                    // 模拟业务逻辑的耗时
                    Thread.sleep(millis);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                log.info("父线程:[{}], 子线程:[{}]", parentThreadName, Thread.currentThread().getName());
            } finally {
			    // 释放锁资源
                reentrantLock.unlock();
            }
        });
    }
}

---

        在上面的代码中，我们通过 for循环的方式 将task交给线程池，每个task都先去抢占锁资源，只有抢占到锁资源才有资格去执行 业务逻辑。这个看起来貌似没有什么问题，但实际上可能存在以下问题：

        我们假设有5个线程（这里就直接说线程，不说task了），按for循环的顺序来，分别是ThreadA、ThreadB、ThreadC、ThreadD、ThreadE。那么，首先进入for循环的ThreadA肯定会先抢到锁资源，这也就意味着，其他4个线程压根都还没开始执行呢，ThreadA就已经抢占到锁资源，对于ThreadA来说，它并没有跟其他4个线程共同竞争锁资源。这就不是真正意义上的 并发操作。

方法二

        我们想要达到无限接近真正的并发操作，就需要使用到JUC包中的 倒计时锁 —— CountDownLatch。

修改后的代码如下：

/**
 * 注解 @Resource 的name取值来源于 Spring boot 的一个配置类
 * @see TaskExecutionAutoConfiguration#applicationTaskExecutor(TaskExecutorBuilder)
 */
@Resource(name = "applicationTaskExecutor")
private ThreadPoolTaskExecutor threadPoolTaskExecutor;

/**
 * 通过 Java visualVM dump线程快照查看线程状态，主要是分析{@link ReentrantLock#lock()}会让线程状态转换为waiting还是blocked。
 * 当然，通过ReentrantLock#lock()方法的逻辑来看，最终会调用{@link LockSupport#park()}方法，而此方法只会将线程状态变为waiting，而不是blocked。
 *
 * @param createThreadNum 要创建的线程数
 * @param millis          模拟子线程执行实际业务的耗时情况
 * @author youyehaoer
 */
public void lockStateTest(int createThreadNum, long millis) {
    String parentThreadName = Thread.currentThread().getName();
    log.info(parentThreadName +
            "通过 Java visualVM dump线程快照查看线程状态，主要是分析【ReentrantLock#lock()】会让线程状态转换为waiting还是blocked。");
    // 主线程计数器，目的是为了让主线程等待所有子线程执行完成。这个可以不要的。
    CountDownLatch mainCdl = new CountDownLatch(createThreadNum);
    // 子线程计数器，目的是为了能够让所有子线程在同一时间点开始执行。
    CountDownLatch sunCdl = new CountDownLatch(createThreadNum);
    ReentrantLock reentrantLock = new ReentrantLock();

    // 1-
    for (int i = 0; i < createThreadNum; i++) {
        // 异步执行
        this.threadPoolTaskExecutor.execute(() -> {
            try {
                // 1-1 每个子线程执行到这里，就在这里等待。一直等到【1-2】执行完成，也就是等到 sunCdl计数器减为0，才会继续向下执行。
                sunCdl.await();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }

            // 1-3 当【1-2】执行完成的时候，也就是当计数器减为0的时候，所有子线程才会在同一时刻开始执行。在这里也就意味着所有子线程会在同一时刻开始抢占锁资源。
            reentrantLock.lock();
            try {
                try {
                    // 模拟业务逻辑的耗时
                    Thread.sleep(millis);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                log.info("父线程:[{}], 子线程:[{}]", parentThreadName, Thread.currentThread().getName());
            } finally {
			  // 1-4 释放锁资源
                reentrantLock.unlock();
			  // 1-5 主线程计数器减1
                mainCdl.countDown();
            }
        });
    }

    // 1-2 这里对应【1-1】，计数器执行减操作，当for循环执行完成的时候（也就是当计数器减为0的时候），所有子线程才会开始【同时】执行业务代码。
    for (int i = 0; i < createThreadNum; i++) {
        sunCdl.countDown();
    }
    log.info("========== 子线程开始并发执行了 ==========");

    try {
        // 2- 让主线程等在这里，等待所有子线程执行完成。
        mainCdl.await();
        log.info("========== 所有子线程都已执行完成 ==========");
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }
}

2. 测试

        我们直接写一个测试方法去调用上面这个方法就可以了。在测试的时候为了能够达到【挂起线程】的目的，我在这里将 方法入参createThreadNum的值设为20，这个值不能太小，太小的话执行的太快，可能看不到。因为JUC包下的【Lock锁不一定会将线程挂起】，具体线程会不会被挂起取决于它内部的一个方法shouldParkAfterFailedAcquire()，从这个方法名来看就可以知道，“在抢占锁资源失败后是否需要挂起线程”，如果需要挂起，最终会调用 LockSupport.park() 方法，所以，【Lock锁对线程状态的影响 本质上就是 LockSupport.park() 方法对线程状态的影响】。

        我们可以通过 Java visualVM 工具 dump出来线程快照信息 查看， LockSupport.park() 方法会将线程的状态转换为 waiting 还是 blocked。

"SH-Thread9" #65 prio=5 os_prio=0 tid=0x000001a7e537b800 nid=0x5fd0 waiting on condition [0x0000006d5abff000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x0000000718451430> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
        at cn.sh.tools.service.component.lock.LockComponent.lambda$lockStateTest$0(LockComponent.java:38)
        at cn.sh.tools.service.component.lock.LockComponent$$Lambda$415/128568340.run(Unknown Source)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:750)

   Locked ownable synchronizers:
        - <0x0000000723bc65b0> (a java.util.concurrent.ThreadPoolExecutor$Worker)

        上面的结论我们也可以从 java.lang.Thread类的内部类 State枚举类的 WAITING 属性的注释中看出来的。

/**
 * Thread state for a waiting thread.
 * A thread is in the waiting state due to calling one of the
 * following methods:
 * <ul>
 *   <li>{@link Object#wait() Object.wait} with no timeout</li>
 *   <li>{@link #join() Thread.join} with no timeout</li>
 *   <li>{@link LockSupport#park() LockSupport.park}</li>
 * </ul>
 *
 * <p>A thread in the waiting state is waiting for another thread to
 * perform a particular action.
 *
 * For example, a thread that has called <tt>Object.wait()</tt>
 * on an object is waiting for another thread to call
 * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
 * that object. A thread that has called <tt>Thread.join()</tt>
 * is waiting for a specified thread to terminate.
 *
 * 线程等待状态。处于该状态的线程需要等待其他线程对其进行通知（唤醒） 或 中断等操作，进而进入下一个状态。
 * 我们通常说 {@link LockSupport#park()} 方法会将线程挂起，但是很少注意到该方法到底会让线程进入哪种状态。
 * 从上面的英文注释中可以看出来 {@link LockSupport#park()}方法 会将线程状态转换为 waiting，而不是 blocked。
 */
WAITING

3. 题外话

伪代码如下：

// 当多个线程同时执行synchronized代码块时，在同一时刻只会有一个线程成功获取到锁，其他的线程就会进入阻塞状态（blocked状态）。
synchronized(obj) {
    // do something
}