現在、シャットダウンする前に Web アプリケーションでクリーンアップ タスクを実行するために実装ServletContextListenerおよび使用しています。ただし、同じ目的でcontextDestroyed()どのように使用できるかについて読んでいます。Runtime.addShutdownHook(Thread)
アンデプロイメント前にクリーンアップを実行するこれら 2 つの方法に違いはありますか? 機能性、効率性、および保守性の観点から、Web アプリケーションに適しているのはどれですか?
ServletContextListener は、セッションごとにリソースをクリーンアップするため、Web アプリケーションにより適していると思います。
JVM がシャットダウンされた状態で、シャットダウン フックが実行されます。それは、1 回限りのイベントであるコンテナーを停止するときです。
addShutdownHook（）を使用する場合の危険性は、アプリを複数回再デプロイすると明らかになるクラスローダーリークが発生する可能性があることです。
シャットダウンフックのクラス（WebアプリケーションのThreadサブクラスまたはRunnable実装のいずれか）はWebアプリケーションのクラスローダーから取得されるため、Webアプリケーションがコンテナーによってアンデプロイされた後でも、シャットダウンフックはシステムに登録されます。これは、Webアプリのクラスローダー全体をガベージコレクションできないことを意味します。
私は間違いなくServletContextListenerをお勧めします。
多くのサーブレット コンテナーは、JVM プロセスをシャットダウンせずに WAR を動的にドロップまたは再ロードする操作をサポートしています。したがって、クリーンアップ ルーチンを ServletContextListener として記述した場合、コンテナの存続期間中に数回実行される可能性があります。(たとえば、コンテナー プロセスがまだ稼働している間に WAR を数回変更してリロードした場合)。
ただし、Runtime.addShutdownHook を使用してクリーンアップを実装すると、コンテナー全体の JVM がシャットダウンされたときに 1 回だけ実行されます。
ServletContextListener は、それをホストしているコンテナー プロセスの寿命とは対照的に、クリーンアップ ルーチンを Web アプリケーションの寿命と結びつけるため、おそらく正しい答えです。
私たちが話しているリークは、ホット/デプロイを行った場合にのみ発生します。ただし、配置を変更するたびにサーバーを再起動すると、フックはメモリ リークなしで正常に動作するはずです。また、リークを支配するもう 1 つの要因は、リスナー/フックを介して制御しようとしているリソース クリーニングのタイプです。