CompletableFuture / ForkJoinPool Set Class Loader

我遇到了类似的事情，并提出了一个不使用反射的解决方案，似乎与JDK9-JDK11配合得很好。

以下是javadocs所说的：

用于构造公共池的参数可以通过设置以下系统属性来控制：

• java.util.concurrent.ForkJoinPool.common.threadFactory - ForkJoinPool.ForkJoinWorkerThreadFactory的类名。系统类装入器用于装入此类。

因此，如果您推出自己的版本，并将其设置为使用正确的使用系统属性，这应该有效。ForkJoinWorkerThreadFactoryClassLoader

这是我的自定义：ForkJoinWorkerThreadFactory

package foo;

public class MyForkJoinWorkerThreadFactory implements ForkJoinWorkerThreadFactory {

    @Override
    public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
        return new MyForkJoinWorkerThread(pool);
    }

    private static class MyForkJoinWorkerThread extends ForkJoinWorkerThread {

        private MyForkJoinWorkerThread(final ForkJoinPool pool) {
            super(pool);
            // set the correct classloader here
            setContextClassLoader(Thread.currentThread().getContextClassLoader());
        }
    }
} 

，然后在应用启动脚本中设置系统属性

-Djava.util.concurrent.ForkJoinPool.common.threadFactory=foo.MyForkJoinWorkerThreadFactory

上面的解决方案是假设第一次引用 ForkJoinPool 类并初始化 ，则此线程的上下文 ClassLoader 是您需要的正确上下文 ClassLoader（而不是 System 类加载器）。commonPool

以下是一些可能有帮助的背景知识：

Fork/Join 公共池线程返回系统类装入器作为其线程上下文类装入器。

在 Java SE 9 中，属于 fork/join 公共池的线程将始终返回系统类装入器作为其线程上下文类装入器。在以前的发行版中，线程上下文类装入器可能继承自导致创建 fork/join 公共池线程的任何线程，例如通过提交任务。应用程序不能可靠地依赖于 fork/join 公共池何时或如何创建线程，因此不能可靠地依赖于要设置为线程上下文类装入器的自定义类装入器。

由于上述向后不兼容更改，使用用于在 JDK8 中工作的的东西在 JDK9+ 中可能不起作用。ForkJoinPool

所以，这是一个非常肮脏的解决方案，我对此并不感到自豪，如果你同意它，可能会为你打破一些东西：

问题是应用程序的类装入器未用于 。由于commonPool的设置是静态的，因此在应用程序启动期间，以后没有容易进行更改的可能性（至少据我所知）。因此，我们需要依赖 Java 反射 API。ForkJoinPool.commonPool()

1. 在应用程序成功启动后创建挂钩

   • 在我的情况下（Spring Boot环境），这将是应用程序ReadyEvent

   • 要侦听此事件，您需要一个如下所示的组件

     @Component
     class ForkJoinCommonPoolFix : ApplicationListener<ApplicationReadyEvent> {
         override fun onApplicationEvent(event: ApplicationReadyEvent?) {
       }
     }
     

2. 在你的钩子里面，你需要将commonPool设置为自定义实现（所以这个自定义实现将使用应用程序类加载器）ForkJoinWorkerThreadFactory

   • （科特林）

     val javaClass = ForkJoinPool.commonPool()::class.java
     val field = javaClass.getDeclaredField("factory")
     field.isAccessible = true
     val modifiers = field::class.java.getDeclaredField("modifiers")
     modifiers.isAccessible = true
     modifiers.setInt(field, field.modifiers and Modifier.FINAL.inv())
     field.set(ForkJoinPool.commonPool(), CustomForkJoinWorkerThreadFactory())
     field.isAccessible = false
     

3. 简单实现CustomForkJoinWorkerThreadFactory

   • （科特林）

     //Custom class
     class CustomForkJoinWorkerThreadFactory : ForkJoinPool.ForkJoinWorkerThreadFactory {
       override fun newThread(pool: ForkJoinPool?): ForkJoinWorkerThread {
         return CustomForkJoinWorkerThread(pool)
       }
     }
     // helper class (probably only needed in kotlin)
     class CustomForkJoinWorkerThread(pool: ForkJoinPool?) : ForkJoinWorkerThread(pool)
     

如果您需要有关反射的更多信息以及为什么更改最终字段不好，请参阅此处和此处。简短摘要：由于优化，更新的最终字段可能对其他对象不可见，并且可能会发生其他未知的副作用。

如前所述：这是一个非常肮脏的解决方案。如果您使用此解决方案，可能会出现不必要的副作用。使用这样的反射不是一个好主意。如果您可以使用没有反射的解决方案（并将其作为答案发布在这里！

编辑：单个呼叫的替代方案

就像问题本身所说：如果你只在少数地方遇到这个问题（即修复调用本身没有问题），你可以使用你自己的执行器。从这里复制一个简单的例子：

ExecutorService pool = Executors.newFixedThreadPool(10);
final CompletableFuture<String> future = 
    CompletableFuture.supplyAsync(() -> { /* ... */ }, pool);