В чём разница между AutoCloseable и Closeable

Основная разница заключается в иерархии, пакете, типе выбрасываемого исключения и области применения: 4. Назначение: AutoCloseable (Java 7) универсален для любых ресурсов (JDBC-...

🟢 Junior Level

Краткий ответ для собеседования (30 секунд)

Основная разница заключается в иерархии, пакете, типе выбрасываемого исключения и области применения:

Иерархия: Closeable является прямым наследником AutoCloseable (Closeable extends AutoCloseable).
Пакет: AutoCloseable находится в java.lang (базовый API ядра), а Closeable — в java.io (потоки ввода-вывода).
Исключение: метод AutoCloseable.close() объявляет throws Exception, тогда как Closeable.close() сужает его до throws IOException.
Назначение: AutoCloseable (Java 7) универсален для любых ресурсов (JDBC-соединения, транзакции, сокеты, пулы потоков), а Closeable (Java 5) исторически проектировался исключительно для потоков ввода-вывода байтов и символов.

Оба интерфейса поддерживаются конструкцией try-with-resources (TWR).

Сравнительная таблица

Критерий	`java.lang.AutoCloseable`	`java.io.Closeable`
Версия Java	Появился в Java 7	Появился в Java 5 (в Java 7 расширен)
Пакет	`java.lang` (не требует `import`)	`java.io` (требует импорта)
Сигнатура `close()`	`void close() throws Exception;`	`void close() throws IOException;`
Иерархия	Базовый интерфейс верхнего уровня	Дочерний интерфейс (`extends AutoCloseable`)
Идемпотентность	Рекомендуется (strongly recommended)	Строго обязательна (mandatory contract)
Область применения	Любые ресурсы (БД, сетевые пулы, локи)	Только структуры I/O (файлы, стримы, каналы)

Иерархия наследования

java.lang.AutoCloseable (Java 7)
    │   void close() throws Exception;
    │
    ├── java.sql.Connection / Statement / ResultSet
    ├── java.util.concurrent.ExecutorService (Java 19+)
    │
    └── java.io.Closeable (Java 5, extends AutoCloseable с Java 7)
            void close() throws IOException;
            │
            ├── java.io.InputStream / OutputStream
            ├── java.io.Reader / Writer
            └── java.nio.channels.Channel

Пример использования обоих интерфейсов в TWR

Оба типа ресурсов взаимозаменяемы в заголовке try-with-resources:

import java.io.FileInputStream;
import java.io.IOException;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class ResourceComparisonExample {
    public static void runDemo() {
        // FileInputStream реализует Closeable (I/O)
        // Connection реализует AutoCloseable (JDBC)
        try (FileInputStream fis = new FileInputStream("app.properties");
             Connection conn = DriverManager.getConnection("jdbc:h2:mem:test")) {
            
            int data = fis.read();
            System.out.println("First byte: " + data);
            System.out.println("Connection valid: " + conn.isValid(2));
            
        } catch (IOException | SQLException e) {
            System.err.println("Resource handling error: " + e.getMessage());
        }
    }
}

🟡 Middle Level

Архитектура обратной совместимости

Когда в Java 7 разрабатывался механизм try-with-resources (Project Coin / JSR 334), требовалось дать возможность закрывать не только файлы и сетевые стримы (java.io), но и базы данных (java.sql), каналы (java.nio) и любые пользовательские ресурсы.

Если бы разработчики завязали оператор try-with-resources на существующий java.io.Closeable:

Возникла бы нежелательная связность между не-I/O модулями и пакетом java.io.
Вся подсистема JDBC была бы вынуждена выбрасывать IOException при закрытии или зависеть от I/O.

Поэтому был создан более общий интерфейс java.lang.AutoCloseable, а существующий java.io.Closeable объявили его наследником:

package java.io;

public interface Closeable extends AutoCloseable {
    @Override
    void close() throws IOException;
}

Благодаря ковариантности сигнатур методов в Java (метод подтипа имеет право декларировать подмножество проверяемых исключений базового метода), Closeable корректно сузил throws Exception до throws IOException. При этом миллионы строк существующего кода Java 5 и 6, использующие Closeable, автоматически получили совместимость с новым синтаксисом try-with-resources без перекомпиляции.

Тонкости контракта: Идемпотентность вызова `close()`

Спецификация Javadoc формулирует требование к идемпотентности для двух интерфейсов с разной степенью жесткости:

Closeable (Строгое требование):

“If the stream is already closed then invoking this method has no effect.” Повторный вызов метода close() у любого класса, реализующего Closeable, не должен делать ничего (no-op) и не должен выбрасывать исключений.
AutoCloseable (Настоятельная рекомендация):

“Note that unlike the close method of Closeable, this close method is not required to be idempotent. In other words, calling this close method more than once may have some visible side effect… However, implementers of this interface are strongly recommended to make their close methods idempotent.”

Почему `AutoCloseable` не требует идемпотентности на 100%?

Некоторые системные ресурсы имеют сложную транзакционную логику. Например:

Транзакционный ресурс, у которого close() выполняет фиксацию (commit) или откат (rollback). Повторная попытка завершить уже завершенную транзакцию может свидетельствовать о нарушении целостности данных, поэтому ресурс может выбросить IllegalStateException.
Конкурентные или распределенные примитивы синхронизации.

Тем не менее, в 99% прикладных классов метод close() следует делать идемпотентным во избежание скрытых ошибок при закрытии цепочек декораторов.

Связь с `Flushable`

Подавляющее большинство реализаций Closeable в java.io одновременно реализуют интерфейс java.io.Flushable:

public class BufferedOutputStream extends FilterOutputStream implements Flushable, Closeable {
    @Override
    public void close() throws IOException {
        try {
            flush(); // 1. Сброс накопленного буфера на диск/в сеть
        } finally {
            super.close(); // 2. Гарантированное закрытие нативного дескриптора
        }
    }
}

Если при выполнении flush() во время вызова close() происходит сетевой сбой или переполнение диска, выбрасывается IOException. Если flush() не обернут в try-finally, сам нативный дескриптор файла рискует остаться незакрытым! Грамотные реализации JDK всегда используют try-finally внутри close().

🔴 Senior Level

Идиоматический выбор: что реализовывать в собственном коде?

Нужно закрывать ресурс?
         │
         ├── Это поток байтов, символов, сокет или канал I/O?
         │         └── ДА  ──> Реализуйте java.io.Closeable (throws IOException)
         │
         └── Это бизнес-сервис, транзакция, контекст или ThreadLocal?
                   └── ДА  ──> Реализуйте java.lang.AutoCloseable
                                 │
                                 ├── Может ли закрытие бросить проверяемое исключение?
                                 │         ├── ДА  ──> Сузьте до конкретного CheckedException
                                 │         └── НЕТ ──> Уберите throws вообще (void close())

Паттерн “No-Throws AutoCloseable” для Scope Guard

Для временной модификации контекста (например, MDC логгера, Security Context, изменения имени потока) создают ресурс без проверяемых исключений. Это избавляет вызывающий код от необходимости писать фиктивные блоки catch:

import org.slf4j.MDC;

public final class MdcScope implements AutoCloseable {
    private final String previousValue;
    private final String key;

    public MdcScope(String key, String value) {
        this.key = key;
        this.previousValue = MDC.get(key);
        MDC.put(key, value);
    }

    // Сигнатура БЕЗ throws: чистый try-with-resources без блока catch
    @Override
    public void close() {
        if (previousValue != null) {
            MDC.put(key, previousValue);
        } else {
            MDC.remove(key);
        }
    }
}

// Использование:
public void processOrder(String orderId) {
    try (var ignored = new MdcScope("orderId", orderId)) {
        // Вся логика внутри логируется с [orderId=12345]
        executeBusinessLogic();
    } // close() вызывается гарантированно, перехват исключений не требуется!
}

Декораторы, каскадное закрытие и Resource Ownership

Паттерн “Декоратор” в java.io (например, BufferedReader(InputStreamReader(FileInputStream))) связывает владение ресурсами. Закрытие внешнего декоратора приводит к каскадному вызову close() на всех вложенных компонентах.

Проблема вторичного закрытия общих ресурсов (Shared Resource Problem)

Если в декоратор передается поток, не принадлежащий этому методу (например, System.in или сокет из внешнего пула), закрытие декоратора закроет разделяемый ресурс для всего приложения:

public void processConsoleInput() {
    // ОШИБКА: Scanner.close() закроет System.in для всей JVM!
    try (Scanner scanner = new Scanner(System.in)) {
        String input = scanner.nextLine();
    }
    // Последующие попытки чтения из System.in приведут к IOException: Stream Closed!
}

Решение: “Uncloseable” обертка

Если поток не должен закрываться декоратором, используют специальный прокси или делегат:

import java.io.FilterInputStream;
import java.io.IOException;
import java.io.InputStream;

public class NonClosingInputStream extends FilterInputStream {
    public NonClosingInputStream(InputStream in) {
        super(in);
    }

    @Override
    public void close() throws IOException {
        // no-op: предотвращаем закрытие подлежащего системного потока
    }
}

Non-blocking I/O и закрытие потоков в состоянии ожидания

В пакете java.nio.channels интерфейс Channel расширяет Closeable. Если один поток заблокирован в операциях чтения/записи на канале (read(), write()), а другой поток вызывает channel.close():

Заблокированный поток немедленно разблокируется и получит исключение java.nio.channels.AsynchronousCloseException.
Если заблокированный поток был прерван (Thread.interrupt()), канал будет немедленно закрыт, а поток получит java.nio.channels.ClosedByInterruptException.

В старом java.io (блокирующие сокеты InputStream.read()) закрытие стрима из другого потока не всегда гарантировало немедленную разблокировку на некоторых операционных системах до появления NIO.

🎯 Шпаргалка для интервью

Вопросы для быстрой проверки

Почему Closeable наследует AutoCloseable, а не наоборот? Ответ: AutoCloseable появился позже (Java 7) как более общая абстракция ядра (java.lang) для любых закрываемых ресурсов с широким контрактом throws Exception. Наследование Closeable extends AutoCloseable позволило всем классам ввода-вывода из Java 5 мгновенно получить совместимость с try-with-resources без поломки старого API.
Почему в Closeable идемпотентность close() строго обязательна, а в AutoCloseable только рекомендована? Ответ: Для потоков ввода-вывода повторный close() однозначно безопасен и должен игнорироваться. Для произвольных ресурсов (транзакции, распределенные блокировки, состояния стейт-машин) повторное закрытие может свидетельствовать о нарушении логики приложения и требовать явного выброса ошибки (например, IllegalStateException).
Что произойдет, если в классе, реализующем AutoCloseable, метод close() выбросит непроверяемое исключение (RuntimeException)? Ответ: Метод завершится аварийно. Если блок try выполнялся без ошибок, это RuntimeException вылетит из try-with-resources. Если же в теле try уже возникло первичное исключение, RuntimeException из close() будет подавлено и прикреплено к первичному через primaryException.addSuppressed(e).
Какой интерфейс следует реализовать для класса, управляющего транзакцией базы данных? Ответ: java.lang.AutoCloseable. При реализации следует сузить выбрасываемое исключение до SQLException (или собственного доменного исключения), либо убрать throws, если метод выполняет тихий rollback при незафиксированной транзакции.

Типичные ошибки и Red Flags

❌ Утверждение, что Closeable бросает RuntimeException: Closeable бросает строго IOException (checked).
❌ Утверждение, что AutoCloseable предназначен только для I/O: Это грубая ошибка архитектурного понимания; AutoCloseable находится в java.lang и предназначен для любых ресурсов.
❌ Закрытие системных потоков (System.in, System.out) через обертки Closeable: Приводит к глобальной недоступности стандартных потоков ввода-вывода в процессе.
❌ Написание throws Exception в собственном классе, реализующем AutoCloseable, без реальной необходимости: Заставляет вызывающий код городить неспецифичные обработчики catch (Exception e).