java - Nettys FileDescriptor 在 OS X 上的使用情况如何

Question

在 PLC4X 项目中，我们使用 Netty 作为客户端连接到充当服务器的 PLC。有时，由于用户错误或 PLC 错误，连接不被接受而是被拒绝。如果我们多次重试尽快建立连接，我们会遇到错误消息 Too many open files .
我尝试清理代码中的所有内容，因此我假设没有可能泄漏的文件描述符:

try {
  final NioEventLoopGroup workerGroup = new NioEventLoopGroup();

  Bootstrap bootstrap = new Bootstrap();
  bootstrap.group(workerGroup);
  bootstrap.channel(NioSocketChannel.class);
  bootstrap.option(ChannelOption.SO_KEEPALIVE, true);
  bootstrap.option(ChannelOption.TCP_NODELAY, true);
  // TODO we should use an explicit (configurable?) timeout here
  // bootstrap.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 1000);
  bootstrap.handler(channelHandler);
  // Start the client.
  final ChannelFuture f = bootstrap.connect(address, port);
  f.addListener(new GenericFutureListener<Future<? super Void>>() {
      @Override public void operationComplete(Future<? super Void> future) throws Exception {
          if (!future.isSuccess()) {
              logger.info("Unable to connect, shutting down worker thread.");
              workerGroup.shutdownGracefully();
          }
      }
  });
  // Wait for sync
  f.sync();
  f.awaitUninterruptibly(); // jf: unsure if we need that
  // Wait till the session is finished initializing.
  return f.channel();
} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
  throw new PlcConnectionException("Error creating channel.", e);
} catch (Exception e) {
  throw new PlcConnectionException("Error creating channel.", e);
}

根据我的理解，监听器应该始终关闭组并释放所有使用的描述符。
但实际上，当在 macOS Catalina 上运行它时，我看到大约 1% 的失败不是由于“拒绝”而是由于“打开的文件太多”。
这是一个 ulimit事情，因为 Netty(在 macOS 上)只需要一些 fd 才能使用？还是我漏了什么东西？

谢谢澄清!

Answer 1

我找到了解决方案，有点像我自己。
原始实现中有 2 个问题(甚至可能是 3 个)，它们与 Mac OS X 没有真正的关系:

connect 和 addListener 应该链接起来

workerGroup.shutdownGracefully()在另一个线程中触发，因此主(被调用)线程已经完成

没有等到 workerGroup 真正完成。

这一起可能导致看起来的情况，新组的产生速度比旧组的关闭速度快。
因此，我将实现更改为

try {
    final NioEventLoopGroup workerGroup = new NioEventLoopGroup();

    Bootstrap bootstrap = new Bootstrap();
    bootstrap.group(workerGroup);
    bootstrap.channel(NioSocketChannel.class);
    bootstrap.option(ChannelOption.SO_KEEPALIVE, true);
    bootstrap.option(ChannelOption.TCP_NODELAY, true);
    // TODO we should use an explicit (configurable?) timeout here
    // bootstrap.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 1000);
    bootstrap.handler(channelHandler);
    // Start the client.
    logger.trace("Starting connection attempt on tcp layer to {}:{}", address.getHostAddress(), port);
    final ChannelFuture f = bootstrap.connect(address, port);
    // Wait for sync
    try {
        f.sync();
    } catch (Exception e) {
        // Shutdown worker group here and wait for it
        logger.info("Unable to connect, shutting down worker thread.");
        workerGroup.shutdownGracefully().awaitUninterruptibly();
        logger.debug("Worker Group is shutdown successfully.");
        throw new PlcConnectionException("Unable to Connect on TCP Layer to " + address.getHostAddress() + ":" + port, e);
    }
    // Wait till the session is finished initializing.
    return f.channel();
}
catch (Exception e) {
    throw new PlcConnectionException("Error creating channel.", e);
}

它解决了上述问题。因此，只有在正确清理后调用才会结束。

我的测试现在显示了恒定数量的打开文件描述符。