0

Springベースのバックエンドを備えたTomcat6.0.28で小さなJRubyonRailsアプリを実行しています。JRubyClassLoaderEclipseメモリ分析ツールを使用してしばらく時間を過ごしましたが、インスタンスがリークしていることは間違いありません。単一のJRubyランタイムのみを使用するようにWebアプリをセットアップしてからtouching、戦争によってTomcatへのホットデプロイを効果的に実行しました。それを数回行った後、私はJRubyClassLoader座っているいくつかの例を見ることができます。

クラスローダーが解放されていないため、ロードされたクラスが解放されておらず、PermGenスペースが不足しています。

Eclipse Memory Analysisを使用すると、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ルートを見つけることができないように見えるところまで。

Leak Suspectsレポートを実行する場合、＃1の容疑者は「<systemclassloader>」によってロードされた「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)

編集2

JRuby 1.5.1にアップグレードしましたが、同じ問題が引き続き発生します。

4

1 に答える 1

0

面白い。finalize()使用されるべきではない別の証拠。

それはあなたのせいではなく、あなたがそれについてできることはあまりありません。

たぶんJRubyチームにドロップするように説得しようとしますfinalize()か？JRubyは、GCまで待つのではなく、できるだけ早い時期にリソースの割り当て解除を処理するべきではありませんか？JRubyを使用している開発者は、これらのオブジェクトとインターフェースをとっていません。これらはすべてJRubyの制御下にあります。

于 2010-07-19T19:30:59.520 に答える