Apache Fury 多线程环境下类加载器问题的分析与解决

Apache Fury 是一个高性能的 Java 序列化框架，但在某些特殊场景下会出现类加载问题。本文将深入分析一个在多线程环境特别是 ForkJoinPool 中使用 Fury 时遇到的 ClassNotFoundException 问题。

问题现象

当开发者在自定义类加载器环境中使用 Fury 进行序列化/反序列化操作时，如果这些操作被提交到 ForkJoinPool.commonPool() 中异步执行，就会出现 ClassNotFoundException。具体表现为：

1. 主线程能够正常完成序列化/反序列化操作
2. 但在 ForkJoinPool 工作线程中执行相同操作时，却无法找到相应的类

根本原因分析

经过深入分析，这个问题由两个关键因素共同导致：

1. ForkJoinPool 的线程特性：在 JDK 11+ 版本中，ForkJoinPool 的工作线程会强制将线程上下文类加载器(ThreadContextClassLoader)设置为系统类加载器(AppClassLoader)，而不再继承父线程的类加载器。

2. Fury 的类加载机制：ThreadSafeFury 的实现没有正确使用构建时指定的类加载器，而是默认使用了线程上下文类加载器。当工作线程的上下文类加载器被强制修改后，就无法找到自定义类加载器加载的类。

技术细节

ForkJoinPool 的类加载器行为变化

在 JDK 8 中，ForkJoinWorkerThread 会继承父线程的上下文类加载器。但从 JDK 11 开始，实现发生了变化：

ForkJoinWorkerThread(ThreadGroup group, ForkJoinPool pool,
                     boolean useSystemClassLoader, boolean isInnocuous) {
    // ...
    if (useSystemClassLoader) // 默认为 true
        super.setContextClassLoader(ClassLoader.getSystemClassLoader());
}

这一变化导致即使用户设置了自定义类加载器，在 ForkJoinPool 中也会被覆盖。

Fury 的类加载机制问题

FuryBuilder.withClassLoader() 方法设置的类加载器只影响当前线程的 Fury 实例，而 ThreadSafeFury 在不同线程中创建新实例时，没有正确继承这个类加载器设置，而是回退到使用线程上下文类加载器。

解决方案

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

1. 确保 ThreadSafeFury 在所有线程中都使用构建时指定的类加载器
2. 不再依赖线程上下文类加载器作为默认选择
3. 提供了更明确的类加载失败错误信息

最佳实践

对于需要在多线程环境中使用 Fury 的开发者，建议：

1. 明确指定 Fury 使用的类加载器
2. 对于自定义类加载器场景，避免依赖线程上下文类加载器
3. 在 ForkJoinPool 等有特殊线程行为的环境中，提前测试序列化/反序列化功能

总结

这个问题展示了在复杂类加载环境和多线程编程中可能遇到的陷阱。Apache Fury 通过这次修复，增强了对特殊运行环境的适应能力，为开发者提供了更可靠的序列化解决方案。理解这些底层机制有助于开发者更好地设计跨线程、跨类加载器的分布式应用。