为什么Java的序列化比第三方API慢？

Question

在处理套接字和通过它们进行对象序列化时，我注意到有一些第三方库可以更快地进行Java对象序列化，例如Kryo和FST。迄今为止，我期望Java的序列化已经被优化并且是最快的。因为它是语言相关的，提供了一个预计会更快的低级解决方案。但是，考虑到这些库声称它们比Java更快。

有人能解释一下为什么Java不能提供最快的序列化解决方案吗？它放弃了哪些性能以换取更好的性能？

提前感谢。

- ovunccetin

---

首先，这两个都不支持开箱即用的版本控制，所以你不能拿它们进行比较。（Kryo可以通过额外的代码来支持版本控制。） - user207421

相关链接：https://dev59.com/8HVC5IYBdhLWcg3wnCb6 - Christophe Roussy

JDK不支持版本控制，它只是管理抛出异常，这对于解决问题没有太大帮助。 - R.Moeller

@R.Moeller 垃圾。在对象版本规范中有一个完整的章节讲解它。 - user207421

@EJP，嗯，我想指出版本控制实现的成本/回报比相当糟糕。在实际应用中，99%的时间需要手动处理版本控制。很容易想象一些版本支持方案，完全不会影响性能。 - R.Moeller

Answer 1

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

原因：

• 对于每个对象在层次结构中爬取类进行读写操作，每个对象都需要多次调用read/writeObject。
• 部分代码编写不佳（1.7版本已经改进）。
• 一些常用类使用旧的、缓慢而过时的序列化特性，例如putfield/getfield等。
• 临时对象分配太多。
• 很多验证（版本控制，实现接口）。
• Java输入/输出流速度慢。
• 使用反射设置/获取字段值。
• 使用JDK集合需要“大数字”，如Integer或Long，而不是基本类型。
• 实现缺乏某些算法优化 :-)
• 基本类型按照网络字节顺序（在Java代码中，而不是本地代码中）重新排序。

为了提高性能，他们需要放弃旧版本支持方案（例如，当前read/writeObject的工作方式不是最佳选择），并选择更加性能敏感的方法来实现版本支持（这是可能的）。此外，HotSpot可能会添加一些内置功能来改进原始数据处理。当设计API时，需要考虑性能，这可能不是JDK序列化的情况。

- R.Moeller

Answer 2

Java序列化因使用反射而变慢。JDK序列化进行了大量的向后兼容检查和严格类型检查。但是，在大多数情况下，Java序列化在反序列化后保证100％相同的对象。

- Ratnesh Dubey