2010-07-19 54 views
0

我們正在Tomcat 6.0.28下運行一個基於Spring的後端的小型JRuby on Rails應用程序。我花了一些時間與Eclipse內存分析工具,我可以肯定地告訴JRubyClassLoader泄漏的實例。我將我們的webapp設置爲僅使用單個JRuby運行時,然後我有效地通過touching對戰爭進行了熱部署。這樣做了幾次之後,我可以看到幾個坐在旁邊的實例。JRubyClassLoader未發佈

由於類加載器沒有被釋放,它所加載的類沒有被釋放,所以我們沒有使用PermGen空間。

使用Eclipse內存分析,我可以看到路徑GC根的樣子:

org.jruby.util.JRubyClassLoader 
    jrubyClassLoader org.jruby.Ruby 
    runtime org.jruby.util.io.ChannelStream 
     reference java.lang.ref.Finalizer 
     next java.lang.ref.Finalizer 

next java.lang.ref.Finalizer不勝枚舉看似永遠...指向我似乎在無法找到實際的GC根。

如果運行泄漏嫌疑人報告中,排名第一的嫌疑人是「java.lang.ref.Finalizer」,由「<系統類加載器>」加載。

任何想法爲什麼終結者是堅持?

編輯

其可能與側面說明,我每次做一個熱點部署時,一大家子的NullPointerExceptions擺:

java.lang.NullPointerException 
    at com.kenai.jffi.Function.finalize(Function.java:177) 
    at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) 
    at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83) 
    at java.lang.ref.Finalizer.access$100(Finalizer.java:14) 
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) 

EDIT 2

我升級到JRuby 1.5.1,我仍然看到同樣的問題。

回答

0

有意思。另一個不應使用finalize()的證據。

這不是你的錯,對此你沒有太多的辦法。

也許試圖說服JRuby團隊放棄finalize()? JRuby是否應該儘早處理資源釋放而不是等到GC?開發人員使用 JRuby不與這些對象交互,它們都在JRuby的控制之下。