---

🟢 Junior Level

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

java.lang.AutoCloseable — це базовий інтерфейс Java (впроваджений у Java 7), що містить єдиний метод void close() throws Exception. Він слугує контрактом для будь-яких ресурсів, які утримують системні або логічні дескриптори (файли, сокети, з’єднання з базою даних, транзакції) та потребують детермінованого вивільнення. Будь-який клас, що реалізує AutoCloseable, може використовуватися в заголовку оператора try-with-resources (TWR), де середовище виконання гарантує автоматичний виклик методу close() при виході з блоку, незалежно від виникнення помилок.

---

Сигнатура інтерфейсу

Інтерфейс розташований у фундаментальному пакеті java.lang, тому не потребує імпорту:

package java.lang;

public interface AutoCloseable {
    void close() throws Exception;
}

---

Як використовувати з try-with-resources

До появи Java 7 розробники вручну писали громіздкі блоки try-finally, у яких перевіряли посилання на null та вкладено перехоплювали винятки. З AutoCloseable закриття автоматизоване:

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;

public class AutoCloseableExample {
    public static void readFirstLine(String path) throws IOException {
        // BufferedReader реалізує AutoCloseable (через Reader та Closeable)
        try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
            String line = reader.readLine();
            System.out.println("First line: " + line);
        } // reader.close() викликається АВТОМАТИЧНО при виході з дужок
    }
}

---

Які класи реалізують AutoCloseable

У стандартній бібліотеці JDK цей інтерфейс реалізують сотні класів:

• Введення-виведення (I/O) та потоки даних: InputStream, OutputStream, Reader, Writer, RandomAccessFile.
• Робота з базами даних (JDBC): Connection, Statement, PreparedStatement, ResultSet.
• Мережева взаємодія: Socket, ServerSocket, DatagramSocket.
• Утиліти та багатопоточність: Scanner, Formatter, ForkJoinPool, ExecutorService (починаючи з Java 19).

---

🟡 Middle Level

Архітектурне рішення: чому java.lang, а не java.io?

До Java 7 існував інтерфейс java.io.Closeable (введений у Java 5). Проте архітектори JDK 7 винесли AutoCloseable на рівень ядра в java.lang з двох причин:

1. Зменшення зв’язності (Decoupling): Ресурсами є не лише структури введення-виведення. З’єднання із СУБД (java.sql), графічні контексти (java.awt), замки чи пули потоків не повинні залежати від пакета java.io.
2. Доступність на рівні мовних примітивів: Розташований у java.lang, інтерфейс став фундаментальним будівельним блоком мови (як Object, Runnable, Iterable), доступним без імпортів у будь-якій точці програми.

---

Правила реалізації методу close()

1. Звуження типу винятку (Exception Narrowing)

Хоча в інтерфейсі оголошено throws Exception, клас-реалізація повинен звужувати сигнатуру до конкретного типу перевірюваного винятку або взагалі прибирати секцію throws, якщо операція закриття гарантовано безвідмовна:

// Погано: змушує клієнтський код ловити універсальний Exception
public class BadResource implements AutoCloseable {
    @Override
    public void close() throws Exception {
        // ...
    }
}

// Чудово: звужуємо до IOException
public class GoodIoResource implements AutoCloseable {
    @Override
    public void close() throws IOException {
        // ...
    }
}

// Чудово: якщо вивільнення не кидає перевірюваних винятків
public class SafeInMemoryResource implements AutoCloseable {
    @Override
    public void close() {
        // Звільнення структур у пам'яті, throws відсутній
    }
}

2. Рекомендація ідемпотентності (Idempotency)

У Javadoc AutoCloseable наполегливо рекомендується робити метод close() ідемпотентним: повторні виклики close() не повинні призводити до помилок чи повторного вивільнення дескрипторів:

public class IdempotentResource implements AutoCloseable {
    private boolean closed = false;

    @Override
    public void close() {
        if (closed) {
            return; // no-op при повторному виклику
        }
        closed = true;
        // реальне звільнення ресурсів
    }
}

3. Безпечне композитне закриття

Якщо ресурс інкапсулює кілька вкладених підресурсів, збій закриття першого не повинен блокувати закриття решти:

public class CompositeResource implements AutoCloseable {
    private final AutoCloseable subResource1;
    private final AutoCloseable subResource2;

    public CompositeResource(AutoCloseable r1, AutoCloseable r2) {
        this.subResource1 = r1;
        this.subResource2 = r2;
    }

    @Override
    public void close() throws Exception {
        Exception primaryException = null;
        try {
            subResource1.close();
        } catch (Exception e) {
            primaryException = e;
        }

        try {
            subResource2.close();
        } catch (Exception e) {
            if (primaryException != null) {
                primaryException.addSuppressed(e);
            } else {
                primaryException = e;
            }
        }

        if (primaryException != null) {
            throw primaryException;
        }
    }
}

