0

実稼働環境でいくつかの問題が発生しており、しばらくすると、コンパイルされた jsps の 1 つ (時々異なります) から InvalidPropertyException が発生します。これは、ヒープから何かが「消える」ことが原因であると思われます。さらに、これはヒープのジェネレーションの 1 つがいっぱいになったことが原因であると思われるため、一部のオブジェクトは別のジェネレーションに「流出」し、最終的に GC 処理されます。

私が疑問に思っているのは、ヒープを自動的に監視し、世代の1つがいっぱいになり、そのような流出の可能性があるときに警告することは可能ですか? これは、プログラムによるものか、何らかの構成によるものである可能性があります.JConsole を使用してみましたが、エラーが発生し始めた後にのみ、すべてが正常に見えますが、私が本当に望んでいるのは、エラーが発生した正確な時間にどのように見えるかを知ることです.手動で監視する必要なく、エラーが発生します (実際には数分前)。

この問題に関するより一般的な質問を投稿しました。これには、さらに詳細が記載されています: Spring、NotReadablePropertyException、Glassfish バージョン

4

2 に答える 2

2

問題がヒープに関連している可能性がないとは言いませんが、そうである場合は、JVM のメモリ サブシステムとガベージ コレクターに重大かつ非常に重大なバグがあることを示しています。もちろん不可能ではありませんが、他の複数の人々によって発見された可能性が非常に高く、他の誰かが同様のことを報告しているとは聞いていないため、可能性は非常に低いです.

基本的に、オブジェクトへのライブ参照が少なくとも 1 つある間は、オブジェクトが GC:ed されることはありません。ヒープ内の世代間の移動は、それとは何の関係もありません。これは、メモリ処理を最適化するために GC によって行われるバックグラウンド作業です。実際、すべての JVM: に世代があるわけではありません。

「消える」オブジェクトがある場合、それは、使用しているWeakReference、またはSoftReference単にコード内でオブジェクトを逆参照して、再利用の対象にするためです。

実際の例外 (スタック トレースなど) と関連するコードの詳細を投稿すると、おそらくここの誰かが問題を見つけるのに役立ちます。

于 2012-11-23T10:27:36.040 に答える
0

コメントはさておき、異なる世代で何が起こっているかを本当に知りたい場合は、Verbose GC ロギングを有効にしてください。java コマンドに-verbose:gcandを追加するだけです。-XX:+PrintGCDetailsこれにより、次のような行を含む GC ログが生成されます。

94.198: [Full GC (System) 94.198: [Tenured: 788K->759K(4096K), 0.0428238 secs] 883K->759K(5056K), [Perm : 2095K->2095K(12288K)], 0.0429641 secs]

これにより、ガベージ コレクションの前後で各世代が使用しているスペースの量がわかります。

この記事には、上記のログの例を取得したこのブログと同様に、このトピックに関する多くの情報があります。

于 2012-11-23T09:24:28.383 に答える