Java docs のシリアライズ可能性によると：
クラスのシリアライズ可能性は、java.io.Serializable インターフェイスを実装するクラスによって有効になります。このインターフェイスを実装しないクラスは、状態がシリアライズまたはデシリアライズされません。シリアライズ可能なクラスのすべてのサブタイプは、それ自体がシリアライズ可能です。シリアライゼーション インターフェイスにはメソッドやフィールドがなく、シリアライズ可能であることのセマンティクスを識別するためだけに機能します。
オブジェクトがまだ実装されていないのはなぜSerializableですか? シリアライズ可能にしたくないメンバーは、 として作成できますtransient。デフォルトのシリアライズ可能性を妨げるのはなぜですか?
シリアライズ可能なクラスのすべてのサブタイプは、それ自体がシリアライズ可能です。
つまり、これまでに作成した、作成した、または作成する予定のすべてのクラスは、すべてシリアライズ可能です。transientクラス全体ではなく、フィールドのみを除外します。
DataSourceこれは潜在的なセキュリティ ホールです。たまたま、たとえば内部のデータベース資格情報でシリアル化できますが、この特定のDataSource実装の作成者がそのようなフィールドを作成するのを忘れた場合transientです。ランダムな Java オブジェクトをシリアル化するのは驚くほど簡単です。たとえば、outer への暗黙的な参照を保持する内部クラスを使用しthisます。
コードを慎重に調べて、不要なフィールドがシリアル化されないようにするのではなく、明示的に必要なクラスのホワイトリストを使用してシリアル化を許可する方が安全です。
さらに、もはや言うことはできません: MySuperSecretClassis not serializable (単に を実装しないことによりSerializable) - 内臓 (フィールド) のみを除外できます。
1. Serializableは空のマーカー インターフェイスですが、クラスが Serializable とマークされている場合は、そのオブジェクトが Serializable であることを意味します。
2. java.lang.Object が Serializable を実装しなかった理由は、特定のフィールドを Serializable にしたくない場合に、そのフィールドに一時的なものを追加するのを間違えた場合、大混乱になるからです。
3.プログラマーに自分のクラスに Serializable を実装させることで、プログラマーは自分が意識的にそれを実装したことを意識し、シリアライズされるべきではないものがシリアライズされるのを防ぐために必要な措置を講じる必要があります。
ほとんどのクラスはシリアライズ可能である必要はありません。現在の設計では、クラスがシリアライズ可能であることが簡単にわかります。基本的に、これはコンパイラによってチェックされた自己文書にすぎません。そうでなければ、おそらく次のように書くでしょう:
/** DON'T SERIALIZE IT!!! */
class Connection { ... }
コメントよりも言語やライブラリの機能を持っている方が良いです。
Serializable永続化が必要なオブジェクトに対して実装する方が理にかなっており、クラスのすべてのフィールドを宣言するのtransienntはより面倒になると思います。私が確信していないもう1つのポイントはObject、それがリフレクション関連のクラスを含むすべてのクラスのルートであるため、オブジェクトクラスにSerializableを実装することは不適切です。