(十一)彻悟并发之JUC分治思想产物-ForkJoin分支合并框架原理剖析上篇

引言

在上篇文章《深入理解并发之Java线程池、工作原理、复用原理及源码分析》中，曾详细谈到了Java的线程池框架。在其中也说到了JDK提供的四种原生线程池以及自定义线程池，而本文则再来详细谈谈JDK1.7中新推出的线程池：ForkJoinPool。但ForkJoinPool的出现并不是为了替代ThreadPoolExecutor，而是作为它的补充，因为在某些场景下，它的性能会比ThreadPoolExecutor更好。在之前的模式中，往往一个任务会分配给一条线程执行，如果有个任务耗时比较长，并且在处理期间也没有新的任务到来，那么则会出现一种情况：线程池中只有一条线程在处理这个大任务，而其他线程却空闲着，这会导致CPU负载不均衡，空闲的处理器无法帮助工作，从而无法最大程度上发挥多核机器的性能。而ForkJoinPool则可以完美解决这类问题，但ForkJoinPool更适合的是处理一些耗时的大任务，如果是普通任务，反而会因为过多的任务拆分和多条线程CPU的来回切换导致效率下降。

一、初窥ForkJoin框架的神秘面纱

ForkJoinPool是一个建立在分治思想上的产物，其采用任务“大拆小”的方式以及工作窃取算法实现并行处理任务。通俗来说，ForkJoin框架的作用主要是为了实现将大型复杂任务进行递归的分解，直到任务小到指定阈值时才开始执行，从而递归的返回各个小任务的结果汇集成一个大任务的结果，依次类推最终得出最初提交的那个大型复杂任务的结果，这和方法的递归调用思想是一样的。当然ForkJoinPool线程池为了提高任务的并行度和吞吐量做了非常多而且复杂的设计实现，其中最著名的就是任务窃取机制。但ForkJoinPool更适合于处理一些大型任务，因此，ForkJoinPool的适用范围不大，仅限于某些密集且能被分解成多个子任务的任务，同时这些子任务运行的结果可以合并成最终结果。ForkJoin框架主体由三部分组成：

• ①ForkJoinWorkerThread：任务的执行者，具体的线程实体
• ②ForkJoinTask：需要执行的任务实体
• ③ForkJoinPool：管理执行者线程的管理池

后续源码阶段会详细分析！

OK~，接着先简单的来看看ForkJoin框架的使用，ForkJoinPool提交任务的方式也有三种，分别为：

• execute()：可提交Runnbale类型的任务
• submit()：可提交Callable类型的任务
• invoke()：可提交ForkJoinTask类型的任务，但ForkJoinTask存在三个子类：
  • ①RecursiveAction：无返回值型ForkJoinTask任务
  • ②RecursiveTask：有返回值型ForkJoinTask任务
  • ③CountedCompleter：任务执行完成后可以触发钩子回调函数的任务

上个案例：

业务需求：需要根据ID值对某个范围区间内的每条数据进行变更，变更后获取最新数据更新缓存。
运行环境：四核机器

public class ForkJoinPoolDemo {
    public static void main(String[] args) {
        testFor();
        testForkJoin();
    }
    
    // 测试for循环
    private static void testFor(){
        Instant startTime = Instant.now();
        List list = new ArrayList();
        for (int id = 1; id <= 1000*10000; id++) {
            // ....... 模拟从数据库根据id查询数据
            list.add(id);
        }
        Instant endTime = Instant.now();
        System.out.println("For循环耗时："+
            Duration.between(startTime,endTime).toMillis() + "ms");
    }
    
    // 测试ForkJoin框架
    private static void testForkJoin(){
        ForkJoinPool forkJoinPool = new ForkJoinPool();
        Instant startTime = Instant.now();
        List invoke = forkJoinPool.invoke(new IdByFindUpdate(1, 1000*10000));
        Instant endTime = Instant.now();
        System.out.println("ForkJoin耗时："+
            Duration.between(startTime,endTime).toMillis() + "ms");
    }
}

class IdByFindUpdate extends RecursiveTask {
    private Integer startID;
    private Integer endID;

    private static final Integer THURSHOLD = 10000; // 临界值/阈值

    public IdByFindUpdate(Integer startID, Integer endID) {
        this.startID = startID;
        this.endID = endID;
    }

    @Override
    protected List compute() {
        int taskSize = endID - startID;
        List list = new ArrayList();

        // 如果任务小于或等于拆分的最小阈值，那么则直接处理任务
        if (taskSize <= THURSHOLD) {
            for (int id = startID; id <= endID; id++) {
                // ....... 模拟从数据库根据id查询数据
                list.add(id);
            }
            return list;
        }
        // 任务fork拆分
        IdByFindUpdate leftTask = new IdByFindUpdate(startID,
                                (startID + endID) / 2);
        leftTask.fork();
        IdByFindUpdate rightTask = new IdByFindUpdate(((startID
                                + endID) / 2) + 1, endID);
        rightTask.fork();

        // 任务join合并
        list.addAll(leftTask.join());
        list.addAll(rightTask.join());

        return list;
    }
}

