Що таке ключове слово final і як воно допомагає у створенні незмінних класів

Ключове слово final в Java виражає намір незмінності та заборони модифікації. Його дія залежить від контексту застосування:

🟢 Junior Level

30-секундна відповідь

Ключове слово final в Java виражає намір незмінності та заборони модифікації. Його дія залежить від контексту застосування:

final змінна / поле: значення може бути присвоєно рівно один раз. Для примітивних типів (int, double) фіксується значення; для посилальних типів фіксується посилання на об’єкт у купі, але не стан самого об’єкта.
final метод: забороняє перевизначення (overriding) методу в класах-нащадках.
final клас: повністю забороняє спадкування від цього класу (створення підкласів через extends).

У створенні незмінних класів ключове слово final відіграє подвійну фундаментальну роль:

final у класу: гарантує, що сторонній код не створить мутабельний підклас із сетерами та перевизначеними методами.
final у полів: гарантує, що стан об’єкта зафіксовано під час конструювання, і запускає гарантію безпечної публікації (Safe Publication) згідно з моделлю пам’яті Java (JMM §17.5).

Наочний приклад

// 1. final клас: заборонено розширення
public final class GeoPoint {
    // 2. final поля: ініціалізуються один раз у конструкторі
    private final double latitude;
    private final double longitude;

    public GeoPoint(double latitude, double longitude) {
        this.latitude = latitude;
        this.longitude = longitude;
    }

    public double getLatitude() {
        return latitude;
    }

    public double getLongitude() {
        return longitude;
    }
}

🟡 Middle Level

1. Blank Final поля та правила ініціалізації

Поле, оголошене як final, не обов’язково ініціалізувати в місці оголошення. Таке поле називається blank final:

public final class OrderItem {
    private final String sku;          // Blank final
    private final int quantity;        // Blank final
    private final long createdAt = System.currentTimeMillis(); // Ініціалізація на місці

    public OrderItem(String sku, int quantity) {
        // Зобов'язані проініціалізувати всі blank final поля в КОЖНОМУ конструкторі
        this.sku = Objects.requireNonNull(sku);
        this.quantity = quantity;
    }
}

Якщо хоча б один конструктор не присвоїть значення blank final полю за всіма гілками виконання, компілятор javac видасть помилку: variable sku might not have been initialized.

2. Ключова пастка: `final`-посилання ≠ Незмінний об’єкт

Модифікатор final захищає лише саме посилання, але ніяк не захищає нутрощі об’єкта, на який воно вказує:

public final class MutableStateTrap {
    // Посилання list не може вказувати на інший ArrayList...
    private final List<String> list = new ArrayList<>();

    public void mutate() {
        // ...але внутрішній стан самого списку спокійно МУТУЄ!
        list.add("Danger!"); 
        list.clear();
    }
}

Для забезпечення справжньої незмінності посилальні поля зобов’язані вказувати на незмінні об’єкти або захищатися через глибоке копіювання (Defensive Copy) та повернення unmodifiable-колекцій (List.copyOf()).

3. Заборона поліморфного забруднення стану

Навіщо потрібен final на рівні класу? Якби клас GeoPoint не був final, зловмисник або розробник міг би написати:

public class MutableGeoPoint extends GeoPoint {
    private double mutableLatitude;

    public MutableGeoPoint(double lat, double lon) {
        super(lat, lon);
        this.mutableLatitude = lat;
    }

    public void setLatitude(double newLat) {
        this.mutableLatitude = newLat;
    }

    @Override
    public double getLatitude() {
        return this.mutableLatitude; // Порушення контракту незмінності базового класу!
    }
}

Клієнтський код, який очікує безпечний GeoPoint, отримає MutableGeoPoint, чий стан змінюється в паралельному потоці. Оголошення класу як final повністю запобігає цій вразливості.

🔴 Senior Level

JMM §17.5: Семантика `final` полів та Freeze Action

Ключове слово final на полях забезпечує критичну багатопотокову гарантію — Safe Publication:

При виході з конструктора об’єкта з final-полями JVM виконує спеціальну дію Freeze Action.
JIT-компілятор вставляє бар’єр пам’яті StoreStore (наприклад, інструкція DMB ISHST на ARM64 або бар’єр компілятора на x86).
Цей бар’єр гарантує:
- Усі операції запису у final-поля скидаються зі Store Buffer у кеш L1/L2 процесора до того, як посилання на новий об’єкт стане доступним в оперативній пам’яті.
- Будь-який потік, що прочитав посилання на об’єкт, гарантовано побачить проініціалізовані значення його final-полів без необхідності оголошувати посилання як volatile або обрамляти читання блоками synchronized.

Оптимізації HotSpot JIT (C2 Compiler)

JIT-компілятор HotSpot поводиться з final полями інакше, ніж зі звичайними полями:

Compile-Time Constant Inlining: Якщо поле оголошено як static final int MAX = 100;, компілятор зберігає його в атрибуті байткоду ConstantValue. Значення 100 вшивається безпосередньо в опкоди машинних інструкцій у місцях викликів, оминаючи читання з купи.
Trust Final Fields: Під час оптимізації нестатичних полів C2-компілятор покладається на те, що значення final поля незмінне в часі. Це дозволяє:
- Виносити читання поля за межі циклів (Loop Invariant Hoisting).
- Схлопувати повторювані перевірки (Common Subexpression Elimination).
- Усувати невикористовуваний код (Dead Code Elimination).

