编程语言
首页 > 编程语言> > Future源码一观-JUC系列

Future源码一观-JUC系列

作者:互联网

背景介绍

在程序中,主线程启动一个子线程进行异步计算,主线程是不阻塞继续执行的,这点看起来是非常自然的,都已经选择启动子线程去异步执行了,主线程如果是阻塞的话,那还不如主线程自己去执行不就好了。那会不会有一种场景,异步线程执行的结果主线程是需要使用的,或者说主线程先做一些工作,然后需要确认子线程执行情况来进行后续的操作。那么这里就需要子线程异步执行完任务能把结果告诉主线程,并且主线程还能访问到子线程执行任务的状态,比如是否执行完成或正在执行中。

Future就是上面概念的抽象,按照源码中的注释,它代表着一个异步计算的结果,提供的方法中可以通过get方法获取异步线程计算的结果,如果计算还没结束,就会阻塞等待返回成功;也可以通过cancel方法取消异步计算任务;还可以通过isCancelledisDone获得异步执行的状态;如果一个异步执行的内容并没有返回值,但是希望可以使用Future来获得取消异步计算任务的能力,可以返回null。

FutureTask

FutureTask提供了对Future的基础实现,在进入FutureTask源码之前,我们先考虑下如果要实现Future的功能可以怎么设计呢?

1,异步线程进入执行任务的时候,主线程先阻塞住,等到一步线程任务完成有返回结果了,唤醒主线程,把返回结果给它。

2,需要有个标记,记录异步线程有没有执行结束,异步线程任务执行一结束,这个标记就要变更,通过这个标记就可以知道执行状态。

3,能获取异步线程,在执行还没完成先,对异步线程可以中断,这样就可以取消异步线程执行的任务了。

4,异步线程执行和取消操作是有并发竞争的,所以应该对标记的更新做锁保护处理。

对照Future的API,大致能想到这些,实际还有大量关键细节组合才能实现。可以带这个实现思路进入源码的学习。

Task

FutureTask本身就是继承Runnable,Runnable的run方法是没有返回参数的。那么既然FutureTask需要把异步线程执行结果返回,就意味着需要把结果拿到记录。

构造函数
public FutureTask(Callable<V> callable) {
    if (callable == null)
        throw new NullPointerException();
    this.callable = callable;
    this.state = NEW;       // ensure visibility of callable
}
public FutureTask(Runnable runnable, V result) {
    this.callable = Executors.callable(runnable, result);
    this.state = NEW;       // ensure visibility of callable
}

当构造函数传的是Runnable的时候,会适配成Callable,所以对于自己的run方法需要返回结果的事那么就好办了,就是调用callable的run方法就行。我们再衍生开去看下Executors.callable(runnable, result);的实现。

public static <T> Callable<T> callable(Runnable task, T result) {
    if (task == null)
        throw new NullPointerException();
    return new RunnableAdapter<T>(task, result);
}	
static final class RunnableAdapter<T> implements Callable<T> {
    final Runnable task;
    final T result;
    RunnableAdapter(Runnable task, T result) {
        this.task = task;
        this.result = result;
    }
    public T call() {
        task.run();
        return result;
    }
}

这个适配没什么特殊,把一个result引用作为参数传入,然后作为结果返回。所以其实很少用这种方式来获取result,更多的是传一个null进来,因为更多的时候是想知道异步线程是否执行结束了,而不是要结果。

run方法

FutureTask既然本身就是Runnable,把它作为task提交给线程池执行,就是调用它的run方法。根据前面的分析,这个run方法需要调用内部属性callable的run获得result,然后保存result,以备get方法来获取的时候能直接返回,另外肯定也是要处理异常的场景。

以下是run方法的源码,再加上仔细关注一下状态的流转,就可以比较好的理解这个核心代码了。

public void run() {
  	// 【1】
    if (state != NEW ||
        !UNSAFE.compareAndSwapObject(this, runnerOffset,
                                     null, Thread.currentThread()))
        return;
    try {
        Callable<V> c = callable;
        if (c != null && state == NEW) {
            V result;
            boolean ran;
            try {
                result = c.call();
                ran = true;
            } catch (Throwable ex) {
                result = null;
                ran = false;
              	// 【2】
                setException(ex);
            }
            if (ran)
              	// 【3】
                set(result);
        }
    } finally {
      	//【4】
        // runner must be non-null until state is settled to
        // prevent concurrent calls to run()
        runner = null;
        // state must be re-read after nulling runner to prevent
        // leaked interrupts
        int s = state;
        if (s >= INTERRUPTING)
          	//【5】
            handlePossibleCancellationInterrupt(s);
    }
}

protected void set(V v) {
  if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
    outcome = v;
    UNSAFE.putOrderedInt(this, stateOffset, NORMAL); // final state
    finishCompletion();
  }
}
protected void setException(Throwable t) {
  if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {
    outcome = t;
    UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state
    finishCompletion();
  }
}
private void handlePossibleCancellationInterrupt(int s) {
  if (s == INTERRUPTING)
    while (state == INTERRUPTING)
      Thread.yield(); // wait out pending interrupt
}

