Netty-calling channel.disconnect（）实际上关闭了通道

我使用的是Netty版本2.6.0.Final

如果我正确理解了Netty文档，在通道上调用disconnect（）应该允许我稍后调用connect（）再次连接。但是，当我调用disconnect（）时，SimpleChannelHandler子类的channelDisconnected（）和channelClosed（）都会被调用

我在调试模式下打开了它，事件的顺序基本上是：

我在我的频道上调用disconnect（）

调用Channels.disconnect（）：

public static ChannelFuture disconnect(Channel channel) {
  ChannelFuture future = future(channel);
  channel.getPipeline().sendDownstream(new DownstreamChannelStateEvent(
        channel, future, ChannelState.CONNECTED, null));
  return future;
}

最终，将调用NioSocketPipelineSink.eventsink（），相关部分为：

    case CONNECTED:
        if (value != null) {
            connect(channel, future, (SocketAddress) value);
        } else {
            channel.worker.close(channel, future);
        }
        break;

因此，由于值为null且状态为CONNECTED，因此通道将关闭（尽管根据CONNECTED with null应指示断开连接的请求，而不一定是关闭）

那么我是不是遗漏了什么？如果断开连接（）只会导致通道关闭，那么它有什么意义呢

---

这不是一个大问题，因为如果我需要，我可以为我的情况创建一个新的通道，但从最初的检查来看，这似乎是一个棘手的错误，除非我只是误解了这是如何工作的，或者我在做一些愚蠢的事。

Netty的一个意图是提供一个统一的通道抽象，它或多或少地与无论底层实现是OIO、NIO还是AIO，面向连接的套接字（TCP）和无连接的套接字（UDP）都是一样的。由于存在很多差异，所以对于特定实现的某些部分，统一接口看起来有点奇怪

断开TCP套接字的连接意味着将其关闭（至少从Java API的角度来看是这样），但断开UDP套接字并不意味着将其关闭，只是删除本地ip地址/端口和远程ip地址/端口之间的关联

因此，不，您并没有做任何愚蠢的事情，但我建议您在打开/关闭事件时采取行动，除非您确实需要在UDP套接字的生命周期中将其“连接”到不同的远程目标

---

编辑：在前面的段落中遗漏了一个重要的“否”。

Hmm，我想这是有意义的。我主要是想寻找一种方法，在断开网络TCP通道连接后，能够重用它们，而不必完全重新创建整个通道和管道（并更新引用它的对象），但这可能不足以成为一个问题。TCP连接几乎总是代表较高级别上的“紧密”连接；在大多数情况下，尝试重新使用较低级别的资源比在较高级别的连接结束时简单地丢弃它们要更费工作和更混乱。