Fury项目中集合元素为抽象类的序列化问题解析

问题背景

在Apache Fury项目中，当使用Java代码生成模式(codegen)时，如果集合(List)中包含抽象类元素，会出现序列化/反序列化错误。具体表现为：当集合元素类型为抽象类时，生成的代码会错误地假设所有元素都是同一具体类型，导致反序列化失败。

问题复现

考虑以下测试用例：

abstract static class Foo {
    private int f1;
}

static class Foo1 extends Foo {}

static class CollectionAbstractTest {
    private List<Foo> foos;
}

@Test
public void testCollectionAbstractCodegen() {
    Fury fury = Fury.builder()
            .withCodegen(true)
            .requireClassRegistration(false)
            .build();
    CollectionAbstractTest test = new CollectionAbstractTest();
    test.foos = new ArrayList<>(ImmutableList.of(new Foo1(), new Foo1()));
    CollectionAbstractTest object = serDe(fury, test);
}

问题分析

问题根源在于Fury的代码生成逻辑。当处理集合元素时，Fury会生成一个sameElementClassWrite方法，该方法假设集合中所有元素都是同一具体类型。对于抽象类元素，这种假设是不成立的，因为抽象类本身不能被实例化，必须通过其具体子类来实现。

生成的错误代码如下：

private void sameElementClassWrite(int value0, MemoryBuffer memoryBuffer1, 
        java.util.List list2, boolean value1) {
    for (int i = 0; i < value0; i+=1) {
        Object object = list2.get(i);
        if (value1) {
            if ((object == null)) {
                memoryBuffer1.writeByte(((byte)-3));
            } else {
                memoryBuffer1.writeByte(((byte)0));
                fooClassInfoHolder.getSerializer().write(memoryBuffer1, object);
            }
        } else {
            fooClassInfoHolder.getSerializer().write(memoryBuffer1, object);
        }
    }
}

解决方案

Fury开发团队通过两个阶段解决了这个问题：

1. 初步修复：尝试通过修改内联表达式(Inlineable Expression)实现，但发现存在一些问题。

2. 最终修复：采用更低层次的修复方式，从根本上解决了抽象类元素在集合中的序列化问题。新方案会正确处理抽象类元素，不再假设所有元素都是同一具体类型。

性能考虑

原始实现中，Fury需要遍历整个集合来检查所有元素是否为同一类型。这在大多数情况下是不必要的，因为集合通常只包含单一类型元素(除非是类似Set<Object>这样的宽泛类型)。优化后的实现可以减少这种不必要的数组遍历，提高性能。

总结

这个问题展示了在序列化框架中处理抽象类型时的复杂性。Fury通过代码生成优化性能的同时，也需要确保正确处理各种类型场景，包括抽象类和接口。开发团队的低层次修复方案既解决了当前问题，也为未来类似情况提供了更好的扩展性。

对于使用Fury的开发者来说，这个修复意味着可以安全地在集合中使用抽象类元素，而不用担心序列化/反序列化失败的问题，同时还能享受代码生成带来的性能优势。