Злам `final` через Reflection та захист JEP 403 (Java 17+)

Історично рефлексія дозволяла модифікувати final поля:

Field f = GeoPoint.class.getDeclaredField("latitude");
f.setAccessible(true);
f.set(point, 99.99); // Працювало в Java 8!

Проте в сучасній Java:

JEP 403 (Strongly Encapsulate JDK Internals): Спроба викликати setAccessible(true) на final-полях внутрішніх класів JDK (java.base) призводить до фатального InaccessibleObjectException.
Ефект JIT Inlining: Навіть для користувацьких класів, якщо C2-компілятор уже заінлайнив читання final-поля як константу, фізичний перезапис значення в пам’яті через рефлексію не вплине на результат роботи скомпільованого методу — метод продовжить повертати вихідне значення!

4 Tricky Questions

1. У чому різниця між константою часу компіляції (`static final primitive/String`) та звичайним runtime `final` полем у байткоді? До якої проблеми це призводить при роздільній компіляції бібліотек?

Відповідь: Поля виду public static final int TIMEOUT = 5000; або рядкові літерали є константами часу компіляції (Compile-Time Constants).

У байткоді класу-власника вони позначаються атрибутом ConstantValue.
Під час компіляції стороннього класу-клієнта, що використовує MyService.TIMEOUT, компілятор javac напряму підставляє число 5000 (байткод-інструкція sipush 5000) прямо в байткод класу-клієнта, повністю видаляючи звернення getstatic MyService.TIMEOUT.
Проблема версіонування: Якщо ви зміните константу в бібліотеці на 10000, перекомпілюєте тільки бібліотечний jar-файл і покладете його в classpath, викликаючий код продовжить використовувати старе значення 5000, доки клас-клієнт не буде примусово перекомпільовано!

2. Чи можна прочитати значення `final`-поля до того, як воно було ініціалізовано в конструкторі? Яке значення повернеться?

Відповідь: Так, це можливо при поліморфному виклику перевизначуваного методу з конструктора базового класу:

class Base {
    public Base() {
        print(); // Виклик перевизначуваного методу з конструктора!
    }
    public void print() {}
}

class Child extends Base {
    private final int x = 42;

    @Override
    public void print() {
        System.out.println("x = " + x); // Виведе "x = 0"!
    }
}

Чому так відбувається: Конструктор Base виконується до ініціалізації полів Child. У момент виклику методу print() пам’ять під об’єкт Child уже виділена, але його поле x ще містить значення за замовчуванням для типу int — 0. Це класичний антипатерн: виклик non-final методів із конструктора заборонений правилами безпечного проєктування.

3. Чому спроба змінити `private final` поле через рефлексію в користувацькому класі може не змінити значення, що повертається в продакшені під C2 JIT?

Відповідь: Коли метод (наприклад, гетер getLatitude()) компілюється високорівневим JIT-компілятором C2, компілятор виконує агресивну оптимізацію: він бачить, що клас і поле позначені final. Якщо метод часто викликається, C2 виконує inlining значення або кешує його в регістрі процесора, покладаючись на специфікацію мови, що final-поле ніколи не мутує. Коли рефлексія виконує field.set(point, 99.0), запис фізично відбувається в комірку оперативної пам’яті об’єкта в купі. Проте скомпільований код методу продовжує читати константу з машинних інструкцій або процесорного регістра, ігноруючи зміни в пам’яті купи. У результаті програма демонструє неконсистентну поведінку: пряме читання через рефлексію показує нове значення, а виклик гетера — старе!

4. У чому відмінність модифікатора `final` у класу від закриття всіх його конструкторів (`private`)?

Відповідь: Обидва підходи роблять клас фактично нерозширюваним ззовні пакета, але мають різні властивості:

final class: абсолютно забороняє спадкування всюди, включаючи той самий .java файл і той самий пакет. Компілятор жорстко забороняє extends.
private конструктори: забороняють створення підкласів зовнішнім кодом, але дозволяють створення підкласів у вигляді вкладених статичних класів (static nested classes) всередині того самого файлу! Це дозволяє реалізувати патерн Algebraic Data Types (до появи sealed classes), де всі допустимі реалізації відомі заздалегідь та інкапсульовані всередині базового класу.

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

3 контексти ключового слова final

Червоні прапорці на співбесіді (Чого говорити не можна)

❌ «Оголошення посилання як final List<String> робить список незмінним» — груба помилка: final фіксує посилання, елементи списку можна додавати та видаляти.
❌ «Для незмінності достатньо зробити поля final, клас final робити необов’язково» — підклас може перевизначити гетери і зламати незмінність.
❌ «Final поля завжди можна безпечно змінювати через рефлексію» — у Java 17+ це заблоковано для java.base, а для власного коду C2 JIT заінлайнить старе значення.
❌ «Константа public static final підтягнеться клієнтами автоматично при заміні JAR-файлу» — примітивні та String константи вшиваються в байткод викликаючого коду під час компіляції.