Завершенный комплект FutureJoinPool Set Loader

Ответ 1

Итак, вот очень грязное решение, которым я не горжусь, и может сломать для вас вещи, если вы согласитесь с ним:

Проблема заключалась в том, что загрузчик классов приложения не использовался для ForkJoinPool.commonPool(). Поскольку настройка commonPool является статической и поэтому во время запуска приложения нет легкой возможности (по крайней мере, насколько мне известно) внести изменения позже. Поэтому нам нужно полагаться на API отражения Java.

1. создать ловушку после успешного запуска вашего приложения

   • в моем случае (среда Spring Boot) это будет ApplicationReadyEvent

   • чтобы прослушать это событие, вам нужен компонент, подобный следующему

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

2. Внутри вашего хука вам нужно установить ForkJoinWorkerThreadFactory commonPool в пользовательскую реализацию (так что эта пользовательская реализация будет использовать загрузчик классов приложения)

   • в Котлине

     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);

Ответ 2

Кажется, что resteasy lib использует потоковый загрузчик классов для загрузки некоторых ресурсов: http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.resteasy/resteasy-client/3.0-beta-1/org/jboss/resteasy/client/jaxrs/ProxyBuilder.java#21.

Когда resteasy попытается загрузить запрошенный класс, он попросит загрузчика классов потока искать его и, если это возможно, загрузить его, когда запрошенный класс находится в пути к классам, невидимом загрузчику классов, операция не выполняется.

И что именно происходит с вашим приложением: ThreadClassLoader попытался загрузить ресурс, расположенный в пути к классам приложений, поскольку ресурсы из этого пути к классам доступны только из AppClassLoader и его дочерних элементов, а затем ThreadClassLoader не удалось загрузить его (ThreadClassLoader не является дочерним элементом AppClassLoader).

Возможное решение может заключаться в том, чтобы переопределить контекст потока ClassLoader вашим приложением ClassLoader: thread.setContextClassLoader(appClass.class.getClassLoader())

Ответ 3

Я столкнулся с чем-то похожим и нашел решение, которое не использует отражение и, кажется, хорошо работает с JDK9-JDK11.

Вот что говорят Javadocs :

Параметры, используемые для создания общего пула, могут контролироваться путем установки следующих системных свойств:

• java.util.concurrent.ForkJoinPool.common.threadFactory - имя класса ForkJoinPool.ForkJoinWorkerThreadFactory. Загрузчик системного класса используется для загрузки этого класса.

Поэтому, если вы развернете свою собственную версию ForkJoinWorkerThreadFactory и установите ее вместо использования правильного ClassLoader с использованием системного свойства, это должно работать.

Вот мой обычай 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 ссылается в первый раз и инициализирует commonPool, контекстный ClassLoader для этого потока является правильным, который вам нужен (и не является загрузчиком класса System).

Вот некоторая справочная информация, которая может помочь:

Потоки общего пула Fork/Join возвращают загрузчик системного класса в качестве загрузчика класса контекста потока.

В Java SE 9 потоки, являющиеся частью общего пула fork/join, всегда возвращают загрузчик системного класса в качестве загрузчика класса контекста потока. В предыдущих выпусках загрузчик класса контекста потока мог быть унаследован от любого потока, вызывающего создание общего потока пула fork/join, например, отправив задачу. Приложение не может надежно зависеть от того, когда или как потоки создаются общим пулом fork/join, и поэтому не может надежно зависеть от пользовательского загрузчика классов, который будет установлен в качестве загрузчика класса контекста потока.

В результате вышеуказанного изменения обратной несовместимости вещи, которые используют ForkJoinPool, который работал в JDK8, могут не работать в JDK9+.