直到网上找到了这篇文章why outcome object in FutureTask is non-volatile?

这里有个很巧妙的设计,就是利用java的happends before中的传递原则,使得在不使用锁的情况下,保证其他线程读到state=NORMAL时,该线程一定能读到outcome的最新值

Task State

前面提到需要一个标记来记录任务的执行状态,源码实现中有一个volatile修饰的int类型state字段(和AQS一样的配方的感觉来了)。

    /**
     * NEW -> COMPLETING -> NORMAL
     * NEW -> COMPLETING -> EXCEPTIONAL
     * NEW -> CANCELLED
     * NEW -> INTERRUPTING -> INTERRUPTED
    **/
		private volatile int state;
    private static final int NEW          = 0;
    private static final int COMPLETING   = 1;
    private static final int NORMAL       = 2;
    private static final int EXCEPTIONAL  = 3;
    private static final int CANCELLED    = 4;
    private static final int INTERRUPTING = 5;
    private static final int INTERRUPTED  = 6;

注释提供了全部状态流转路径,核心逻辑就是一步步变更状态来进行的。

Treiber Stack

我们需要了解清楚这个Treiber Stack的概念,因为这在JUC源码很多地方有使用,有助于我们理解JUC其他组件代码的实现。

对于一个栈,我们并发往栈里放节点的时候如何处理竞争呢?比较简单的方式就是使用锁,放的时候锁,取的时候锁。

有个大佬他不想用锁,而是利用CAS并发原语设计了一个无锁堆栈,并发表了论文,他名字就叫Treiber,这个就是Treiber Stack的由来。在FutureTask的源码注释中专门提到,很多JDK源码中都用到了类似这种引用,表达这个实现是有坚实理论依据的,有一种做学术的专业氛围。

直接看《Java Concurrency in Practice》中提供的实现代码:

public class TreiberStack <E> {
    AtomicReference<Node<E>> top = new AtomicReference<Node<E>>();

    public void push(E item) {
        Node<E> newHead = new Node<E>(item);
        Node<E> oldHead;
        do {
            oldHead = top.get();
            newHead.next = oldHead;
        } while (!top.compareAndSet(oldHead, newHead));
    }

    public E pop() {
        Node<E> oldHead;
        Node<E> newHead;
        do {
            oldHead = top.get();
            if (oldHead == null)
                return null;
            newHead = oldHead.next;
        } while (!top.compareAndSet(oldHead, newHead));
        return oldHead.item;
    }

    private static class Node <E> {
        public final E item;
        public Node<E> next;

        public Node(E item) {
            this.item = item;
        }
    }
}

这个队列在入队和出队的时候都没有进行锁操作,而是CAS设置头节点是否成功,如果设置成功表示头节点没有被修改过,就没有竞争发生,直接设置头节点,如果CAS设置失败表示有竞争发生,则字段继续,知道设置头节点成功。

其实只要记住一点,操作这个数据结构的入口集中在头节点上,原子操作头节点保证不会发生并发引起的读写数据异常的问题。

下面看一下FutureTask是如何定义这个链表节点的:

WaitNode

使用WaitNode来表示链表节点,内部有记录阻塞等待的线程和下一个节点的引用。

static final class WaitNode {
    volatile Thread thread;
    volatile WaitNode next;
    WaitNode() { thread = Thread.currentThread(); }
}

以下是FutureTask中实现的Treiber Stack结构图:
image

get方法

前面已经提过,get方法是阻塞线程等待的,怎么阻塞的?多个线程都调用get方法阻塞的时候如何维护这些线程?带着这两问题继续阅读源码。

public V get() throws InterruptedException, ExecutionException {
    int s = state;
    if (s <= COMPLETING)
        s = awaitDone(false, 0L);
    return report(s);
}

public V get(long timeout, TimeUnit unit)
    throws InterruptedException, ExecutionException, TimeoutException {
    if (unit == null)
        throw new NullPointerException();
    int s = state;
    if (s <= COMPLETING &&
        (s = awaitDone(true, unit.toNanos(timeout))) <= COMPLETING)
        throw new TimeoutException();
    return report(s);
}
awaitDone

这个方法里实现了如果异步线程还未执行结束的时候,来调用get方法阻塞等待的能力。

