有关查找“打开的文件过多”原因的任何 Java 调试技巧,请参阅

发布于 2024-12-04 19:19:46 字数 315 浏览 0 评论 0原文

我正在Linux环境中进行开发,系统旨在长时间连续运行。经过一夜的测试后,我们看到 FileNotFoundException 并显示一条消息“打开的文件太多”。我们开始在系统中的不同时间记录 lsof 命令的输出,看看是否可以看到发生了什么。我们注意到许多未命名的管道打开了。所以我认为这是由于文件流没有关闭造成的。我在源代码中搜索了使用的任何 *Stream 对象,并确保它们都在 finally{} 块中关闭。是否有任何其他我可以搜索但可能不会关闭的 Java 对象类型会导致所有这些未命名管道被打开?

另外,我的 ulimit 是 1024,我还搜索了 *Writer 并确保它们也都关闭了。

I'm developing in a linux environment and the system is intended to run continuously over a long period of time. After an overnight test we see the FileNotFoundException with a message of "Too Many Files Open". We started logging the output of the lsof command at various times in the system to see if we can see what is happening. We noticed lots of unnamed pipes opened. So I figured these were due to File Streams not getting closed. I searched through the source for any *Stream objects used and made sure they were all getting closed in a finally{} block. Are there any other Java object types that I could search for that I might not be closing that would cause all these unnamed pipes to be opened?

Also, my ulimit is 1024 and I also searched for *Writer and made sure those were all closing too.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

梦里寻她 2024-12-11 19:19:46

YourKit 可能值得一看。它的探针旨在帮助解决此类问题,尽管我'我自己从未有机会尝试该功能。

YourKit might be worth a look. Its probes are meant to help with this type of problems, although I've never had the occasion to try that functionality myself.

梦一生花开无言 2024-12-11 19:19:46

我假设你的 ulimit 是 ulimit -n 的输出。 1024 是生产系统中允许的相当少量的文件描述符。对于调试步骤,与其随机运行 lsof 并尝试关联,为什么不捕获 FileNotFound 异常并运行 Runtime.exec("lsof") 并将输出打印到日志文件以获得准确的相当准确的视图问题发生时使用了哪些文件描述符。

I'm assuming your ulimit is the output of ulimit -n. 1024 is a fairly small number of file descriptors to allow for in a production system. For a debugging step, rather than running lsof at random times and trying to correlate, why not catch the FileNotFound exception and run a Runtime.exec("lsof") and print the output to a log file to get a fairly accurate view of exactly what file descriptors were used when the problem occurred.

天涯沦落人 2024-12-11 19:19:46

其他可能泄漏文件描述符的类是 FileChannel 和 RandomAccessFile - 后者甚至似乎没有终结器,因此它的泄漏可能是永久性的。

Other classes that might leak file descriptors are FileChannel and RandomAccessFile - the latter doesn't even seem to have a finalizer, so its leaks might be permanent.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文