Стратегічний дизайн виключень

Вступ

Виключення у Java — безумовно корисний механізм, однак їхнє необережне використання може суттєво знизити продуктивність системи, особливо в ключових ділянках коду або високонавантажених фрагментах логіки.

Ці ключові ділянки коду та фрагменти логіки:

• Виконуються з високою частотою (high-frequency execution path);

• Мають прямий вплив на загальну продуктивність системи;

• Реалізують основні бізнес-сценарії;

• Потребують мінімальних затримок під час виконання (latency-sensitive).

Розуміння вартості виключень

Коли у Java створюється виключення, JVM виконує декілька ресурсоємних операцій:

1. Збирає стек-трейс (найдорожча операція)

2. Ініціалізує об'єкт виключення

3. Шукає відповідний обробник у стеку виклику

4. Виконує розгортання стеку (stack unwinding)

У найбільш навантажених фрагментах логіки ці операції можуть призвести до значного зниження пропускної здатності (throughput) і збільшення затримки (latency).

Техніки оптимізації

Уникнення створення стек-трейсу

Для внутрішніх виключень, які не потребують повного стек-трейсу:

public class LightweightException extends RuntimeException {
    public LightweightException(String message) {
        super(message, null, false, false);
    }
}

Конструктор RuntimeException(String message, Throwable cause, boolean enableSuppression, boolean writableStackTrace) дозволяє створювати виключення без стек-трейсу, що значно зменшує вартість створення виключення.

Параметри enableSuppression і writableStackTrace у конструкторі винятків (Throwable, Exception, RuntimeException тощо) керують тим, як поводиться виняток після створення — зокрема, чи дозволено додавати до нього пригнічені винятки та чи буде створено стек викликів.

✅ enableSuppression

Цей параметр визначає, чи дозволено додавати пригнічені винятки (suppressed exceptions).

• Якщо true — дозволено використовувати метод addSuppressed(Throwable), і пригнічені винятки зберігатимуться (наприклад, при try-with-resources).

• Якщо false — спроба додати suppressed exception буде ігноруватися.

🧠 Навіщо це може бути потрібно?
Щоб зекономити пам’ять, якщо точно знаєте, що suppressed exceptions не потрібні, особливо в ресурсозатратних місцях (наприклад, в low-latency системах).

✅ writableStackTrace

Цей параметр визначає, чи створювати стек викликів (stack trace) для винятку.

• Якщо true — стек буде створено і доступний через printStackTrace() або getStackTrace().

• Якщо false — стек не створюється, і ці методи не дають корисної інформації.

🧠 Навіщо вимикати стек?
У high-performance застосунках створення стеку винятку — дорога операція (через збирання інформації про виклики методів). Якщо ви генеруєте багато винятків, але не аналізуєте їх, це може покращити продуктивність.

📉 Чи впливає це на перформанс?

• writableStackTrace = false → зменшує навантаження на CPU та GC.

• enableSuppression = false → економить пам'ять у випадках, коли suppressed exceptions не потрібні.

Але ці виграші мають сенс лише в специфічних сценаріях — коли ви кидаєте винятки масово, як частину логіки, а не для виняткових ситуацій.

Використання кешованих синглтон-виключень

Для ситуацій, коли виключення повторно використовуються:

public class ApiException {
    private static final NotFoundException NOT_FOUND = new NotFoundException("Resource not found");
    
    public static NotFoundException notFound() {
        return NOT_FOUND;
    }
    
    private static class NotFoundException extends RuntimeException {
        private NotFoundException(String message) {
            super(message, null, false, false);
        }
        
        // Запобігання модифікації стеку для повторного використання
        @Override
        public synchronized Throwable fillInStackTrace() {
            return this;
        }
    }
}

Патерн "Exception Handling Chain"

Організація обробки виключень у вигляді ланцюжка з чіткими рівнями відповідальності:

try {
    // Критичний код
} catch (SQLException e) {
    // Перетворення в доменне виключення без захоплення повного стек-трейсу
    throw new DataAccessException("Database error", e, false);
} catch (IOException e) {
    // Специфічна обробка для IO
    log.error("IO error", e);
    metrics.incrementErrorCount();
    throw new ServiceException(e.getMessage());
}

Профілювання та моніторинг впливу виключень

Для виявлення проблем із виключеннями варто використовувати:

1. Async-profiler з флагом --event=cpu для виявлення часу, витраченого на створення виключень

2. JFR (Java Flight Recorder) з відстеженням подій jdk.JavaExceptionThrow

3. Метрики JVM для відстеження частоти створення виключень

Тому..

1. Використовуйте виключення за призначенням — для обробки виняткових ситуацій, а не для контролю потоку

2. “В гярячих“ точках застосовуйте техніки lightweight exceptions без стек-трейсу

3. Розробіть чітку ієрархію виключень та стратегію їх перетворення

4. Вимірюйте вплив обробки виключень на пропускну здатність та затримку критичних флоу

5. Балансуйте між діагностичною цінністю стек-трейсів та продуктивністю