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

Обработчики onClose запускаются только при явном закрытии стрима через close() или автоматически внутри конструкции try-with-resources. Завершение терминальной операции само по себе стрим не закрывает, поэтому обработчик может не выполниться.

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

Stream API появился в Java 8 как декларативный механизм обработки последовательностей данных с поддержкой ленивых операций, оптимизаций и параллельного выполнения. При этом стримы могут быть построены поверх ресурсов, требующих освобождения: файлов, сетевых каналов или JDBC-источников.

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

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

Если ресурсный стрим не закрыть явно, зарегистрированный обработчик не гарантированно освободит ресурс. Особенно опасно ошибочно считать, что после collect, count или другой терминальной операции стрим автоматически закрывается.

В результате возможны утечки файловых дескрипторов, незакрытые соединения и исчерпание ограниченного пула ресурсов. Сборщик мусора также не является заменой явному закрытию: момент его запуска не определён, а обработчик onClose не является финализатором.

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

Вызов onClose добавляет обработчик к жизненному циклу стрима и возвращает эквивалентный стрим. Обработчик запускается при вызове close(); если зарегистрировано несколько обработчиков, они выполняются в порядке регистрации.

Терминальная операция завершает вычисление конвейера, но не меняет состояние владения ресурсом. Поэтому ресурсный стрим следует создавать в try-with-resources, который гарантирует вызов close() даже при исключении:

import java.util.stream.Stream;

try (Stream<String> stream = Stream.of("a", "b")
        .onClose(() -> System.out.println("Ресурс освобождён"))) {
    long count = stream.count();
}

После count() блок завершается, и try-with-resources вызывает close(), поэтому сообщение будет напечатано. Без этой конструкции терминальная операция выполнится, но обработчик не обязан запускаться.

Производный стрим сохраняет связь с исходным конвейером: закрытие стрима обычно приводит к выполнению зарегистрированных close-обработчиков этого конвейера. Повторный вызов close() не должен повторно выполнять закрытие уже закрытого стрима.

Обработчик должен быть коротким, предсказуемым и безопасным для повторного обращения к освобождаемому ресурсу. onClose не превращает обычный стрим в владельца произвольного объекта автоматически: вызывающий код всё равно обязан организовать вызов close().

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

Сервис читает строки из файла через поток, регистрирует в onClose закрытие вспомогательного ресурса и выполняет фильтрацию. Вариант без явного закрытия кажется рабочим: строки обрабатываются, а тесты на малом числе файлов проходят. Однако при длительной работе процесса число открытых дескрипторов постепенно растёт.

Первый вариант — надеяться на сборку мусора. Его плюс — отсутствие дополнительного кода, но минусом является недетерминированное освобождение ресурсов и риск исчерпания дескрипторов.

Второй вариант — вызвать close() вручную после терминальной операции. Это работает, но при исключении между началом обработки и вызовом close() ресурс может остаться открытым.

Выбранное решение — try-with-resources. Оно компактно задаёт границу владения ресурсом и вызывает close() как при нормальном завершении, так и при исключении. В результате обработчик onClose срабатывает детерминированно, а ошибка обработки не приводит к утечке.

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

Запускается ли onClose после любой терминальной операции?

Нет. Терминальная операция запускает вычисление конвейера и возвращает результат, но не обязана закрывать стрим. Обработчик будет вызван только при явном close() или при автоматическом закрытии через try-with-resources.

Что произойдёт, если у одного конвейера зарегистрировать несколько обработчиков закрытия?

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

Достаточно ли зарегистрировать освобождение ресурса через onClose, чтобы ресурс всегда был освобождён?

Нет. onClose только регистрирует действие и не запускает его автоматически после терминальной операции. Гарантия появляется лишь тогда, когда код действительно закрывает стрим, предпочтительно через try-with-resources; сам по себе объект Stream не заменяет явное управление ресурсом.