操作系统：Ubuntu 14.04
JVM：1.8.0_181
Netty：4.1.8（目前不使用本机epoll实现..希望转向此实现）
我们仅设法找到了表现出该行为的几个节点，随后进行了监视以帮助进一步追踪它，观察到的行为是anon_inode和管道实例从约1.5k的正常水平增加约3k至数十万（一个实例为〜808k和〜1.6M） ..我们还没有得到堆转储，现在应该可以进行监视了。
在仅使用Netty作为客户端的服务中（以及在具有服务器的服务中看到它，但事实是它发生在客户端有助于缩小范围）
没有看到任何指示选择器重建的日志。
在所有可能的情况下，这都是我们的代码，但是如果您能指出我们为实现此目的而应该做的事情（通常，我们在这种状态下捕获服务器的次数为4或5次，并且还有更多报告）不胜感激。例如我看不到我们会创建许多客户端引导程序，通道管道等实例。通过这种设置，我们每天要在数千个节点上进行数十亿次呼叫，所以这是一种边缘情况。
作为调查的一部分，我们一直在进行一些分层（使我更想要原生epoll实现），并从Java实现中发现了这个“有趣”的调用序列
这是来自编写单行的基本客户端，它使用UDP编写示例度量标准行，然后关闭/关闭
sendto(22, "blah:-523410803|#blah:what,hey:ho\n", 34, 0, {sa_family=AF_INET6, sin6_port=htons(2003), inet_pton(AF_INET6, "::ffff:127.0.0.1", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
<... sendto resumed> ) = 34
epoll_wait(21, [{EPOLLIN, {u32=19, u64=19}}], 8192, 0) = 1
socketpair(AF_UNIX, SOCK_STREAM, 0, [23, 24]) = 0
close(24) = 0 # close one end of the pair just
created
dup2(23, 22) = 22 # WHY? .. currently 22 is being used to write output, this should result in 22 being closed and 22 then points to the same thing as 23
epoll_ctl(21, EPOLL_CTL_DEL, 22, 0x7f346cf1208c) = -1 ENOENT (No such file or directory) # lose interest in 22
close(22) # close 22 (which is actually 23)
虽然看起来结果是应该关闭所有东西，但额外的socketpair / close / dup2 / close是意外的，您是否在此处看到一个可能导致泄漏的孔？我知道您已经打开了许多JDK错误，因此希望它是其中一个：-）
我们还看到他们在一些地方不使用CLOEXEC，但这真的是一个问题吗？ （JVM是否曾经进行过fork / exec或docker exec / attach？）
谢谢！