java.util.concurrent.Future中的取消（）方法是否应该阻塞？
我正在努力实现未来
根据官方文件，我们可以推断：
>
文件说
此方法返回后，对isDone（）的后续调用将始终返回true。
但是
boolean isDone（）如果此任务完成，则返回true。
因此，如果我们在任务处理时运行取消（）并且无法取消，则此方法应该等到任务完成。这与1相矛盾。
cancel（）的返回值描述为
返回：如果无法取消任务（通常是因为任务已正常完成），则返回false；否则为true
因此，如果任务正在运行，并且可能会被取消，但此时不能取消，那么我们应该返回true（我们不能声明它不能被取消）或wait（但它与1相矛盾）。
但也有一个声明
如果此方法返回true，则对isCancelled（）的后续调用将始终返回true。
但是
boolean is取消（）如果此任务在正常完成之前被取消，则返回true。
当我们在任务运行时运行cancel（）时，这与3相矛盾，并且不能说任务是否可以取消（因为在这种情况下cancel（）应该返回true，而isCancelled（）应该返回false）。
看起来这个API很久以前就被删除了，这样的不一致不应该出现在文档中。但确实有。我是否理解错误？
共有2个答案
我将其理解为“isCancelled（）在cancel（）返回true后返回true”，我看不到任何不一致
我是否理解错误？
我想是的Future不是作业控制API；它是对可能尚未计算的值概念的抽象。通过取消未来，您只需放弃对该价值的兴趣；其余取决于实现细节。
因此，Future与最终产生其结果的计算没有强烈耦合。如果您调用取消并返回true，则您已将Future移动到其最终的、不可更改的状态：取消的Future的状态，它永远不会产生其值。底层计算任务可能会也可能不会持续不确定的时间；您无法通过Future的API对此进行控制。
-
问题内容： 使用原生（ES6）Promise。我应该以错误拒绝： 还是我应该拒绝一个字符串： 浏览器行为有什么区别？ 问题答案： 是的，绝对可以。字符串不是错误，通常当您遇到错误时，这意味着出了点问题，这意味着您将真正享受良好的堆栈跟踪。没有错误-没有堆栈跟踪。 就像try / catch一样，如果您添加到抛出拒绝中，则希望能够记录堆栈跟踪，而抛出字符串会为您带来麻烦。 我在移动设备上，因此答案很
-
我应该在中具体放入什么？ 我找不到这方面的指导。
-
在我的UI中，我尝试使用不同的按钮在应该显示的活动工作表之间切换。 显示正常。但是，我不知道该如何正确地将其辞退。用户可以将激活的工作表划走。它消失了。不过，不知道内存会不会腾出来呢？是否应该有额外的代码，以正确的方式消除这些活动的工作表？
-
也许这是一个容易被删除的问题，但以防万一。 我最近在我的服务上执行注释方法时，怀疑这些方法是否应该包含在服务的接口上。 但是，另一方面，我的服务上有一个公共方法，但它不包括在接口上，出于某种原因，这对我来说很难闻（也许这只是一种习惯）。 那么，怎么办呢？这方面有什么惯例吗？
-
我有多个线程使用ElasticSearchClient，如下所述 据我所知，Singleton类是线程安全的，但我不确定如果多个线程开始执行Singleton类的同一方法会发生什么。这有副作用吗？ 注意：我知道上面的singleton类不是反射和序列化安全的。
-
我有一个顶点，它有一个处理程序，可以在事件循环线程中调用Vertx的Web客户端。实际的底层API调用是同步的还是异步的？它会阻塞我的事件循环线程吗？假设我的API调用需要30秒才能返回。 我是否需要用Vertx.execute阻塞（p-