JDK1.8修改了FutureTask的实现，JKD1.8不再依赖AQS来实现，而是通过一个volatile变量state以及CAS操作来实现。之前版本实现FutureTask源码详解(JDK1.7)
1- 继承结构
2- state字段
volatile修饰的state字段
3- 其他变量
runner和waiters为volatile类型
4- 构造器
5- CAS工具初始化
6- get()方法的等待队列
7- run()方法详解
run()方法一般被Executor调用
需要注意的是方法中的catch子句，如果caller线程调用cancel(true)方法来中断runner线程任务的执行，除非在Callable的call()方法实现上设计成响应线程中断，否则是不会中断callable.call()方法的执行的。
唤醒get()方法阻塞的线程
重点看一下handlePossibleCancellationInterrupt方法：这个方法是自旋等待state变为INTERRUPTED（对应cancel方法的结束），即等待中断的结束。
作者本来想在方法的尾部调用Thread.interrupted()方法来重置runner线程的中断状态的，但是考虑到程序员设计程序时可能使用中断作为task和caller之间的通信，如果贸然的清除中断标志，可能会给程序设计者带来不便，所以既然不能保证一定是cancel(true)导致的中断，那么就不清除了，最终将最后一行注释了。所以最终的结果还是让runner保持中断状态。（基于jdk1.8.0_65版本）
8- cancel方法详解
9- get方法详解
NEW 状态的 FutureTask 的 get 方法将会被阻塞，直到被唤醒从循环中返回。
10- 总结
- JDK的源码文档中作者添加了如下修改注释
讲解了自己在JDK1.8中重新FutureTask的意图是想避免在执行取消的循环中runner还一直保持中断状态，所以想在取消的循环中重置runner的中断状态，但是又考虑到如下事实：程序员设计程序时可能使用中断作为task和caller之间的通信。所以贸然的清除中断标志，可能会给程序设计者带来不便，所以既然不能保证一定是cancel(true)导致的中断，那么就不清除了，最终将最后一行注释了。所以最终的结果还是让runner保持中断状态。（基于jdk1.8.0_65版本）
- 当cancel(true)去以中断的方式中断任务的执行时，除非在Callable的call()方法实现上设计成响应线程中断，否则是不会中断callable.call()方法的执行的，虽然不会中断任务的执行，但是不会设置callable的运行结果，在get()方法返回时抛出CancellationException异常。
