Что такое ExecutorService в Java и как им правильно пользоваться?

Э, слушай, давай я тебе про этот ваш ExecutorService расскажу, а то смотрю, народ путается в этих пулах, как в трёх соснах, блядь. Это ж просто механизм, чтобы не городить свои потоки на коленке, а пользоваться готовым, как из пакета.

Представь, что у тебя есть куча дел, а ты — царь и бог. Ты не будешь же сам пол мыть, блядь. Ты нанимаешь работников — это потоки. А ExecutorService — это твой прораб, который этих работников нанимает, в жопу пинает и задачи им раздаёт. Всё, сука, просто!

Вот смотри, какие у прораба кнопки есть:

• execute(Runnable task) — это типа: «Вася, иди подмети двор». Послал и забыл, хуй узнаешь, подмёл он или нет.
• submit(Callable<T> task) — а это уже: «Вася, сходи в магазин, купи водки и чек принеси». Ты ему даёшь Future — это как расписка, что водка будет. Потом по этой расписке можешь прийти и спросить: «Ну что, Вася, водка-то есть?» Или даже встать над душой с таймаутом: «Давай, блядь, за две секунды чек показывай!».
• invokeAll(...) — это когда посылаешь сразу бригаду Васей на разные дела и стоишь, пока ВСЕ не отчитаются. Унылое ожидание, пиздец.
• invokeAny(...) — а это хитро, ёпта! Послал десять Васей в десять магазинов за водкой. Кто первый принёс — того и чек принимаешь, остальных посылаешь нахуй, пусть водку себе оставляют.

А чтобы прораба нанять, есть контора готовая — Executors. Там тебе на выбор:

// 1. Бригада фиксированная. 10 человек, ни больше, ни меньше.
ExecutorService fixedPool = Executors.newFixedThreadPool(10);

// 2. Бригада временщиков. Задача есть — наняли человека. Задачи нет — «спасибо, свободен».
ExecutorService cachedPool = Executors.newCachedThreadPool();

// 3. Один универсальный солдат. Всё делает по очереди, зато без гонки.
ExecutorService singleThread = Executors.newSingleThreadExecutor();

// 4. Бригада с будильником. «Через 5 секунд начинаем», «каждые 2 секунды долбим».
ScheduledExecutorService scheduledPool = Executors.newScheduledThreadPool(4);
scheduledPool.schedule(() -> System.out.println("Запуск через 5 сек"), 5, TimeUnit.SECONDS);

А теперь, самое важное, блядь! Этого прораба НАДО УВОЛЬНЯТЬ, когда работа закончена. А то он потоки держит, как дурак, и память жрёт!

Сейчас (Java 19+) модно так делать — он сам закроется:

try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<Integer> future = executor.submit(() -> {
        Thread.sleep(1000); // Симулируем работу
        return 42; // Ответ на главный вопрос
    });
    Integer result = future.get(2, TimeUnit.SECONDS); // Ждём, но не долго, блядь
    System.out.println("Результат: " + result);
} catch (TimeoutException e) {
    System.err.println("Задача зависла, пошла нахуй.");
}

А если ты старовер, то вот тебе классический обряд завершения, чтоб ни один поток не остался висеть:

ExecutorService executor = Executors.newFixedThreadPool(4);
try {
    // Кидаешь задачи...
} finally {
    executor.shutdown(); // Говоришь: «Ребят, новых дел не даю, доделывайте что есть».
    try {
        // Ждёшь час, пока доделают
        if (!executor.awaitTermination(1, TimeUnit.HOURS)) {
            executor.shutdownNow(); // Не доделали? ВСЕМ УВОЛЬНЕНИЕ, НАХУЙ!
        }
    } catch (InterruptedException e) {
        executor.shutdownNow();
        Thread.currentThread().interrupt(); // Восстанавливаешь статус, а то затрёшь
    }
}

Если же ты совсем технарь и хочешь всё по полочкам, можешь собрать своего мега-прораба — ThreadPoolExecutor:

// Тут ты сам решаешь, сколько Васей в бригаде, какую им очередь задач дать и что делать, если все сдохли.
int corePoolSize = 5;    // Постоянный костяк
int maxPoolSize = 20;    // Максимум наёмников в аврал
long keepAliveTime = 60L; // Сколько лишние наёмники ждут работы, прежде чем сваливать
BlockingQueue<Runnable> workQueue = new LinkedBlockingQueue<>(100); // Очередь из 100 поручений
RejectedExecutionHandler handler = new ThreadPoolExecutor.CallerRunsPolicy(); // Что делать при полной очереди

ExecutorService customPool = new ThreadPoolExecutor(
    corePoolSize, maxPoolSize, keepAliveTime, TimeUnit.SECONDS, workQueue, handler
);

Про политики при переполнении (RejectedExecutionHandler): Это что делать, когда и очередь из 100 задач забита, и все 20 Васей заняты, а ты пытаешься запихнуть 101-ю задачу.

• AbortPolicy (стандартная): Выбросит тебе в рожу RejectedExecutionException. «Сам дурак, блядь».
• CallerRunsPolicy (по-человечески): Задачу выполнит тот поток, который её пытался запихнуть. То есть ты сам, царь, идёшь пол мыть. Справедливо, ёпта.
• DiscardPolicy (по-тихому): Просто выкидывает задачу в никуда. «Не было — и хуй с ним».
• DiscardOldestPolicy (беспринципно): Выкидывает самую старую задачу из очереди и пихает на её место новую. «Извини, старик, твоё время вышло».

Итоговые мудрости, блядь:

1. ЗАКРЫВАЙ пулы. Это не мусорка, чтоб их не чистить.
2. Используй submit() с Future, если тебе важен результат или исключение. Иначе потом будешь гадать, почему всё упало, а в логах нихуя.
3. Размер пула — это святое. Для задач, где CPU пашет (типа вычислений) — пул размером с количество ядер. Для задач, где ждёшь ответа от сети/БД (I/O-bound) — можно больше, чтоб не простаивать.
4. Не игнорируй RejectedExecutionException. Это крик системы: «Ёбаный насос, я не справляюсь!».
5. Для сложных сценариев, где одна задача запускает другую, глянь в сторону CompletableFuture. Это уже высший пилотаж, но и пиздеца там может быть овердохуища.

Вот и вся магия, сука. Не так страшен чёрт, как его малюют. Главное — понять, что это просто надстройка, чтобы твои потоки не болтались без дела как пизда в проруби.