案例如上，在其中模拟了数据库查询1000W数据后，将数据添加到集合中的操作。其中定义了任务类：IdByFindUpdate，因为需要返回结果，所以IdByFindUpdate类实现了ForkJoinTask的子类RecursiveTask，确保任务可以提交给ForkJoinPool线程池执行。任务的拆分阈值设定为1W，当任务的查询数量小于阈值时，则直接执行任务。反之，拆分任务直至最小（达到阈值）为止才开始执行，执行结束后合并结果并返回。

同时，我们为了对比区别，也使用了普通的for循环来对比测试，结果如下：

/* 运行结果：
 *      For循环耗时：3274ms
 *      ForkJoin耗时：1270ms
 */

很明显，ForkJoin的执行速度比普通的for循环速度快上三倍左右，但是值得一提的是：如果任务的量级太小，ForkJoin的处理速度反而比不上普通的For循环。这是因为ForkJoin框架在拆分任务fork阶段于合并结果join阶段需要时间，并且开启多条线程处理任务，CPU切换也需要时间，所以当一个任务fork/join阶段以及CPU切换的时间开销大于原本任务的执行时间时，这种情况下则没有必要使用ForkJoin框架。

注意：ForkJoin的执行时间跟机器硬件配置以及拆分临界值/阈值的设定也有关系，拆分的阈值并不是越小越好，因为阈值越小时，一个任务拆分的小任务也就会越多，而拆分、合并阶段都是需要时间的，所以阈值需要根据机器的具体硬件设施和任务的类型进行合理的计算，这样才能保证任务执行时能够到达最佳状态。

ok，我也做了一个比较有意思的小测试，把单线程for循环的模式来处理上述任务以及ForkJoin框架处理上述任务分别分为了两次来执行，同时监控了CPU的利用率状况，具体如下：

CPU利用率对比

通过上图可以非常清晰的看见，当单线程for循环的模式处理任务时，因为是在多核机器上执行，所以对于CPU的利用率最高不到50%，而当使用ForkJoin框架处理任务时，几次触顶达到了100%的CPU利用率。所以我们可以得出一个结论：ForkJoin框架在处理任务时，能够在最大程度上发挥机器的性能。

二、ForkJoin框架原理浅析及成员构成

在如上，对于ForkJoin框架已经建立的初步的认知，接着慢慢继续分析其内部实现过程。

2.1、ForkJoin框架原理

在前面提到过，ForkJoin框架是建立在分治思想上的产物，而向FoorkJoinPool中传递一个任务时，任务的执行流程大体如下：

ForkJoin框架执行流程

从图中可以很轻易的明白：提交的任务会被分割成一个个小的左/右任务，当分割到最小时，会分别执行每个小的任务，执行完成后，会将每个左/右任务的结果进行，从而合并出父级任务的结果，依次类推，直至最终计算出整个任务的最终结果。

工作窃取：在引言中曾提到过ForkJoin框架是基于分治和工作窃取思想实现的，那么何谓工作窃取呢？先举个例子带大家简单理解一下这个思想，具体的实现会在后面的源码分析中详细谈到。
例子：我是开了个工厂当老板，一条流水线上招聘八个年轻小伙做事，每个人安排了五十个任务，并且对他们说：“你们是一个团队，必须等到每个人做完了自己的任务之后才能一起下班！”。但是在这八个小伙里面，有手比较灵巧做的比较快的，也有做的比较慢、效率比较低的人。那么当一段时间过后，代号③的小伙率先完成了分配给自己的任务后，为了早些下班，会跑到一些做的比较慢的小伙哪儿去拿一些任务过来帮助完成进度，这便是工作窃取思想。在ForkJoin框架同样存在这样的情况，某条线程已经执行完成了分配给自己的任务后，有些线程却还在执行并且堆积着很多任务，那么这条已经处理完自己任务的线程则会去“窃取”其他线程的任务执行。

2.2、ForkJoin框架成员分析

在前面说过，ForkJoin框架是由三部分组成，分别为：执行者线程、任务实体以及线程池。接下来我们依次分析这些成员。

2.2.1、ForkJoinWorkerThread：任务的执行者

ForkJoinWorkerThread继承了Thread线程类，作为Thread的子类，但是却并没有对线程的调度、执行做改变，只是仅仅增加了一些额外功能。ForkJoinWorkerThread线程被创建出来后都交由ForkJoinPool线程池管理，并且设置为了守护线程，而ForkJoinWorkerThread线程创建出来之后都是被注册到FrokJoinPool线程池，由这些线程来执行用户提交的任务，所以ForkJoinWorkerThread也被称为任务的执行者。

