サーブレットについての私の理解では、サーブレットはコンテナーによってインスタンス化され、そのinit()メソッドは一度呼び出され、サーブレットは JVM がシャットダウンするまでシングルトンのように存続します。
アプリサーバーが回復するか、正常に起動すると、サーブレットが新しく構築されるため、サーブレットがシリアライズされるとは思いません。サーブレットはセッション固有のメンバーを保持してはならないため、ディスクに書き込んで再度インスタンス化しても意味がありません。これには実用的な用途がありますか？
私の懸念は、そこにいくつかのシリアル化できないフィールドを配置すると、別の種類のセッション レプリケーションが行われる本番環境でアプリが不思議なことに失敗することです。
技術的には、EJBセッションBeanと同様に、サーブレットコンテナがサーブレットオブジェクトをディスクに「不動態化」できると思います。したがって、シリアル化できないフィールドが原因でアプリが失敗するかどうかを質問するのは正しいことです。
実際には、これを行うコンテナのことは聞いたことがないので、実際には、初期のJ2EEの古き良き時代からのレガシー手荷物にすぎません。私はそれについて心配しません。
HttpServlet は、ディスクにシリアル化され、サーブレット コンテナーの再起動後も存続する必要があります。たとえば、Tomcat では、この種のサバイバルを可能にするフラグを設定できます。次のオプションは、JNDI を使用した転送です。これはガベージではなく、極端なユース ケースでのみ使用されます。
Googleは、コンテナの作成者が必要に応じてオプションを利用できるようにするために、これが行われたことを示唆しているようです。
サーブレットがセッション固有のメンバーを保持してはならないのは正しいです。実際、状態をできるだけ少なくしたいと思います。すべてをSessionまたはServletConfigのいずれかに保存すると、シリアル化を乗り切ることができると思います。
クラスタオプションを提供するサーブレットコンテナのキャッシュを存続させるためにSessionオブジェクトがシリアル化されるのと同じように、コンテナがサーブレットインスタンスを別のクラスタノードに転送するオプションがあるかもしれません。ここで推測しているだけです
Serializable は、分散環境でセッションの属性のマーカー インターフェイスとして使用されます。
SRV.7.7.2 分散環境 (JSR-154)
配布可能とマークされたアプリケーション内では、セッションの一部であるすべてのリクエストは、一度に 1 つの Java 仮想マシン (「JVM」) によって処理される必要があります。コンテナーは、setAttribute または putValue メソッドを適切に使用して、HttpSession クラスのインスタンスに配置されたすべてのオブジェクトを処理できる必要があります。これらの条件を満たすために、次の制限が課されます。
- コンテナーは、Serializable インターフェイスを実装するオブジェクトを受け入れる必要があります。
- セッションの移行は、コンテナー固有の機能によって処理されます。
分散サーブレット コンテナは、オブジェクトを格納するセッションの移行に必要なメカニズムをコンテナがサポートできないオブジェクトに対して IllegalArgumentException をスローする必要があります。
分散サーブレット コンテナは、 Serializable を実装するオブジェクトの移行に必要なメカニズムをサポートする必要があり ます。
(...)
コンテナー プロバイダーは、分散システムの任意のアクティブなノードからシステムの別のノードにセッション オブジェクトとそのコンテンツを移動する機能を持つことで、負荷分散やフェールオーバーなどのサービス機能のスケーラビリティと品質を確保できます。分散コンテナがサービス品質機能を提供するためにセッションを永続化または移行する場合、ネイティブ JVM シリアライゼーション メカニズムを使用して HttpSession とその属性をシリアライズすることに制限されません。開発者がセッション属性を実装する場合、コンテナーがセッション属性で readObject および writeObject メソッドを呼び出すことは保証されていませんが、それらの属性の Serializable クロージャーが保持されることは保証されています。