在linux平台上使用socket时是否存在文件描述符泄漏？
如果我通过调用例如
Socket s = new Socket( ... );
s.setReuseAddress(true);
in = s.getInputStream();
...
in.close();
s.close();
Linux 来打开和关闭套接字，则该套接字仍处于打开状态，或者至少存在连接的文件描述符。 当通过 lsof 查询该进程的打开文件时，有一个已关闭连接的条目：
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
java 9268 user 5u sock 0,4 93417 can't identify protocol
该条目一直保留到程序关闭为止。 还有其他方法可以最终关闭套接字吗？ 我有点担心我的 java 应用程序可能会阻塞许多文件描述符。 这可能吗？ 或者即使设置了 ReuseAdress，java 也会保留这些套接字以重新使用它们吗？
If I open and close a socket by calling for instance
Socket s = new Socket( ... );
s.setReuseAddress(true);
in = s.getInputStream();
...
in.close();
s.close();
Linux states that this socket is still open or at least the file descriptor for the connection is presen. When querying the open files for this process by lsof, there is an entry for the closed connection:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
java 9268 user 5u sock 0,4 93417 can't identify protocol
This entry remains until the program is closed. Is there any other way to finally close the socket?
I'm a little worried that my java application may block to many file descriptors. Is this possible? Or does java keep these sockets to re-use them even is ReuseAdress is set?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果这些套接字都处于 TIME_WAIT 状态，这是正常的，至少在一段时间内是正常的。 用netstat检查一下； 套接字通常会挂起几分钟，以确保在将端口重新用于新套接字之前成功丢弃来自套接字的散乱数据。
If those sockets are all in the TIME_WAIT state, this is normal, at least for a little while. Check that with netstat; it is common for sockets to hang around for a few minutes to ensure that straggling data from the socket is successfully thrown away before reusing the port for a new socket.
您可能还想检查
/proc//fd ，该目录将包含所有当前打开的文件描述符。 如果文件在关闭套接字后消失，您将不会遇到任何问题（至少不会遇到文件描述符:)。You may also want to check
/proc/<pid>/fd, the directory will contain all of your currently opened file descriptors. If a file disappears after you closed the socket you will not run into any problems (at least not with your file descriptors :).我认为这不是你程序的问题。
在SUN_Java中，当加载socket相关的native lib时，会创建一个MAGIC_SOCK fd。
对 MAGIC_SOCK 进行写入将导致 Connect Rest 异常，对 MAGIC_SOCK 进行读取将导致 EOF。
magic_sock的peer已经完全关闭，而magic_sock本身是half_close，状态将保持“无法识别协议”。
I think it's not your program's problem.
In SUN_Java, when socket related native lib loaded, A MAGIC_SOCK fd will be created.
write on the MAGIC_SOCK will resulted a Connect Rest Exception, and read on the MAGIC_SOCK will resulted a EOF.
the magic_sock's peer has been fully closed, and the magic_sock itself is half_closed, and the state will remain "can't identify protocol".
也许它是某个其他协议的套接字（“无法识别协议”，是吗？），在实现中内部使用来执行某些操作，该套接字是在第一个套接字上创建的。
您是否尝试过重复创建套接字并关闭它们，以查看这些套接字是否真的持续存在？ 这似乎是一次性的。
Java 可能在内部使用套接字来完成很多事情 - 它们可能是 Unix、Netlink（在 Linux 下）或其他类型的套接字。
Maybe it's a socket of some other protocol ("Can't identify protocol" eh?) used internally in the implementation to do something, which gets created on the first socket.
Have you tried repeatedly creating sockets and closing them, to see if these sockets really persist? It seems likely that this is a one-off.
Java probably uses sockets internally for lots of things - they might be Unix, Netlink (under Linux) or some other type of socket.
创建一个小的 bash 脚本来监视某个应用程序或 pid 的打开套接字，并让它在测试您的 java 应用程序时运行。
无论如何，我怀疑这件事是否存在任何类型的泄漏，因为套接字在 linux/unix 世界中非常常用，而且这种问题很快就会出现
Create a small bash script to monitor opened sockets for a certain app or pid, and let it run while testing your java app.
I doubt anyway that there are any kind of leaks in this thing as sockets are very used in linux/unix world and this kind of problem would bubble up very quicky