ForkJoinPool线程池与之前的线程池有一点区别在于：之前的线程池中，总共只有一个任务队列，而ForkJoinPool中，每个ForkJoinWorkerThread线程在创建时，都会为它分配一个任务队列。同时为了实现工作窃取机制，该队列被设计为双向队列，线程执行自身队列中的任务时，采用LIFO的方式获取任务，当其他线程窃取任务时，采用FIFO的方式获取任务。ForkJoinWorkerThread线程的主要工作为执行自身队列中的任务，其次是窃取其他线程队列中的任务执行。源码如下：

public class ForkJoinWorkerThread extends Thread {
    final ForkJoinPool pool;    // 当前线程所属的线程池
    final ForkJoinPool.WorkQueue workQueue; // 当前线程的双向任务队列
    
    protected ForkJoinWorkerThread(ForkJoinPool pool) {
        // 调用Thread父类的构造函数创建线程实体对象
        // 在这里是先暂时使用aFJT作为线程名称，当外部传递线程名称时会替换
        super("aForkJoinWorkerThread");
        // 当前设置线程池
        this.pool = pool;
        // 向ForkJoinPool线程池中注册当前线程，为当前线程分配任务队列
        this.workQueue = pool.registerWorker(this);
    }
    
    // ForkJoinWorkerThread类 → run方法
    public void run() {
        // 如果队列中有任务
        if (workQueue.array == null) { 
            // 定义异常对象，方便后续记录异常
            Throwable exception = null;
            try {
                // 执行前置钩子函数（预留方法，内部未实现）
                onStart();
                // 执行工作队列中的任务
                pool.runWorker(workQueue);
            } catch (Throwable ex) {
                // 记录捕获的异常信息
                exception = ex;
            } finally {
                try {
                    // 对外写出捕获的异常信息
                    onTermination(exception);
                } catch (Throwable ex) {
                    if (exception == null)
                        exception = ex;
                } finally {
                    // 调用 deregisterWorker 方法进行清理
                    pool.deregisterWorker(this, exception);
                }
            }
        }
    }
    // 省略其他代码.....
}

很明显的可以看到，ForkJoinWorkerThread的构造函数中，在初始化时会将自身注册进线程池中，然后由线程池给每个线程对象分配一个队列。

2.2.2、ForkJoinTask：任务实体

ForkJoinTask与FutrueTask一样，是Futrue接口的子类，ForkJoinTask是一种可以将任务进行递归分解执行，从而提高执行并行度的任务类型，执行结束后也可以支持结果返回。但ForkJoinTask仅是一个抽象类，子类有三个：

• ①RecursiveAction：无返回值型ForkJoinTask任务
• ②RecursiveTask：有返回值型ForkJoinTask任务
• ③CountedCompleter：任务执行完成后可以触发钩子回调函数的任务

ForkJoinTask的作用就是根据任务的分解实现，将任务进行拆分，以及等待子任务的执行结果合并成父任务的结果。ForkJoinTask内部存在一个整数类型的成员status，该成员高16位记录任务的执行状态，如：如NORMAL、CANCELLED或EXCEPTIONAL，低16位预留用于记录用户自定义的任务标签。ForkJoinTask源码具体如下：

public abstract class ForkJoinTask implements Future, Serializable {
    // 表示任务的执行状态，总共有如下几种值
    volatile int status;
    // 获取任务状态的掩码，后续用于位计算，判断任务是否正常执行结束
    static final int DONE_MASK   = 0xf0000000;
    // 表示任务正常执行结束
    static final int NORMAL      = 0xf0000000; 
    // 表示任务被取消
    static final int CANCELLED   = 0xc0000000;
    // 表示任务出现异常结束
    static final int EXCEPTIONAL = 0x80000000;
    // 表示当前任务被别的任务依赖，在结束前会通知其他任务join结果
    static final int SIGNAL      = 0x00010000; 
    // 低16位掩码，预留占位(short mask)
    // setForkJoinTaskTag方法中应用了该成员，但这个方法没实现/应用
    static final int SMASK       = 0x0000ffff;

    // 异常哈希链表数组（异常哈希表，类似于hashmap1.8之前的实现）
    // 因为任务拆分之后会很多，异常信息要么都没有，要么都会出现
    // 所以不直接记录在ForkJoinTask对象中，而是采用哈希表结构存储弱引用类型的节点
    // 注意这些都是 static 类属性，所有的ForkJoinTask共用的
    private static final ExceptionNode[] exceptionTable;        
    private static final ReentrantLock exceptionTableLock;
    // 在ForkJoinTask的node被GC回收之后，相应的异常节点对象的引用队列
    private static final ReferenceQueue