对象的序列化(object serialization)API，它提供了一个框架，用来将对象编码成一个字节流，以及从字节流编码中重新构建对象。
一、谨慎地实现Serializable
要想使一个类的实例可被序列化，非常简单，只要它的声明中加入"implements
Serializable"即可。正因为太容易了，所以普遍存在这样一种误解：程序员只需要做极少的工作就可以支持序列化了。
因为实现Serializable而付出的最大代价是，一旦一个类被发布，则”改变这个类的实现“的灵活性将大大降低。当一个类的序列化形式Serialized form变成了它的导出的API的一部分。一旦这个类被广泛使用，那么必须要永远支持这种序列化形式，就好像你必须要支持所有其他部分导出的API一样。如果你没有精力来设计一个自定义的序列化形式（custom serialized form），而仅仅接受了默认的序列化形式，那么，这个类的序列化形式将永远束缚在该类最初的内部表示上。
序列化会使类的演化受到限制，这种限制的一个例子与刘的惟一标示符（Stream unique identifier）有关，通常它也被称为序列版本UID（serial version UID）。每一个可序列化的类都有一个惟一标识号与它相关联，如果你没有在一个名为SerialVersionUID的私有静态final的long域中显式地指定该标识号，那么系统会自动将一个确定性的复杂过程作用在这个类上，从而产生该标识号，这个自动产生的值会受到类名字，它实现的接口的名字、以及所有公有和受保护的成员的名字的影响。
实现Serializable的第二个代价是，它增加了错误（bug）和安全漏洞的可能性。因为反序列化过程必须要保证所有“由真正的构造函数建立起来的约束关系”，并且不允许攻击者能访问到正在构造过程中的对象的内部信息：依靠默认的反序列化机制很容易使对象的约束关系受到破坏，以及遭受非法访问。
实现Serializable的第三个代价是，随着一个类的新颁布的发行，相关的测试负担增加了。当一个可序列化的类被修订的时候，很重要的一点事，要检查是否可以“在新颁布中序列化一个实例，然后在老版本中反序列化”，或者相反的过程：异常，测试所需要的工作量与“可序列化的类的数量x版本数”的乘积成正比。
实现Serializable接口不是一个很轻松就可以做出的决定。
为了继承而设计的类应该很少实现Serializable，接口也应该很少会扩展它。