我有一个自定义类 MyFutureTask extends FutureTask ，我在该类的 done() 方法上执行了一些代码。
我使用 ExecutorService，将其称为 submit(new MyFutureTask()) 。
现在，我可以保留对调用提交后返回的 Future 的引用，但是当我调用 cancel 时，isCancelled() 方法永远不会返回 true 。
我是否应该忽略返回的 Future 对象，而使用 MyFutureTask 并对其调用 cancel(true) ？
那么 Future 对象有什么用呢？
编辑：Java中的Future和FutureTask有什么区别？ 从这个帖子中我明白了其中的区别。
除了默认的取消行为之外，我还想尝试停止正在进行的网络调用，所以我猜我将使用 FutureTask 的路线是正确的。有人可以证实吗？
I have a custom class MyFutureTask extends FutureTask<Void> upon which I do some code on the done() method.
I use an ExecutorService which I call submit(new MyFutureTask()) into it.
Now I can keep a reference to the Future<?> that gets returned after you call submit, but when I call cancel to that the isCancelled() method never returns true.
Should I ignore the Future<?> object that gets returned and instead work with MyFutureTask and call cancel(true) on that instead?
What is the use of the Future<?> object then?
edit: What's the difference between Future and FutureTask in Java? from this thread I understand the difference.
Besides the default cancel behavior I also want to attempt to stop a network call in progress so I guess the route I am going to use FutureTask is correct. Someone can confirm?
发布评论
评论（2）
不要使用
Executor.submit，而是使用Executor.execute，因为您已经拥有一个 Future。当您调用提交时，您只是不必要地将您的 FutureTask 包装在另一个 FutureTask 中。Don't use
Executor.submit, instead useExecutor.executesince you already have a Future. When you call submit, you are just needlessly wrapping your FutureTask in another FutureTask.您也无法“停止”网络旅行。您必须等到它返回或超时。你所做的就是调用Future.cancel(true)，然后当你的网络旅行返回时查看Future是否已被取消Future.isCancelled()。那么你就可以停止做你未来正在做的事情。无论出于何种目的，这与取消网络旅行的效果相同。对于最终用户（即客户端代码或调用者），它将以相同的方式显示。您可能注意到的唯一副作用是，如果只有一个线程执行任务，在这种情况下，等待网络行程的线程必须先返回，然后才能开始执行下一个任务。如果这是使用线程池的问题。
顺便说一句，如果您使用 NIO 或其某些库，您可以立即停止等待结果，但这需要更多的编码工作。
Also you can't "stop" a network trip. You have to wait until it returns or times out. What you do is call Future.cancel(true), then when your network trip returns look and see if the future has been canceled Future.isCancelled(). THen you can just stop doing what you were doing in the Future. For all intents and purposes it's the same effect as if you could cancel a network trip. To the end user (ie the client code or caller) it will appear the same way. The only side effect you might notice is if you have only a single thread executing tasks in which case the thread waiting on the network trip has to return before it will pick up the next task. If that's a problem using a pool of threads.
As an aside if you used NIO or some library thereof you could stop waiting on the result immediately, but that's a lot more work to code up.