oli*_*ren 7 java serialization
如今，大多数项目中并不常见Java 对象到二进制形式的内置序列化，这些项目倾向于使用 ProtoBufs、XML、JSON 等在服务器之间进行数据传输。CORBA 和所有这些似乎都属于 2000 年左右的项目。老实说，我只见过它实现一次（在十年前的 J2EE 项目中），而且看起来有点奇怪。Serializable不过，每次 IntelliJ 抱怨serialVersionUID某些课程缺失时，我仍然会想起整件事！如今，这种情况主要发生在我使用 Jackson 处理 JSON 序列化/反序列化时，因为它的类型注释表明某些类必须实现Serializable. 通常是这样的东西
StdDeserializer<T> extends JsonDeserializer<T> implements Serializable, Gettable
（我没有看到T需要可序列化，只有序列化器？）
现在，我不明白的是，当我们现在主要处理 JSON 和 XML 时，为什么仍然处理二进制 java 对象序列化的概念。为什么杰克逊（和其他“新”图书馆）会选择处理这个问题？
我唯一的猜测是，这与 Jakcson 客户端序列化的域类无关，但某些高级 JVM 用法可以在 JVM 之间传输正在使用的各种对象或类似的东西，这需要 和 的稳定writeObject()接口readObject()。但我在这里真的如履薄冰。
在查看了为班级介绍此问题的提交后，我就这个问题与 Jackson 的维护者Tatu Saloranta联系StdSerializer，他详细回答了！在这里发布他的答案：
事实上，这是作为用户请求而来的，据我记得，可能有 2 个用例这可能有用。其中第二个可能符合“在不同 JVM 之间移动对象”的资格。我不得不同意，这些用例似乎都不是特别常见的模式，fwtw。
第一个比较奇特的（可能与此时相关，也可能不相关）是 Android 用例的解冻/解冻（或者当应用程序进入后台模式时调用的任何内容，返回，wrt XmlMapper（XML 支持） ObjectMapper）——如果是这样，与重新创建映射器实例相比，使用 JDK 序列化的性能显然要好得多。我不知道情况是否仍然如此。
其次，更广泛适用的用例是 Spark（或 Hadoop，也许是 Flink/Apache Beam）等平台，其中协调器节点可能希望以某种方式配置映射器，然后将其发送到初始化为特定设置的工作节点（还包括注册的模块，这就是序列化器/反序列化器的相关方式）。如果是这样，性能并不是关键，而是能够使用精确的配置。
但是尝试使/保持（反）序列化器 JDK 可序列化是一件很麻烦的事情，我很高兴可以从 Jackson 3.x 中删除它（无论何时发布:)）。ObjectMappers 仍然是 JDK 可序列化的，但不需要许多/大多数内部组件可序列化。这是通过改变映射器的构造方式来完成的，我可能不应该在这里太深入地讨论细节。:)