为什么 Java 的序列化比 3rd 方 API 慢？答案

【问题标题】：Why Java's serialization slower than 3rd party APIs?为什么 Java 的序列化比 3rd 方 API 慢？
【发布时间】：2013-10-18 10:40:17
【问题描述】：

在处理套接字和序列化对象的过程中，我注意到有一些第三方库可以在 Java 上实现更快的对象序列化，例如 Kryo 和 FST。到现在为止，我期望Java的序列化是优化的并且是最快的。因为，它依赖于语言，并提供了一个预计会更快的低级解决方案。但是，所考虑的库声称它们比 Java 更快。

谁能解释一下为什么 Java 不能提供最快的序列化解决方案？为了什么而放弃更好的性能？

提前致谢。

【问题讨论】：

一方面，它们都不支持开箱即用的版本控制，因此您不会将同类与同类进行比较。（Kryo 用额外的代码支持它。）
相关：stackoverflow.com/questions/239280/…
JDK不支持版本控制，它只是设法抛出一个异常，这不是很有帮助。
@R.Moeller 垃圾。 Object Versioning Specification 中有整整一章。
@EJP 好吧，我想指出版本控制实现的成本/回报比非常糟糕。在现实世界的实践中，需要 99% 的时间手动处理版本控制。不难想象版本支持方案，它根本不影响性能。

标签： java performance serialization

【解决方案1】：

有几个原因（我是http://code.google.com/p/fast-serialization/的作者）

原因：

爬取每个对象的类层次结构，以防万一，对每个对象执行多次读取/写入对象调用。
部分编码不佳（使用 1.7 进行了改进）
一些常用的类利用了旧的慢速 + 过时的序列化功能，例如 putfield/getfield 等。
临时对象分配过多
大量验证（版本控制、实现的接口）
缓慢的 Java 输入/输出流
反射设置/获取字段值。
使用需要“大数字”的 JDK 集合，例如 Integer 或 Long，而不是原语。
实现缺乏某些算法优化:-)
在 x86 上将原语重新排序为网络字节顺序（在 java 代码中，而不是本机）。

为了提供更好的性能，他们将不得不放弃对旧版本控制方案的支持（例如，read/writeObject 目前的工作方式不是最理想的），并让一些东西（例如版本控制支持可选）或选择对性能更敏感的方法那（可能）。此外，HotSpot 可能会添加一些内在函数来改进基元的低级处理。在设计 API 时需要考虑性能，而 JDK 序列化可能并非如此。

【讨论】：

【解决方案2】：

Java 序列化很慢，因为它使用反射。 JDK 序列化做了很多向后兼容性检查和严格的类型检查。但是在大多数情况下，java 序列化在反序列化后获得了 100% 相同的对象。

【讨论】：