Future 模式详解（并发使用）
?
??我觉得很多讲Future模式的文章并没有深刻理解Future模式，其实Future模式只是生产者-消费者模型的扩展。经典“生产者-消费者”模型中消息的生产者不关心消费者何时处理完该条消息，也不关心处理结果。Future模式则可以让消息的生产者等待直到消息处理结束，如果需要的话还可以取得处理结果
?
用过Java并发包的朋友或许对Future (interface)?已经比较熟悉了，其实Future?本身是一种被广泛运用的并发设计模式，可在很大程度上简化需要数据流同步的并发应用开发。在一些领域语言（如Alice ML?）中甚至直接于语法层面支持Future。
这里就以java.util.concurrent.Future?为例简单说一下Future的具体工作方式。Future对象本身可以看作是一个显式的引用，一个对异步处理结果的引用。由于其异步性质，在创建之初，它所引用的对象可能还并不可用（比如尚在运算中，网络传输中或等待中）。这时，得到Future的程序流程如果并不急于使用Future所引用的对象，那么它可以做其它任何想做的事儿，当流程进行到需要Future背后引用的对象时，可能有两种情况：
- 希望能看到这个对象可用，并完成一些相关的后续流程。如果实在不可用，也可以进入其它分支流程。
- “没有你我的人生就会失去意义，所以就算海枯石烂，我也要等到你。”（当然，如果实在没有毅力枯等下去，设一个超时也是可以理解的）
对于前一种情况，可以通过调用Future.isDone()判断引用的对象是否就绪，并采取不同的处理；而后一种情况则只需调用get()或
get(long timeout, TimeUnit unit)通过同步阻塞方式等待对象就绪。实际运行期是阻塞还是立即返回就取决于get()的调用时机和对象就绪的先后了。简单而言，Future模式可以在连续流程中满足数据驱动的并发需求，既获得了并发执行的性能提升，又不失连续流程的简洁优雅。
但是Futrue模式有个重大缺陷：当消费者工作得不够快的时候，它会阻塞住生产者线程，从而可能导致系统吞吐量的下降。所以不建议在高性能的服务端使用。
java.util.concurrent.Callable与java.util.concurrent.Future类可以协助您完成Future模式。Future模式在请求发生时，会先产生一个Future对象给发出请求的客户。它的作用类似于代理(Proxy)对象，而同时所代理的真正目标对象的生成是由一个新的线程持续进行。真正的目标对象生成之后，将之设置到Future之中，而当客户端真正需要目标对象时，目标对象也已经准备好，可以让客户提取使用
Callable是一个接口，与Runnable类似，包含一个必须实现的方法，可以启动为让另一个线程来执行。不过Callable工作完成后，可以传回结果对象。Callable接口的定义如下：
?
?java.util.concurrent.FutureTask是一个代理，真正执行找质数功能的是Callable对象。使用另一个线程启动FutureTask，之后就可以做其他的事了。等到某个时间点，用isDone()观察任务是否完成，如果完成了，就可以获得结果。一个执行结果如下，显示所有找到的质数：?
2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61?
??????????? 67 71 73 79 83 89 97 101 103 107 109 113 127 131?
??????????? 137 139 149 151 157 163 167 173 179 181 191 193?
??????????? 197 199 211 223 227 229 233 239 241 251 257 263?
??????????? 269 271 277 281 283 293 307 311 313 317 331 337?
??????????? 347 349 353 359 367 373 379 383 389 397 401 409?
??????????? 419 421 431 433 439 443 449 457 461 463 467 479?
??????????? 487 491 499 503 509 521 523 541 547 557 563 569?
??????????? 571 577 587 593 599 601 607 613 617 619 631 641?
??????????? 643 647 653 659 661 673 677 683 691 701 709 719?
??????????? 727 733 739 743 751 757 761 769 773 787 797 809?
??????????? 811 821 823 827 829 839 853 857 859 863 877 881?
??????????? 883 887 907 911 919 929 937 941 947 953 967 971?
??????????? 977 983 991 997?用户可能需要快速翻页浏览文件，但在浏览到有图片的页数时，由于图片文件很大，导致图片加载较慢，造成用户浏览文件时会有停顿的现象。因此希望在文件开启之后，仍有一个后台作业持续加载图片。这样，用户在快速浏览页面时，所造成的停顿可以获得改善，从而可以考虑使用这里所介绍的功能?
?