Kryo是否无法序列化大于2GB的对象？Spark序列化配置疑问

三个问题直接给答案：

• 完全没必要切换Java序列化器，切了也解决不了2GB大小限制的问题
• Java序列化器同样存在接近2GB的大小上限，性能还比Kryo差很多
• 出现待序列化单对象超过2GB的情况，本质是数据处理逻辑设计不合理，优先改逻辑拆分大对象，别想着靠调序列化参数绕过去

Kryo缓冲区2GB的上限不是框架故意设置的阈值，根源是JVM的原生限制：Java里字节数组能分配的最大长度就是Integer.MAX_VALUE，算上对象头、内存对齐的开销，实际可用连续空间不到2GB。Kryo序列化时需要申请连续的字节缓冲区存储序列化结果，所以Spark直接把spark.kryoserializer.buffer.max的最大可配置值硬限制为2048MB。
Java序列化存储结果同样需要申请连续字节块，所以单对象大小接近2GB的时候，一样会抛出数组长度超限、堆内存不足的错误，根本不存在“Java序列化能支持更大对象”的说法。而且同等数据量下，Java序列化的速度、内存占用表现都比Kryo差3~10倍，切换属于纯粹的负优化。

按推荐优先级从高到低排列：

• 优先拆分超大对象：这是最彻底、性能最好的解决方案。99%出现单对象超2GB的场景，都是代码逻辑不合理导致的：比如把整个分区的所有数据聚成一个大集合传递、把GB级的大文件整个读成单个字节数组、单条数据里塞了超大的二进制字段。这类场景直接调整逻辑即可：大集合拆成多个小批次分批处理、大文件改为分块流式读取、超大字段单独存到对象存储只传访问引用，从根源上避免产生超大单对象。
• 特殊场景自定义分块序列化：如果业务逻辑确实无法拆分大对象（这种场景非常少见），可以自行实现Kryo序列化器，对超大对象做分块处理：序列化时把大对象拆成多个小于1.8GB的字节块依次写入，反序列化时按顺序读取块拼接为完整对象。这种方案需要自行维护序列化逻辑，兼容性差、维护成本高，不到万不得已不建议使用。
• 不要白费功夫修改Spark源码试图把spark.kryoserializer.buffer.max设到2GB以上，底层字节数组申请逻辑会直接抛出错误，任务根本无法正常运行。
• 额外提醒：就算你把对象大小刚好压到2GB以内，这种超大对象序列化/反序列化的过程也会占用大量堆内存，频繁触发Full GC，把整个任务的性能拉得极低，哪怕能跑通也不建议保留这类逻辑。

内容的提问来源于stack exchange，提问作者Pavel Orekhov