当前位置: 首页 > 知识库问答 >
问题:

Netty是否违反了Future.cancel(...)方法?

姜增
2023-03-14

根据方法<code>java.util.concurrent的约定。未来#取消:

此方法返回后,对 isDone 的后续调用将始终返回 true。

Netty的Future接口扩展了它:

public interface Future<V> extends java.util.concurrent.Future<V>

所以Netty应该遵守合同。但事实上Netty没有。您可以运行以下示例代码:

import io.netty.util.concurrent.GlobalEventExecutor;
import io.netty.util.concurrent.Promise;

public class DefaultPromiseIsDoneTest {

    private final Promise<?> defaultPromise = GlobalEventExecutor.INSTANCE.newPromise();

    public static void main(String args[]) {
        DefaultPromiseIsDoneTest main = new DefaultPromiseIsDoneTest();
        main.isDoneTest();
    }

    private void isDoneTest() {
        defaultPromise.setUncancellable();
        defaultPromise.cancel(false);
        boolean isDone = defaultPromise.isDone();
        System.out.println(isDone);
    }
}

控制台应打印:

但实际上它打印:

以下方法也违反了合同:

io.netty.channel.group.VoidChannelGroupFuture#isDone
io.netty.channel.VoidChannelPromise#isDone

我已经在github上创建了一个问题:问题

但是我仍然想在stackoverflow中讨论这个问题,因为我认为这是< code>cancel的一个非常基本的设计决策

还有一些相关主题:

未来取消方法文档

java.util.concurrent.Future中的cancel()方法是否应该被阻塞?

顺便说一下,我是Netty的粉丝:)

共有1个答案

程俊誉
2023-03-14

Netty确认了这个问题,请参考问题。

我认为这个契约很可能在其他Java异步框架中被错误地实现。因为当我们第一次读到它时,它确实是一个违反直觉的合同。

 类似资料:
  • 问题内容: Liskov替换原理是SOLID的原理之一。我已经读过几次这个原理,并试图理解它。 这就是我的所作所为, 此原则与类层次结构之间的强行为契约有关。子类型应该能够被超类型替换而不会违反合同。 我也读过其他文章,对这个问题我有些失落。难道方法不违反LSP? 上面链接的文章摘录: 换句话说,当通过对象的基类接口使用对象时,用户仅知道基类的前提条件和后置条件。因此, 派生对象不能期望此类用户遵

  • 来自Liskov替代原理-www.blackwasp。co.uk 不符合LSP的一个常见指示是当客户端类检查其依赖项的类型时。这可以通过读取人为描述其类型的对象的属性或通过使用反射来获得类型。通常,根据依赖项的类型,将使用开关语句执行不同的操作。这种额外的复杂性也违反了打开/关闭原则(OCP),因为随着更多子类的引入,客户端类需要修改。 以下技术(使用反射)是否会导致违反LSP? 依赖注入 注:我

  • 我正在阅读为什么Java中的数组协方差不好(为什么数组是协方差的,而泛型是不变的?)。如果是的子类型,则是的子类型。这是一个问题,因为这样的事情是可以做的: 这与“正确”实现的泛型不同。不是的子类型 我试图理解为什么它是坏的本质,并且刚刚读了关于LSP的文章。它有没有违反LSP?似乎没有明显的违规行为。

  • 考虑以下程序: (编译器资源管理器) GCC和Clang的各种版本都可以接受它,但MSVC不能接受它,因为MSVC编译失败,出现错误消息 第一条错误消息向我暗示了ODR违规--但如果这个程序是格式不良的NDR,我需要帮助理解为什么会这样。我已经检查了标准草案中的temp.over.link,但我不相信我对它的解释是正确的。根据我的理解,程序是可以的,因为这些函数模板有不同的签名。 在不太可能的情况

  • 有人能告诉我下面的例子是否违反了LSP吗? 我有一个例子: 和子类: 和主类: 在此示例中,子类添加名为 的新属性,并通过对其自己的属性 进行附加检查来覆盖方法。 在main方法中,我创建了2个对象。第一个是类型的对象,第二个是类型的对象。 当验证人员时,因为所有前提条件都是正确的,所以它是正确的,但是对于员工,它将抛出< code > IllegalArgumentException ,因为它与

  • 我有以下代码: 所以我们知道