彻底理解Java的Future模式

本文内容纲要：

先上一个场景：假如你突然想做饭，但是没有厨具，也没有食材。网上购买厨具比较方便，食材去超市买更放心。

实现分析：在快递员送厨具的期间，我们肯定不会闲着，可以去超市买食材。所以，在主线程里面另起一个子线程去网购厨具。

但是，子线程执行的结果是要返回厨具的，而run方法是没有返回值的。所以，这才是难点，需要好好考虑一下。

模拟代码1：

packagetest; publicclassCommonCook{ publicstaticvoidmain(String[]args)throwsInterruptedException{ longstartTime=System.currentTimeMillis(); //第一步网购厨具 OnlineShoppingthread=newOnlineShopping(); thread.start(); thread.join();//保证厨具送到 //第二步去超市购买食材 Thread.sleep(2000);//模拟购买食材时间 Shicaishicai=newShicai(); System.out.println("第二步：食材到位"); //第三步用厨具烹饪食材 System.out.println("第三步：开始展现厨艺"); cook(thread.chuju,shicai); System.out.println("总共用时"+(System.currentTimeMillis()-startTime)+"ms"); } //网购厨具线程 staticclassOnlineShoppingextendsThread{ privateChujuchuju; @Override publicvoidrun(){ System.out.println("第一步：下单"); System.out.println("第一步：等待送货"); try{ Thread.sleep(5000);//模拟送货时间 }catch(InterruptedExceptione){ e.printStackTrace(); } System.out.println("第一步：快递送到"); chuju=newChuju(); } } //用厨具烹饪食材 staticvoidcook(Chujuchuju,Shicaishicai){} //厨具类 staticclassChuju{} //食材类 staticclassShicai{} }

运行结果：

第一步：下单 第一步：等待送货 第一步：快递送到 第二步：食材到位 第三步：开始展现厨艺 总共用时7013ms

可以看到，多线程已经失去了意义。在厨具送到期间，我们不能干任何事。对应代码，就是调用join方法阻塞主线程。

有人问了，不阻塞主线程行不行？？？

不行！！！

从代码来看的话，run方法不执行完，属性chuju就没有被赋值，还是null。换句话说，没有厨具，怎么做饭。

Java现在的多线程机制，核心方法run是没有返回值的；如果要保存run方法里面的计算结果，必须等待run方法计算完，无论计算过程多么耗时。

面对这种尴尬的处境，程序员就会想：在子线程run方法计算的期间，能不能在主线程里面继续异步执行？？？

Wherethereisawill，thereisaway！！！

这种想法的核心就是Future模式，下面先应用一下Java自己实现的Future模式。

模拟代码2：

packagetest; importjava.util.concurrent.Callable; importjava.util.concurrent.ExecutionException; importjava.util.concurrent.FutureTask; publicclassFutureCook{ publicstaticvoidmain(String[]args)throwsInterruptedException,ExecutionException{ longstartTime=System.currentTimeMillis(); //第一步网购厨具 Callable<Chuju>onlineShopping=newCallable<Chuju>(){ @Override publicChujucall()throwsException{ System.out.println("第一步：下单"); System.out.println("第一步：等待送货"); Thread.sleep(5000);//模拟送货时间 System.out.println("第一步：快递送到"); returnnewChuju(); } }; FutureTask<Chuju>task=newFutureTask<Chuju>(onlineShopping); newThread(task).start(); //第二步去超市购买食材 Thread.sleep(2000);//模拟购买食材时间 Shicaishicai=newShicai(); System.out.println("第二步：食材到位"); //第三步用厨具烹饪食材 if(!task.isDone()){//联系快递员，询问是否到货 System.out.println("第三步：厨具还没到，心情好就等着（心情不好就调用cancel方法取消订单）"); } Chujuchuju=task.get(); System.out.println("第三步：厨具到位，开始展现厨艺"); cook(chuju,shicai); System.out.println("总共用时"+(System.currentTimeMillis()-startTime)+"ms"); } //用厨具烹饪食材 staticvoidcook(Chujuchuju,Shicaishicai){} //厨具类 staticclassChuju{} //食材类 staticclassShicai{} }

运行结果：

第一步：下单 第一步：等待送货 第二步：食材到位 第三步：厨具还没到，心情好就等着（心情不好就调用cancel方法取消订单） 第一步：快递送到 第三步：厨具到位，开始展现厨艺 总共用时5005ms

可以看见，在快递员送厨具的期间，我们没有闲着，可以去买食材；而且我们知道厨具到没到，甚至可以在厨具没到的时候，取消订单不要了。

好神奇，有没有。

下面具体分析一下第二段代码：

**1）**把耗时的网购厨具逻辑，封装到了一个Callable的call方法里面。

publicinterfaceCallable<V>{ /** *Computesaresult,orthrowsanexceptionifunabletodoso. * *@returncomputedresult *@throwsExceptionifunabletocomputearesult */ Vcall()throwsException; }

Callable接口可以看作是Runnable接口的补充，call方法带有返回值，并且可以抛出异常。

**2）**把Callable实例当作参数，生成一个FutureTask的对象，然后把这个对象当作一个Runnable，作为参数另起线程。

publicclassFutureTask<V>implementsRunnableFuture<V> publicinterfaceRunnableFuture<V>extendsRunnable,Future<V> publicinterfaceFuture<V>{ booleancancel(booleanmayInterruptIfRunning); booleanisCancelled(); booleanisDone(); Vget()throwsInterruptedException,ExecutionException; Vget(longtimeout,TimeUnitunit) throwsInterruptedException,ExecutionException,TimeoutException; }

这个继承体系中的核心接口是Future。Future的核心思想是：一个方法f，计算过程可能非常耗时，等待f返回，显然不明智。可以在调用f的时候，立马返回一个Future，可以通过Future这个数据结构去***控制***方法f的计算过程。

这里的***控制***包括：

get方法：获取计算结果（如果还没计算完，也是必须等待的）

cancel方法：还没计算完，可以取消计算过程

isDone方法：判断是否计算完

isCancelled方法：判断计算是否被取消

这些接口的设计很完美，FutureTask的实现注定不会简单，后面再说。

**3）**在第三步里面，调用了isDone方法查看状态，然后直接调用task.get方法获取厨具，不过这时还没送到，所以还是会等待3秒。对比第一段代码的执行结果，这里我们节省了2秒。这是因为在快递员送货期间，我们去超市购买食材，这两件事在同一时间段内异步执行。

通过以上3步，我们就完成了对Java原生Future模式最基本的应用。下面具体分析下FutureTask的实现，先看JDK8的，再比较一下JDK6的实现。

既然FutureTask也是一个Runnable，那就看看它的run方法

publicvoidrun(){ if(state!=NEW|| !UNSAFE.compareAndSwapObject(this,runnerOffset, null,Thread.currentThread())) return; try{ Callable<V>c=callable;//这里的callable是从构造方法里面传人的 if(c!=null&&state==NEW){ Vresult; booleanran; try{ result=c.call(); ran=true; }catch(Throwableex){ result=null; ran=false; setException(ex);//保存call方法抛出的异常 } if(ran) set(result);//保存call方法的执行结果 } }finally{ //runnermustbenon-nulluntilstateissettledto //preventconcurrentcallstorun() runner=null; //statemustbere-readafternullingrunnertoprevent //leakedinterrupts ints=state; if(s>=INTERRUPTING) handlePossibleCancellationInterrupt(s); } }

先看try语句块里面的逻辑，发现run方法的主要逻辑就是运行Callable的call方法，然后将保存结果或者异常（用的一个属性result）。这里比较难想到的是，将call方法抛出的异常也保存起来了。

这里表示状态的属性state是个什么鬼

*Possiblestatetransitions: *NEW->COMPLETING->NORMAL *NEW->COMPLETING->EXCEPTIONAL *NEW->CANCELLED *NEW->INTERRUPTING->INTERRUPTED */ privatevolatileintstate; privatestaticfinalintNEW=0; privatestaticfinalintCOMPLETING=1; privatestaticfinalintNORMAL=2; privatestaticfinalintEXCEPTIONAL=3; privatestaticfinalintCANCELLED=4; privatestaticfinalintINTERRUPTING=5; privatestaticfinalintINTERRUPTED=6;

把FutureTask看作一个Future，那么它的作用就是控制Callable的call方法的执行过程，在执行的过程中自然会有状态的转换：

1）一个FutureTask新建出来，state就是NEW状态；COMPETING和INTERRUPTING用的进行时，表示瞬时状态，存在时间极短(为什么要设立这种状态？？？不解)；NORMAL代表顺利完成；EXCEPTIONAL代表执行过程出现异常；CANCELED代表执行过程被取消；INTERRUPTED被中断

2）执行过程顺利完成：NEW->COMPLETING->NORMAL

3）执行过程出现异常：NEW->COMPLETING->EXCEPTIONAL

4）执行过程被取消：NEW->CANCELLED

5）执行过程中，线程中断：NEW->INTERRUPTING->INTERRUPTED

代码中状态判断、CAS操作等细节，请读者自己阅读。

再看看get方法的实现：

publicVget()throwsInterruptedException,ExecutionException{ ints=state; if(s<=COMPLETING) s=awaitDone(false,0L); returnreport(s); } privateintawaitDone(booleantimed,longnanos) throwsInterruptedException{ finallongdeadline=timed?System.nanoTime()+nanos:0L; WaitNodeq=null; booleanqueued=false; for(;;){ if(Thread.interrupted()){ removeWaiter(q); thrownewInterruptedException(); } ints=state; if(s>COMPLETING){ if(q!=null) q.thread=null; returns; } elseif(s==COMPLETING)//cannottimeoutyet Thread.yield(); elseif(q==null) q=newWaitNode(); elseif(!queued) queued=UNSAFE.compareAndSwapObject(this,waitersOffset, q.next=waiters,q); elseif(timed){ nanos=deadline-System.nanoTime(); if(nanos<=0L){ removeWaiter(q); returnstate; } LockSupport.parkNanos(this,nanos); } else LockSupport.park(this); } }

get方法的逻辑很简单，如果call方法的执行过程已完成，就把结果给出去；如果未完成，就将当前线程挂起等待。awaitDone方法里面死循环的逻辑，推演几遍就能弄懂；它里面挂起线程的主要创新是定义了WaitNode类，来将多个等待线程组织成队列，这是与JDK6的实现最大的不同。

挂起的线程何时被唤醒：

privatevoidfinishCompletion(){ //assertstate>COMPLETING; for(WaitNodeq;(q=waiters)!=null;){ if(UNSAFE.compareAndSwapObject(this,waitersOffset,q,null)){ for(;;){ Threadt=q.thread; if(t!=null){ q.thread=null; LockSupport.unpark(t);//唤醒线程 } WaitNodenext=q.next; if(next==null) break; q.next=null;//unlinktohelpgc q=next; } break; } } done(); callable=null;//toreducefootprint }

以上就是JDK8的大体实现逻辑，像cancel、set等方法，也请读者自己阅读。

再来看看JDK6的实现。

JDK6的FutureTask的基本操作都是通过自己的内部类Sync来实现的，而Sync继承自AbstractQueuedSynchronizer这个出镜率极高的并发工具类

/**Statevaluerepresentingthattaskisrunning*/ privatestaticfinalintRUNNING=1; /**Statevaluerepresentingthattaskran*/ privatestaticfinalintRAN=2; /**Statevaluerepresentingthattaskwascancelled*/ privatestaticfinalintCANCELLED=4; /**Theunderlyingcallable*/ privatefinalCallable<V>callable; /**Theresulttoreturnfromget()*/ privateVresult; /**Theexceptiontothrowfromget()*/ privateThrowableexception;

里面的状态只有基本的几个，而且计算结果和异常是分开保存的。

VinnerGet()throwsInterruptedException,ExecutionException{ acquireSharedInterruptibly(0); if(getState()==CANCELLED) thrownewCancellationException(); if(exception!=null) thrownewExecutionException(exception); returnresult; }

这个get方法里面处理等待线程队列的方式是调用了acquireSharedInterruptibly方法，看过我之前几篇博客文章的读者应该非常熟悉了。其中的等待线程队列、线程挂起和唤醒等逻辑，这里不再赘述，如果不明白，请出门左转。

最后来看看，Future模式衍生出来的更高级的应用。

再上一个场景：我们自己写一个简单的数据库连接池，能够复用数据库连接，并且能在高并发情况下正常工作。

实现代码1：

packagetest; importjava.util.concurrent.ConcurrentHashMap; publicclassConnectionPool{ privateConcurrentHashMap<String,Connection>pool=newConcurrentHashMap<String,Connection>(); publicConnectiongetConnection(Stringkey){ Connectionconn=null; if(pool.containsKey(key)){ conn=pool.get(key); }else{ conn=createConnection(); pool.putIfAbsent(key,conn); } returnconn; } publicConnectioncreateConnection(){ returnnewConnection(); } classConnection{} }

我们用了ConcurrentHashMap，这样就不必把getConnection方法置为synchronized(当然也可以用Lock)，当多个线程同时调用getConnection方法时，性能大幅提升。

貌似很完美了，但是有可能导致多余连接的创建，推演一遍：

某一时刻，同时有3个线程进入getConnection方法，调用pool.containsKey(key)都返回false，然后3个线程各自都创建了连接。虽然ConcurrentHashMap的put方法只会加入其中一个，但还是生成了2个多余的连接。如果是真正的数据库连接，那会造成极大的资源浪费。

所以，我们现在的难点是：如何在多线程访问getConnection方法时，只执行一次createConnection。

结合之前Future模式的实现分析：当3个线程都要创建连接的时候，如果只有一个线程执行createConnection方法创建一个连接，其它2个线程只需要用这个连接就行了。再延伸，把createConnection方法放到一个Callable的call方法里面，然后生成FutureTask。我们只需要让一个线程执行FutureTask的run方法，其它的线程只执行get方法就好了。

上代码：

packagetest; importjava.util.concurrent.Callable; importjava.util.concurrent.ConcurrentHashMap; importjava.util.concurrent.ExecutionException; importjava.util.concurrent.FutureTask; publicclassConnectionPool{ privateConcurrentHashMap<String,FutureTask<Connection>>pool=newConcurrentHashMap<String,FutureTask<Connection>>(); publicConnectiongetConnection(Stringkey)throwsInterruptedException,ExecutionException{ FutureTask<Connection>connectionTask=pool.get(key); if(connectionTask!=null){ returnconnectionTask.get(); }else{ Callable<Connection>callable=newCallable<Connection>(){ @Override publicConnectioncall()throwsException{ returncreateConnection(); } }; FutureTask<Connection>newTask=newFutureTask<Connection>(callable); connectionTask=pool.putIfAbsent(key,newTask); if(connectionTask==null){ connectionTask=newTask; connectionTask.run(); } returnconnectionTask.get(); } } publicConnectioncreateConnection(){ returnnewConnection(); } classConnection{ } }

推演一遍：当3个线程同时进入else语句块时，各自都创建了一个FutureTask，但是ConcurrentHashMap只会加入其中一个。第一个线程执行pool.putIfAbsent方法后返回null，然后connectionTask被赋值，接着就执行run方法去创建连接，最后get。后面的线程执行pool.putIfAbsent方法不会返回null，就只会执行get方法。

在并发的环境下，通过FutureTask作为中间转换，成功实现了让某个方法只被一个线程执行。

就这么多吧，真是呕心沥血啊！！！哈哈

-------------------------------------------------------------------------------------------------------------

最后这个场景有问题，具体请看下篇文章！！！

本文内容总结：

原文链接：https://www.cnblogs.com/cz123/p/7693064.html