Apache Fury 中 ThreadPoolFury 的 ClassLoader 问题解析

背景介绍

Apache Fury 是一个高性能的序列化框架，在 Java 生态中提供了高效的二进制序列化能力。其中 ThreadPoolFury 是其线程安全的 Fury 实现，用于多线程环境下的序列化操作。然而，近期发现了一个与 ClassLoader 相关的重要问题，特别是在处理动态代理对象时。

问题现象

当使用 ThreadPoolFury 序列化和反序列化动态代理对象时，如果代理接口是由不同于当前线程上下文类加载器的类加载器加载的，就会抛出"non-public interface is not defined by the given loader"异常。这种情况常见于 Spring Boot 应用中，当 Spring 的 SerializableTypeWrapper 创建代理时使用应用类加载器(AppClassLoader)，而 ThreadPoolFury 在反序列化时却使用了 Tomcat 的嵌入式类加载器(TomcatEmbeddedClassLoader)。

问题根源

深入分析后发现，ThreadPoolFury 存在两个关键问题：

1. 它没有正确继承 FuryBuilder 中设置的类加载器，而是默认使用线程上下文类加载器(Thread.currentThread().getContextClassLoader())
2. 在反序列化动态代理时，Proxy.newProxyInstance() 方法要求接口类必须由指定的类加载器定义，否则会抛出异常

解决方案

Apache Fury 项目组已经修复了这个问题，主要改进包括：

1. 确保 ThreadPoolFury 正确使用 FuryBuilder 中配置的类加载器
2. 提供了更灵活的类加载器设置方式，允许开发者根据需求选择：
   • 全局固定类加载器（通过 FuryBuilder.withClassLoader()）
   • 线程级类加载器（通过 ThreadSafeFury.setClassLoader()）
   • 自定义类加载器策略（通过 ThreadPoolFury 构造函数）

最佳实践

对于需要使用 ThreadPoolFury 处理动态代理的场景，建议采用以下方式：

// 方式1：使用固定类加载器
ThreadSafeFury fury = Fury.builder()
    .withClassLoader(myClassLoader)  // 设置固定类加载器
    .buildThreadSafeFuryPool();

// 方式2：自定义类加载策略
ThreadSafeFury fury = new ThreadPoolFury(classloader -> 
    Fury.builder()
        .withClassLoader(myClassLoader)  // 每个线程使用相同的类加载器
        .build()
);

技术要点

1. Java 动态代理机制对类加载器的要求非常严格，接口类必须由指定的类加载器定义
2. 在多线程环境下，线程上下文类加载器可能与创建代理时的类加载器不同
3. 序列化框架需要确保序列化和反序列化时使用一致的类加载器上下文

总结

这个问题揭示了在复杂类加载环境下处理动态代理对象的挑战。Apache Fury 的修复确保了框架在不同类加载器环境下的稳定性，特别是对于 Spring 等框架生成的代理对象的支持。开发者在使用时应当注意类加载器的设置，特别是在容器环境中。