罚款在Java中实现Serializable？
是否有惩罚补充
implements Serializable 到Java类？ 对实例化对象或性能的大小的影响？
成本接近零，不值得关注。
一些进一步细节：
- 每个对象实例的大小没有增加
- 类本身的规模有小幅度的增长，但是由于这是一次性成本，所以在大量实例上分摊时是微不足道的
- 对于需要在运行时进行接口检查的任何事情（reflection，实例查找，内联caching的额外压力等），可能会有一些额外的运行时成本。 同样，对于大多数目的，这可能是微不足道的。
- 可串行化是一个标记接口 ，没有需要实现的方法。 其他标记接口的例子有：Clonable，SingleThreadModel，Event listener。
除非你/别人实际序列化/反序列化，否则不会有任何影响。 Serializable只是一个标记界面。
它可能只会将生成的字节码的大小增加几个字节。
除非您执行序列化/反序列化，否则没有性能影响，但在apidevise方面存在权衡。
从有效的Java通过Joshua Bloch
- 实现Serializable的一个主要代价是它减less了一个类的实现一旦被释放就改变的灵活性
- 实现Serializable的第二个代价是增加了bug和安全漏洞的可能性
- 实现Serializable的第三个代价是增加了与释放一个类的新版本相关的testing负担
取决于你的用例，这些适用于什么程度取决于你的用例。
你应该总是首先考虑维护的开销。 现场部署的应用程序的成本可能是其开发成本的几倍。
在这种情况下，生成一个Serializable类的成本，但实际上并没有用于序列化，可能会导致错误或混乱远远超过性能成本。 例如说需要1分钟或者某人的时间才能确定Serializable是不需要的，这可能会比应用程序发生的几纳秒额外启动时间花费更多。
如果你确实需要它是可序列化的，你不能将它与非序列化版本进行比较，因为只有第一种情况才能真正完成所需的工作。
Serializable只是一个“标记”界面。 它不要求你实现任何方法。
唯一的是build议有一个static final long serialVersionUID一个static final long serialVersionUID来帮助序列化API。 每个序列化的类需要花费一个单独的值。
你可能想看看这篇关于Java序列化API的文章 。 它详细描述了序列化/反序列化的大部分注意事项。
