静的な最終オブジェクトはガベージコレクタによって削除されますか？

Question

以前は常にJavaのサービスでカスタムオブジェクトを使用していましたが、バックエンドで常に実行し続けていました。ガベージコレクタによってオブジェクトが破棄されたために、NULL_POINTER_EXCEPTIONというトレースを含むバグレポートが表示されることがあります。私はすべてのハイエンドデバイスを持っているので、私はこれをテストすることができません静的な最終的なオブジェクトはガベージコレクタによって破壊されるかどうか？

Answer 1

静的な最終オブジェクトはガベージコレクタによって削除されますか？

私はこれが起こる可能性が3つの状況を考えることができます。staticを持つクラスをロードしたクラスローダが到達不能になった

1. 。しかし、これはの後に発生する可能性があります。あなたのコードは、オブジェクトがGC'dであることに気付くことのできないポイントに達しました！

2. をstatic finalに割り当てるために何か「厄介な反射癖」が使用されました。 （はい、できます...）

3. 何かが微妙にヒープを破壊しています。例えばいくつかのバグのあるJNI/JNAコード。

注あなたは（明らかに）にGC'dされているオブジェクトの効果を観察しているので、それはははGC'dているクラスローダの直接の結果することができないこと。クラスローダーとfinal staticをGC'edできるようにするために何か他のことが起こっているはずです...もし実際にここで起こっているのであれば。

---

実際に、あなたの問題はGC関連ではないと思われます。むしろ、私はあなたのサービスが記録されていないチェックされていない例外のために死んでいると思われます。"main"以外のスレッドでキャッチされない例外のデフォルトの動作は、それらを黙って無視することです。

run()メソッドのcatchまたは "キャッチされない例外ハンドラ"のいずれかでサービススレッドがすべての例外を記録していることを確認することをお勧めします。

Answer 2

JVMはマークスイープGCアルゴリズムを使用します。これは、GCの "ルート"位置（現在のコールスタック内のすべてのオブジェクトと同様）のすべてのライブ参照を検査する必要があります。各ライブオブジェクトは生きていると「マークされています」、ライブオブジェクトによって参照されるオブジェクトには「生きている」とマークされます。

マークフェーズの完了後、GCはヒープをスイープし、マークされていないすべてのオブジェクトのメモリを解放します（残りのライブオブジェクトのメモリを圧縮します）。

「いいえ、最終的な改変者は、GCが作業負荷を軽減するのに役立たない」と言うつもりです。

Answer 3

通常のJavaアプリケーション（私はAndroidについてはわかりません）では、static final参照されたObjectは、適切なClassLoaderがアンロードされたときにのみGCedされます。

たとえば、コンテナ（Tomcatなど）に複数のWebアプリケーションを配置し、各WebアプリケーションをアンデプロイしてアプリケーションのClassLoaderをアンロードすると、アプリケーションのstatic final参照されたオブジェクトがGCedされます。しかし、他のClassLoader（他のweb-appのClassLoader、共通ClassLoader、boot-strap ClassLoaderなど）によってロードされたオブジェクトはGCされません。

あなたの質問に対する答えは、ClassLoaderが非アクティブ化されているかどうかによって異なります。