前言：此處描述的兩個問題是在一年前發現并修復的。 本文僅用作歷史證明，也是有關解決Java中文件描述符泄漏的初學者指南。

在Ultra ESB中，我們使用內存RAM磁盤文件緩存來進行快速且無垃圾的有效負載處理。 一段時間以前，我們在共享的SaaS AS2網關上遇到了一個問題，該緩存隨著時間的推移泄漏了文件描述符。 最終，在擊中系統ulimit時，導致too many open files錯誤too many open files 。

有彈性的城堡軍團：流支持的MIME部分中的剩余部分？

我們發現罪魁禍首是Bouncy Castle ，這是著名的安全服務提供商，自Ultra ESB Legacy時代起就一直是我們的摯愛。

通過一些簡單的工具，我們發現BC習慣了對MIME部分調用getContent()以確定它們的類型（例如， instanceof檢查）。 沒錯，這本身并不是犯罪。 但是我們的大多數MIME部分都是文件支持的 ，另一端帶有文件緩存文件-這意味著每個getContent()都會為該文件打開一個新流。 因此，現在有指向我們的文件緩存的雜散流（以及文件描述符）。

這些已經足夠了，我們將用盡分配給Ultra ESB（Java）進程的文件描述符配額。

讓他們變得懶惰！

我們不想弄亂BC代碼庫。 因此，我們找到了一個簡單的解決方案：使用“惰性”流創建所有文件支持的MIME部分。 我們（以前）同事Rajind寫了LazyFileInputStream -靈感LazyInputStream從jboss-vfs -打開只有當實際文件read嘗試。

BC很高興，文件緩存也很高興。 但是我們是最快樂的

Hibernate JPA：晚飯后清理，也就是關閉消耗的流

我們發現的另一個錯誤是某些數據庫操作留下了未關閉的文件句柄。 顯然，只有當我們將流支持的Blob饋送到Hibernate時，流才通常來自文件緩存項。

經過一番挖掘之后，我們提出了一個理論，即Hibernate不會關閉這些Blob條目的基礎流。 （這是有道理的，因為java.sql.Blob接口沒有公開Hibernate可以用來操作基礎數據源的任何方法。）但是，這是一個問題，因為丟棄的流（以及關聯的文件句柄）不會得到發布直到下一個GC。

對于一個短期應用程序來說，這本來可以，但是像我們這樣長期運行的應用程序很容易用完文件描述符。 例如突然而持續的峰值。

讓他們自動關閉！

我們不想失去流媒體的好處，但是我們也無法控制流媒體。 您可能會說我們應該將流放在可自動關閉的結構中（例如try-with-resources ）。 不錯的嘗試; 但是可悲的是，Hibernate在我們的執行范圍之外（特別是在@Transactional流中）讀取它們。 一旦我們開始在代碼范圍內關閉流，我們的數據庫操作就開始慘敗-尖叫“流已關閉！”。

他們說， 在羅馬時，就像羅馬人一樣 。

因此，我們決定不打擾Hibernate，而是決定自己處理流。

Rajind（是的，還是他）再次入侵了SelfClosingInputStream包裝器 。 這將跟蹤從底層流讀取的數據量，并在讀取最后一個字節后立即將其關閉。

（我們確實考慮過使用現有選項，例如來自Apache commons-io AutoCloseInputStream ；但是發生了，我們到處都需要一些自定義設置，例如詳細的跟蹤日志記錄。）

底線

當涉及到Java中的資源管理時，很容易過度關注內存和CPU（處理），而忽略其余部分。 但是虛擬資源（例如臨時端口和每個進程的文件描述符 ）可能同樣重要，甚至更多。

尤其是在長時間運行的流程（例如我們的AS2 Gateway SaaS應用程序）上，它們實際上可以成為沉默的殺手。

您可以通過兩種主要方式檢測這種“泄漏”：

• “單周期”資源分析 ：運行一個完整的處理周期，比較前后的資源使用情況
• 長期監控 ：持續記錄和分析資源指標以識別趨勢和異常

在任何情況下，修復泄漏都不是一件容易的事。 一旦您清楚地了解要處理的內容。

祝您好運，尋找您的資源消耗d（a）守護程序！

翻譯自: https://www.javacodegeeks.com/2019/10/is-your-jvm-leaking-file-descriptors-like-mine.html

總結

以上是生活随笔為你收集整理的您的JVM是否泄漏文件描述符-像我的一样？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。