Краткий ответ

После shutdown() исполнитель перестаёт принимать новые задачи, но продолжает выполнять ранее принятые задачи. Метод не прерывает уже работающие задачи и не гарантирует немедленное освобождение ресурсов: для ожидания завершения используют awaitTermination(), а для попытки прерывания — shutdownNow().

Исторический контекст

ExecutorService отделяет отправку задач от управления потоками. Такой подход появился как часть модели пулов потоков: приложение не обязано вручную создавать и координировать отдельный поток для каждой задачи.

Разделение состояний позволяет корректно завершать приложение. Иначе рабочие потоки могли бы продолжать удерживать ресурсы и препятствовать завершению процесса даже после того, как основной код закончил работу.

Постановка проблемы

Вызов shutdown() переводит исполнитель в состояние завершения. Новые задачи после этого отклоняются обычно с помощью RejectedExecutionException, а задачи, уже принятые исполнителем, остаются в очереди или продолжают выполняться.

Ошибочно считать shutdown() командой немедленной остановки. Если приложение сразу завершает поток, вызвавший shutdown, это не означает, что все задачи уже закончились; если не дождаться завершения, можно преждевременно закрыть внешние ресурсы или потерять результаты.

Подробное решение

Логика жизненного цикла такова:

до shutdown() исполнитель принимает новые задачи;
после shutdown() новые задачи не принимаются, но ранее принятые обрабатываются;
после завершения всех принятых задач исполнитель переходит в состояние terminated;
awaitTermination() ожидает этот переход ограниченное время;
shutdownNow() пытается остановить работу: ожидающие задачи возвращаются вызывающему коду, а работающим потокам отправляется запрос прерывания.

Прерывание не является принудительным убийством потока. Оно устанавливает флаг прерывания или вызывает реакцию у блокирующих операций; задача должна корректно обрабатывать этот сигнал и завершаться сама. Код, игнорирующий прерывание или бесконечно выполняющийся без проверок, может продолжить работу даже после shutdownNow().

Обычный шаблон завершения сначала вызывает shutdown(), затем ждёт ограниченное время. Если задачи не завершились, приложение может перейти к shutdownNow(), снова дождаться завершения и восстановить флаг прерывания у текущего потока, если ожидание было прервано.

ExecutorService pool = Executors.newFixedThreadPool(4);
try {
    submitTasks(pool);
} finally {
    pool.shutdown();
    try {
        if (!pool.awaitTermination(30, TimeUnit.SECONDS)) {
            pool.shutdownNow();
        }
    } catch (InterruptedException e) {
        pool.shutdownNow();
        Thread.currentThread().interrupt();
    }
}

Выбор между мягким и жёстким завершением — компромисс. shutdown() сохраняет принятые задачи, но может ждать долго; shutdownNow() быстрее инициирует остановку, однако результаты задач могут быть потеряны, а корректность зависит от обработки прерываний.

Ситуация из практики

Сервис обрабатывает входящие сообщения пулом потоков и при остановке приложения вызывает только shutdownNow(). Часть сообщений уже находится в очереди, поэтому они возвращаются вызывающему коду и не получают результата; часть текущих обработчиков игнорирует прерывание во время вычислений.

Рассматривались два варианта. Немедленный shutdownNow() сокращает время остановки, но повышает риск потери сообщений и оставляет некооперативные задачи работающими. Только shutdown() сохраняет принятые задачи, однако может задержать остановку из-за зависшей внешней системы.

Выбран двухэтапный вариант: сначала shutdown() и ожидание ограниченного времени, затем shutdownNow() с сохранением списка невыполненных задач для повторной постановки. Обработчики отдельно научили реагировать на прерывание и безопасно фиксировать промежуточное состояние; в результате штатная остановка стала предсказуемой, а незавершённые сообщения перестали теряться.

Что кандидаты часто упускают

Означает ли успешный возврат из shutdown(), что все задачи завершены?

Нет. Метод лишь инициирует переход к завершению и перестаёт принимать новые задачи. Для проверки фактического завершения используют isTerminated() после ожидания или awaitTermination().

Можно ли отправить задачу между проверкой состояния и вызовом execute()?

Нельзя строить корректность на раздельной проверке isShutdown() и последующей отправке. Между этими действиями другой поток может вызвать завершение, поэтому задача всё равно должна обрабатываться через контракт отправки и возможное отклонение. Сам исполнитель синхронизирует переходы состояний, но не устраняет необходимость обработать RejectedExecutionException.

Что происходит с задачами, переданными через submit(), если их Future отменили?

Отмена Future пытается отменить выполнение задачи. Если задача ещё ждёт в очереди, она обычно не будет выполнена; если уже выполняется, при отмене с признаком прерывания рабочему потоку отправляется запрос прерывания. Гарантия завершения зависит от самой задачи: она должна реагировать на прерывание, а вызов get() после отмены сообщит об отмене через CancellationException.