在我職業生涯中進行的所有故障排除練習中，我感到隨著時間的推移，我所追尋的錯誤在不斷發展，變得越來越卑鄙和丑陋。 也許僅僅是我的年齡開始了。這個特別的Heisenbug –看起來像這篇帖子一樣，再次讓我清醒了很多，而不是我想要的。

與其他特別令人討厭的錯誤一樣，我現在遇到的那個錯誤的癥狀是“有時系統運行緩慢”。 太好了，我已經感覺到脊椎發麻。 當我發現系統在生產中設置了簡單的監視解決方案來監視系統時，情況就好了一些。 從本質上講，它只是Pingdom的功能 ，每秒測量一次響應時間，但是延遲圖立即引起了我的注意。

在圖中繪制的響應時間似乎是隨機的尖峰–每次在藍月亮中，響應開始花費的時間將近10倍。 不久之后，一切又恢復了正常。

最初的犯罪嫌疑人–看不見定期的cron工作或昂貴的報告流程。 存儲監視也沒有暴露任何特別丑陋的查詢擊中數據庫。 但是在打電話之前，我在應用程序配置中添加了更多日志記錄選項，重新啟動了整個程序，并迷惑了自己的行為。

第二天早上，我還有其他事情要看，GC日志等。 十分鐘之內，我發現自己盯著下面的東西：

11.408: [Full GC [PSYoungGen: 192K->0K(48640K)] [ParOldGen: 16324K->14750K(114688K)] 16516K->14750K(163328K) [PSPermGen: 31995K->31637K(64000K)], 0.1543430 secs] [Times: user=0.58 sys=0.00, real=0.16 secs] ... 3613.362: [Full GC [PSYoungGen: 256K->0K(47104K)] [ParOldGen: 15142K->13497K(114688K)] 15398K->13497K(161792K) [PSPermGen: 32429K->32369K(72192K)], 0.1129070 secs] [Times: user=0.51 sys=0.00, real=0.11 secs] ... 7215.278: [Full GC [PSYoungGen: 224K->0K(44544K)] [ParOldGen: 13665K->13439K(114688K)] 13889K->13439K(159232K) [PSPermGen: 32426K->32423K(70144K)], 0.0881450 secs] [Times: user=0.44 sys=0.00, real=0.09 secs] ...

現在，我可以將看似隨機的性能下降與每次經過大約3600秒時運行的Full GC關聯起來。 將VisualVM附加到JVM令我感到困惑–沒有證據表明高內存使用率會導致整個垃圾收集器運行。 與開發人員核對后，我確定他們沒有通過cron作業運行顯式GC。 所以我站在那兒，對GC的常規性感到困惑。

工程師對問題感到困惑時會怎么做？ 他谷歌 。 就在那里，凝視著我的臉。 與擔心每小時進行一次完整GC的人員進行的逐頁討論，沒有任何明顯的原因。

罪魁禍首-RMI。 顯然，當您的應用程序通過RMI公開其服務或通過RMI使用任何服務時，您必然會有一個額外的垃圾回收周期。 正如RMI文檔所述 ：

“當需要確保不導出不可達的遠程對象并及時收集垃圾時，此屬性的值表示Java RMI運行時將允許在本地堆的垃圾回收之間的最大間隔（以毫秒為單位）。 默認值為3600000毫秒（一小時）。”

暫時的解決方案是將sun.rmi.dgc.server.gcInterval長度從默認的3,600秒增加。 我想知道，當RMI過去每分鐘強制一次完整的GC時，在JDK 6中引入更改之前，情況如何。 考慮到當時所有的EJB狂潮，我猜沒有一個應用程序在性能方面有機會。 如果您有遠古時代的回憶，也許您可??以向我們說明這些應用程序如何能夠度過這種瘋狂。

參考： RMI強制Full GC每小時從我們的JCG合作伙伴 Nikita Salnikov Tarnovski （在Plumbr Blog博客上）運行。

翻譯自: https://www.javacodegeeks.com/2013/12/rmi-enforcing-full-gc-to-run-hourly.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的RMI强制Full GC每小时运行一次的全部內容，希望文章能夠幫你解決所遇到的問題。

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