---

Garbage Collector та нативні дескриптори

Збирач сміття (GC) керує виключно купою Java (JVM Heap). Коли Java-об’єкт відкриває файл або TCP-сокет, операційна система виділяє числовий файловий дескриптор (file descriptor, FD) у таблиці процесів ядра ОС.

Якщо об’єкт втрачає сильні посилання, але close() не був викликаний:

1. GC вивільнить пам’ять під Java-об’єкт у купі.
2. Дескриптор у ядрі ОС залишиться відкритим.
3. При вичерпанні ліміту дескрипторів (на Linux: ulimit -n, системні ліміти sysctl fs.file-max) застосунок впаде з фатальною помилкою IOException: Too many open files.

Механізм	Час спрацьовування	Детермінованість	Роль в архітектурі
try-with-resources (AutoCloseable)	Одразу при виході з блоку	100% синхронно та гарантовано	Основний стандарт для всіх критичних ресурсів
java.lang.ref.Cleaner (Java 9+)	Фоновий потік очищення після виявлення GC	Недетерміновано (може спрацювати через хвилини/години)	Страхувальна сітка (fallback) на випадок помилки програміста
finalize() (Java 1.0–8)	Непередбачувано перед збиранням GC	Не гарантовано, сповільнює GC	Deprecated з Java 9, видалений/заборонений у сучасних версіях

---

🔴 Senior Level

Under the Hood: генерація байткоду та пригнічені винятки (Suppressed Exceptions)

Під час компіляції конструкції try-with-resources компілятор javac розгортає її в еквівалент try-catch-finally з обробкою пригнічених винятків. Якщо виняток виникає і в тілі try, і в методі close(), виняток із тіла вважається первинним (primary), а виняток із close() прикріплюється до нього через метод Throwable.addSuppressed(Throwable suppressed):

// Вихідний код:
try (Resource res = new Resource()) {
    res.doWork();
}

// Приблизний скомпільований низькорівневий байткод:
Resource res = new Resource();
Throwable primaryExc = null;
try {
    res.doWork();
} catch (Throwable t) {
    primaryExc = t;
    throw t;
} finally {
    if (res != null) {
        if (primaryExc != null) {
            try {
                res.close();
            } catch (Throwable closeExc) {
                primaryExc.addSuppressed(closeExc); // Помилка з close() не затирає робочу аварію!
            }
        } else {
            res.close();
        }
    }
}

---

Багатопотоковий close(): атомарність та захист від State Corruption

У конкурентних системах один і той самий розділюваний ресурс може закриватися паралельними потоками (наприклад, потік-воркер завершує обробку, а фоновий потік моніторингу закриває ресурс за таймаутом). Звичайний прапорець boolean closed призводить до стану гонки (race condition) та потенційного подвійного вивільнення дескриптора на рівні драйвера C/C++ (double free / memory corruption).

Коректна реалізація використовує AtomicBoolean:

import java.util.concurrent.atomic.AtomicBoolean;

public class ThreadSafeResource implements AutoCloseable {
    private final AtomicBoolean isClosed = new AtomicBoolean(false);
    private final long nativeDescriptor;

    public ThreadSafeResource(long descriptor) {
        this.nativeDescriptor = descriptor;
    }

    public void executeOperation() {
        if (isClosed.get()) {
            throw new IllegalStateException("Resource is already closed");
        }
        // Виконання операції з нативним дескриптором
    }

    @Override
    public void close() {
        // CAS гарантує, що реальне закриття виконається суворо один раз рівно одним потоком
        if (isClosed.compareAndSet(false, true)) {
            releaseNativeHandle(nativeDescriptor);
        }
    }

    private void releaseNativeHandle(long handle) {
        // Нативний системний виклик закриття дескриптора (наприклад, close(fd))
    }
}

---

Пастка витоку в конструкторі (Constructor Leak Anti-Pattern)

Якщо конструктор ресурсу відкриває нативний дескриптор, а потім викидає виняток (наприклад, під час валідації параметрів чи збою подальшої ініціалізації), посилання на об’єкт не повертається викликаючому коду. Відповідно, try-with-resources не зможе викликати close(), і нативний ресурс назавжди витече в ОС.

// ❌ НЕБЕЗПЕЧНО: конструктор захоплює ресурс, але падає до завершення
public class RiskyResource implements AutoCloseable {
    private final long handle;

    public RiskyResource(String path, int bufferSize) {
        this.handle = openNativeFile(path); // Ресурс виділено в ОС
        if (bufferSize <= 0) {
            // Виняток! Посилання не створено, TWR не викличе close(), handle витік!
            throw new IllegalArgumentException("Invalid buffer size");
        }
    }

    @Override
    public void close() {
        closeNativeFile(handle);
    }
    
    private static native long openNativeFile(String p);
    private static native void closeNativeFile(long h);
}

