kolpakovee Oct 20 at 08:17

Кейс из production: Deadlock в асинхронном коде на Java

Medium

4 min

3.5K

Java * IT systems testing * Website development * High performance * System Analysis and Design *

From sandbox

+10

Comments 12

remindscope Oct 20 at 09:35

С появлением виртуальных потоков я бы добавил, что для IO-bound задач в принципе больше нет необходимости в пуле потоков, будет достаточно Executors.newVitrualThreadPerTaskExecutor()

kolpakovee Oct 20 at 10:00

Валидно, но я не придумал как подружить их с TaskDecorator (так как контекст логирования ThreadLocal и не передается между потоками по умолчанию)

remindscope Oct 20 at 10:05

Можно попробовать использовать InheritableThreadLocal

kolpakovee Oct 20 at 10:11

Рассмотрю это решение

cuba001 Oct 20 at 10:07

Еще бы увидеть код с этой ситуацией.

kolpakovee Oct 20 at 10:09

// Плохая конфигурация (причина deadlock)
ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
executor.setCorePoolSize(1); // Всего ОДИН поток!
executor.initialize();

// Главный поток
CompletableFuture<?> task1 = CompletableFuture.supplyAsync(() -> {
    // Внутри задачи 1...
    CompletableFuture<?> subTask1 = CompletableFuture.supplyAsync(..., executor);
    CompletableFuture<?> subTask2 = CompletableFuture.supplyAsync(..., executor);
    
    // БЛОКИРОВКА! Используем allOf().join() для ожидания всех подзадач
    return CompletableFuture.allOf(subTask1, subTask2).join(); 
}, executor);

CompletableFuture<?> task2 = CompletableFuture.supplyAsync(..., executor);
CompletableFuture.allOf(task1, task2).join(); // Вечное ожидание...

ris58h Oct 20 at 12:27

Странно, что решением выбран костыль с докинуть ~~памя~~ потоков, вместо отказа от блокировок.

kolpakovee Oct 20 at 12:32

Валидно, но пул потоков в любом случае нужно было расширять

Deosis Oct 21 at 05:04

Вместо решения проблемы, её замели под ковер.

kolpakovee Oct 21 at 05:33

В конечном итоге пришли к тому, чтобы не блокировать потоки в дочерних задачах

shtanko-a-o Oct 21 at 05:15

Можно использовать эластичный пул
public ExecutorService myExecutorService() {

BlockingQueue<Runnable> queue = new ArrayBlockingQueue<>(1000); ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(1000, 1000, 60L, TimeUnit.SECONDS, queue, new ThreadPoolExecutor.AbortPolicy()); threadPoolExecutor.allowCoreThreadTimeOut(true);

return threadPoolExecutor;

}

kolpakovee Oct 21 at 05:36

«эластичный» пул с большим числом потоков и очередью не устраняет корневую причину — блокировку рабочего потока из‑за join внутри того же пула, где должны стартовать дочерние задачи, поэтому риск starvation/дедлока остаётся и лишь «маскируется» масштабированием. Решение — не блокировать воркеры: компоновать этапы через thenCompose/thenCombine/allOf и делать единственный join на границе, либо выносить дочерние задачи в отдельный исполнитель или виртуальные потоки для изоляции от блокировок.