private int awaitDone(boolean timed, long nanos)
    throws InterruptedException {
    final long deadline = timed ? System.nanoTime() + nanos : 0L;
    WaitNode q = null;
    boolean queued = false;
    for (;;) {
        if (Thread.interrupted()) {
            removeWaiter(q);
            throw new InterruptedException();
        }

        int s = state;
      	// 【1】
        if (s > COMPLETING) {
            if (q != null)
                q.thread = null;
            return s;
        }
        else if (s == COMPLETING) // cannot time out yet
            Thread.yield();
      	// 【2】
        else if (q == null)
            q = new WaitNode();
        else if (!queued)
            queued = UNSAFE.compareAndSwapObject(this, waitersOffset,
                                                 q.next = waiters, q);
      	// 【3】
        else if (timed) {
            nanos = deadline - System.nanoTime();
            if (nanos <= 0L) {
                removeWaiter(q);
                return state;
            }
            LockSupport.parkNanos(this, nanos);
        }
        else
            LockSupport.park(this);
    }
}

finishCompletion

这个方法在任务执行结束或取消的时候执行,前面提到过的其中执行结束的两种情况是正常执行结束和异常结束。它需要把等待的节点中的线程全部唤醒,在了解了链表结构后,我们看一下这个唤醒操作的代码:

private void finishCompletion() {
    // assert state > COMPLETING;
    for (WaitNode q; (q = waiters) != null;) {
        if (UNSAFE.compareAndSwapObject(this, waitersOffset, q, null)) {
            for (;;) {
                Thread t = q.thread;
                if (t != null) {
                    q.thread = null;
                    LockSupport.unpark(t);
                }
                WaitNode next = q.next;
                if (next == null)
                    break;
                q.next = null; // unlink to help gc
                q = next;
            }
            break;
        }
    }

    done();

    callable = null;        // to reduce footprint
}

遍历节点前会先用CAS的方式将头设置成null,成功设置才能继续,所以这里有两个for循环,第二个for循环是遍历链表,找出Thread不为空的节点,用LockSupport.unpark唤醒,被唤醒的线程会从awaitDonepark处醒来继续执行。

其中留了一个done()方法提供给子类扩展,很多字类实现了这个扩展,比如说guava的ListenableFutureTask

removeWaiter

awaitDone方法中的循环中,判断出线程有中断标记的时候会执行removeWaiter,还有就是get超时也会触发。

private void removeWaiter(WaitNode node) {
    if (node != null) {
        node.thread = null;
        retry:
        for (;;) {          // restart on removeWaiter race
            for (WaitNode pred = null, q = waiters, s; q != null; q = s) {
                s = q.next;
                if (q.thread != null)
                    pred = q;
                else if (pred != null) {
                    pred.next = s;
                    if (pred.thread == null) // check for race
                        continue retry;
                }
                else if (!UNSAFE.compareAndSwapObject(this, waitersOffset,
                                                      q, s))
                    continue retry;
            }
            break;
        }
    }
}

一个链表中并发删除随机节点自然会有冲突问题,比如同时删除的节点为相邻节点,前面的节点的next可能只想null导致链表断裂。那么这里是如何避免这种问题的呢?

首先,这个方法进入的时候第一步就会把节点的thread设置为null,实际这个操作是可以作为当前线程正在删除这个节点的标记,其他线程只要判断节点是否为null就可以推算出可能有线程正在删除这个节点。

其次,每个节点都会先判断thread是否为空,不为空则会设置给pred,也就是说pred只要有节点这个节点在从节点移除前thread都是不为空的,如果判断出节点的thread为空,那么就跳过判断进入下一个节点的判断,那么这个节点就自然链表中移除了,因为上一个节点的next会指向到thread不为空的下一个节点(pred.next = s)。当next指向后,会再判断pred的thread是否为空,如果是为空就表示可能有线程并发操作,这里就直接从头循环链表。

最后,前两个判断都不成立的情况只有一种那就是头节点的thread为空的情况,此时就要用cas的方式来处理如果设置失败,和前面操作链表一样自旋即可。

cancel

public boolean cancel(boolean mayInterruptIfRunning) {
  	// 【1】
    if (!(state == NEW &&
          UNSAFE.compareAndSwapInt(this, stateOffset, NEW,
              mayInterruptIfRunning ? INTERRUPTING : CANCELLED)))
        return false;
  	// 【2】
    try {    // in case call to interrupt throws exception
        if (mayInterruptIfRunning) {
            try {
                Thread t = runner;
                if (t != null)
                    t.interrupt();
            } finally { // final state
                UNSAFE.putOrderedInt(this, stateOffset, INTERRUPTED);
            }
        }
    } finally {
      	//【3】
        finishCompletion();
    }
    return true;
}

后记

《Netty实战》中有写到JDK中Future所提供的实现只允许手动检查对应的操作是否完成,或者一直阻塞知道它完成。这是非常烦琐的,所以Netty提供了自己的实现,所以下一站,ChannelFuture。

参考

https://yangsanity.me/2021/07/27/FutureTask/

https://en.wikipedia.org/wiki/Treiber_stack

https://www.cnblogs.com/iwehdio/p/14285282.html

标签:一观,JUC,执行,state,源码,线程,NEW,null,节点
来源: https://www.cnblogs.com/killbug/p/16441226.html