Ідіоматичне рішення: Безпечна ініціалізація

1. Легковажний конструктор без side-effects.
2. Відкриття ресурсу всередині статичного фабричного методу:

public class SafeResource implements AutoCloseable {
    private final long handle;

    private SafeResource(long handle) {
        this.handle = handle;
    }

    public static SafeResource open(String path, int bufferSize) {
        if (bufferSize <= 0) {
            throw new IllegalArgumentException("Invalid buffer size");
        }
        long h = openNativeFile(path);
        return new SafeResource(h);
    }

    @Override
    public void close() {
        closeNativeFile(handle);
    }

    private static native long openNativeFile(String p);
    private static native void closeNativeFile(long h);
}

---

Ідіоматична інтеграція з java.lang.ref.Cleaner (Java 9+)

Для максимальної надійності бібліотечного коду AutoCloseable комбінують із Cleaner. Критична вимога: лямбда або Runnable очищення не повинні посилатися на сам екземпляр ресурсу, інакше об’єкт ніколи не буде зібраний GC через сильну циклічну залежність:

import java.lang.ref.Cleaner;

public class NativeBuffer implements AutoCloseable {
    private static final Cleaner CLEANER = Cleaner.create();

    // 1. Статичний клас стану - НЕ утримує прихованого посилання на NativeBuffer (this)
    private static final class State implements Runnable {
        private long nativeAddress;

        State(long address) {
            this.nativeAddress = address;
        }

        @Override
        public void run() {
            if (nativeAddress != 0) {
                freeMemory(nativeAddress);
                nativeAddress = 0;
            }
        }

        private static native void freeMemory(long address);
    }

    private final State state;
    private final Cleaner.Cleanable cleanable;

    public NativeBuffer(long size) {
        long address = allocateMemory(size);
        this.state = new State(address);
        // Реєструємо об'єкт у Cleaner
        this.cleanable = CLEANER.register(this, state);
    }

    @Override
    public void close() {
        // Детерміноване закриття: при виклику clean() Runnable виконується негайно
        // та знімається з черги Cleaner
        cleanable.clean();
    }

    private static native long allocateMemory(long size);
}

---

🎯 Шпаргалка для інтерв’ю

Питання для швидкої перевірки

1. Чому в сигнатурі AutoCloseable.close() оголошено throws Exception, а не IOException? Відповідь: Щоб інтерфейс був універсальним для будь-яких систем (SQL, розподілені транзакції, пули потоків, мережеві протоколи), а не лише для файлового I/O. Під час реалізації рекомендується звужувати виняток до конкретного доменного типу або прибирати його взагалі.
2. Чи зобов’язаний close() в AutoCloseable бути суворо ідемпотентним? Що станеться при повторному виклику? Відповідь: Javadoc наполегливо рекомендує робити метод ідемпотентним (повторні виклики мають бути no-op). Проте специфікація допускає виняток, якщо клас явно документує заборону повторного виклику (наприклад, викидає IllegalStateException).
3. Що станеться, якщо в заголовку try (R1 r1 = new R1(); R2 r2 = new R2()) конструктор R2 викине виняток? Відповідь: Ресурс r1 був успішно ініціалізований, тому середовище виконання гарантовано викличе r1.close(). Конструктор R2 не завершився, тому посилання r2 не створено, і його метод close() викликаний не буде.
4. Чому в реалізації Cleaner для AutoCloseable дія очищення обов’язково виноситься в статичний клас? Відповідь: Нестатичний внутрішній клас або нестатична лямбда неявно захоплюють посилання this на об’єкт, що очищується. Це створює сильне циклічне посилання між об’єктом і механізмом Cleaner, що назавжди блокує збирання об’єкта збирачем сміття (GC).

Типові помилки та Red Flags

• ❌ Твердження, що Garbage Collector автоматично вивільнить сокети та файли: GC вивільняє виключно пам’ять у купі Java, нативні дескриптори ОС залишаються відкритими до перезапуску процесу.
• ❌ Залишення throws Exception у сигнатурі close() прикладного класу: Змушує клієнтський код огортати виклики в універсальний catch (Exception e), маскуючи runtime-помилки.
• ❌ Викидання неперевірюваних винятків із методу close(): Непередбачений збій у close() може замаскувати первинний бізнес-виняток, що виник у блоці try.
• ❌ Спроба використовувати неідемпотентний close() у каскадних ресурсах: Декоратори (на кшталт BufferedInputStream) під час закриття каскадно закривають внутрішній потік; якщо він неідемпотентний, виникає повторна помилка.

Пов’язані теми

• В чому різниця між AutoCloseable та Closeable
• Що таке try-with-resources
• Які вимоги до ресурсів в try-with-resources
• Що таке suppressed винятки
• Що станеться, якщо виняток виникне ще й в блоці finally