Apache Fury 反序列化 InputStream 问题分析与解决方案

问题背景

Apache Fury 是一个高性能的序列化框架，但在使用过程中发现了一个关于 InputStream 反序列化的兼容性问题。当开发者尝试从 ByteArrayInputStream 或其他 InputStream 反序列化对象时，会遇到"Unsupported coder 111"或"IllegalArgumentException"等异常。

问题重现

通过一个简单的测试用例可以重现这个问题：

1. 使用 Fury 序列化一个简单的 Java 对象
2. 尝试通过三种方式反序列化：
   • 直接使用字节数组 - 成功
   • 使用 ByteArrayInputStream - 抛出 UnsupportedOperationException
   • 使用 BufferedInputStream 包装的 ByteArrayInputStream - 抛出 IllegalArgumentException

问题根源

经过分析，这个问题源于 Fury 序列化输出流和字节数组两种方式的差异：

1. 序列化到 OutputStream 时：Fury 会在数据前写入对象的大小信息
2. 序列化到字节数组时：不包含这个大小信息

当尝试用 deserializeJavaObject(InputStream) 方法反序列化来自 serializeJavaObject(Object) 的数据时，由于缺少预期的长度前缀，导致解析失败。

当前解决方案

目前有两种临时解决方案：

1. 手动添加长度前缀：在字节数组前添加4字节的长度信息
2. 保持序列化和反序列化方式一致：
   • 序列化使用 serializeJavaObject(OutputStream, Object)
   • 反序列化使用 deserializeJavaObject(InputStream, Class)

未来改进方向

Fury 社区已经意识到这个问题，并计划从以下几个方面进行改进：

1. 原生流式反序列化支持：让 MemoryBuffer 能够持有读取通道或输入流对象
2. 零拷贝优化：特别针对大对象和大数据处理场景
3. API 一致性：统一不同序列化/反序列化方式的行为

性能考量

值得注意的是，Fury 当前的设计选择是基于性能考虑：

1. 避免多态设计 MemoryBuffer 以保持方法调用的高效性
2. 对小对象场景优化，牺牲了部分流式处理的便利性

但随着大数据和机器学习应用的普及，对大对象的流式处理需求日益增长，这使得改进流式反序列化支持变得尤为重要。

总结

这个问题反映了序列化框架在流式处理和批处理之间的权衡。开发者在使用时需要注意序列化和反序列化方法的配对使用，而 Fury 社区也正在努力提供更统一和高效的流式处理支持。对于性能敏感的应用，目前建议使用字节数组方式或确保输入输出流配对使用。