Що таке stack trace

Розглянемо класичний приклад генерації винятку:

🟢 Junior Level

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

Stack Trace (стек викликів) — це знімок ланцюжка викликів методів у поточному потоці виконання, зафіксований у момент створення об’єкта винятку (new Throwable()). Він відображає зворотну траєкторію виконання програми: від конкретного рядка методу, де стався збій, униз до точки входу в потік (наприклад, методу main() або методу run() фонового воркера). Кожен елемент стек-трейсу містить назву класу, назву методу, ім’я вихідного файлу та номер скомпільованого рядка.

Анатомія Stack Trace

Розглянемо класичний приклад генерації винятку:

public class StackTraceDemo {
    public static void main(String[] args) {
        initiateOrder();
    }

    private static void initiateOrder() {
        processPayment();
    }

    private static void processPayment() {
        throw new IllegalStateException("Payment gateway unreachable");
    }
}

Виведення в консолі:

java.lang.IllegalStateException: Payment gateway unreachable
    at StackTraceDemo.processPayment(StackTraceDemo.java:11)
    at StackTraceDemo.initiateOrder(StackTraceDemo.java:7)
    at StackTraceDemo.main(StackTraceDemo.java:3)

Порядковий розбір:

java.lang.IllegalStateException: Payment gateway unreachable — повне кваліфіковане ім’я класу винятку та текстове повідомлення причини (message).
at StackTraceDemo.processPayment(StackTraceDemo.java:11) — вершина стека (Top of Stack): активний фрейм, у якому було інстанційовано об’єкт винятку (файл StackTraceDemo.java, рядок 11).
at StackTraceDemo.initiateOrder(StackTraceDemo.java:7) — фрейм викликаючого методу (рядок 7).
at StackTraceDemo.main(StackTraceDemo.java:3) — точка входу потоку, корінь виклику (Bottom of Stack).

Що таке Stack Frame (кадр стека)

Стек викликів формується з кадрів (фреймів), які JVM виділяє в пам’яті Thread Stack при кожному виклику методу. Кожен фрейм містить:

Масив локальних змінних методу (передані аргументи та локальні змінні).
Операндний стек (Operand Stack) для виконання байткод-інструкцій.
Посилання на пул констант часу виконання (Runtime Constant Pool) поточного класу.
Вказівник адреси повернення (Return Address) у викликаючий метод.

🟡 Middle Level

Внутрішня будова: `StackTraceElement`

Стек-трейс у Java представляється масивом об’єктів java.lang.StackTraceElement[]:

public class StackTraceInspection {
    public static void printCurrentStack() {
        StackTraceElement[] frames = Thread.currentThread().getStackTrace();
        for (StackTraceElement frame : frames) {
            System.out.printf("Class: %s | Method: %s | Line: %d | Native: %b%n",
                frame.getClassName(),
                frame.getMethodName(),
                frame.getLineNumber(),
                frame.isNativeMethod());
        }
    }
}

У Java 9+ до StackTraceElement додалася підтримка модульної системи JPMS:

getModuleName() — ім’я модуля (наприклад, java.base).
getModuleVersion() — версія модуля.
getClassLoaderName() — ім’я завантажувача класів.

Вартість формування: метод `fillInStackTrace()`

Ключова архітектурна особливість: стек-трейс заповнюється під час виконання конструктора Throwable, а не в інструкції throw.

Конструктор Throwable викликає нативний метод:

public synchronized native Throwable fillInStackTrace();

Що відбувається в HotSpot JVM під час виклику `fillInStackTrace()`:

Потік призупиняє виконання байткоду Java та перемикається на нативний код ядра C++ HotSpot.
Віртуальна машина виконує лінійний обхід фізичних фреймів стека викликів ОС.
Відбувається декодування адрес виконання та зіставлення їх із символьними метаданими класів у Metaspace.
Виділяється пам’ять у купі (Java Heap) під масив структур стек-трейсу.
На глибоких стеках (у Spring Boot / Hibernate глибина нерідко досягає 80–150 фреймів) це забирає від 1 до 10 мікросекунд.

Сучасний `StackWalker` API (Java 9+)

До Java 9 для програмного аналізу стека використовували Thread.currentThread().getStackTrace() або new Throwable().getStackTrace(). Обидва підходи жадібно (eagerly) копіюють увесь стек повністю, створюючи надлишкове навантаження на Garbage Collector.

У Java 9 представлено високоефективний лінивий інструмент — java.lang.StackWalker:

import java.lang.StackWalker.Option;
import java.util.List;

public class StackWalkerExample {
    // Створюємо екземпляр із доступом до живих Class<?> об'єктів
    private static final StackWalker WALKER = StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);

    public static List<String> getCallerMethods() {
        return WALKER.walk(frames -> frames
            .filter(f -> !f.getClassName().startsWith("org.springframework")) // Фільтруємо проксі-шари
            .dropWhile(f -> f.getMethodName().equals("getCallerMethods"))
            .limit(5)
            .map(StackWalker.StackFrame::getMethodName)
            .toList()
        );
    }
}

Переваги `StackWalker`:

Ліниве обчислення (Lazy Evaluation): Стек обходиться як Stream<StackFrame>, JVM не виділяє пам’ять під непотрібні глибокі фрейми.
Прямий доступ до Class<?>: Метод f.getDeclaringClass() повертає живий об’єкт класу без повільного виклику Class.forName().
Продуктивність: Працює в рази швидше та економніше порівняно зі старим getStackTrace().

🔴 Senior Level

Загадка зниклого стека: оптимізація `-XX:-OmitStackTraceInFastThrow`

Класична проблема у продакшені під високим навантаженням: сервіс раптово починає писати в логи мільйони порожніх повідомлень:

java.lang.NullPointerException
java.lang.NullPointerException
java.lang.NullPointerException

Стек-трейс повністю відсутній, номер рядка невідомий!

Чому це відбувається?

JIT-компілятор HotSpot (C2) містить оптимізацію: якщо вбудоване виключення (NullPointerException, ArithmeticException, ArrayIndexOutOfBoundsException, ClassCastException) викидається в одній точці коду тисячі разів поспіль, компілятор вважає, що місце збою стабільне.

Компілятор C2 перекомпільовує цю ділянку байткоду, замінюючи створення нового об’єкта винятку на викидання попередньо виділеного статичного синглтона без стека (fast throw).

Як діагностувати або вимкнути:

Для повернення повних стек-трейсів у лог на час розслідування передають прапорець JVM:
```
-XX:-OmitStackTraceInFastThrow
```
У продакшені слід шукати найпершу появу винятку в логах: перші кілька сотень разів помилка гарантовано логувалася з повним стек-трейсом.

Стек-трейси в асинхронному коді та Virtual Threads (Java 21)

1. Асинхронні ланцюжки (Reactive / CompletableFuture)

В асинхронному та реактивному коді (WebFlux, Project Reactor, RxJava) стек-трейс фіксує лише потік обробника подій (Event Loop / Netty thread) у момент аварії. Він не містить інформації про те, хто й коли ініціював асинхронну операцію.

Рішення: Розподілений трейсинг (MDC correlation ID, OpenTelemetry traceparent) та оператори відладки (Hooks.onOperatorDebug()).

2. Virtual Threads (Project Loom / Java 21)

Віртуальні потоки виконуються поверх пулу несучих потоків ОС (Carrier Threads — ForkJoinPool). Стек віртуального потоку зберігається в купі Java Heap, а не у фіксованому стеку ОС.

Під час формування стек-трейсу віртуального потоку JVM «склеює» логічний стек користувацьких методів, автоматично приховуючи внутрішні фрейми планувальника Loom (Continuation.run()).
У дампах потоків (jcmd <pid> Thread.dump_to_file) віртуальні потоки відображаються компактно, запобігаючи вичерпанню пам’яті при аналізі мільйонів віртуальних стеків.

Production Observability: Структуроване логування винятків

Виведення стек-трейсу через e.printStackTrace() або конкатенацію рядків у високонавантажених системах неприпустиме. Логування має здійснюватися у структурованому форматі JSON через SLF4J / Logback:

{
  "timestamp": "2026-09-28T20:53:30.123Z",
  "level": "ERROR",
  "thread": "http-nio-8080-exec-1",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7",
  "message": "Failed to process customer payment",
  "exception": {
    "class": "com.bank.payment.PaymentException",
    "message": "Gateway timeout (504)",
    "stackTrace": "com.bank.payment.PaymentException: Gateway timeout\n\tat com.bank.payment.GatewayClient.charge(GatewayClient.java:45)..."
  }
}

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

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

У який саме момент формується стек-трейс винятку: під час new Exception() чи під час throw? Відповідь: У момент виконання оператора new Exception(). Саме в цей час конструктор Throwable викликає нативний метод fillInStackTrace(). Інструкція байткоду throw лише передає вже сформований об’єкт у механізм розгортання стека (stack unwinding).
Чому в продакшені під високим навантаженням NullPointerException раптово починає логуватися без стек-трейсу? Відповідь: Це результат роботи оптимізації JIT-компілятора HotSpot під назвою OmitStackTraceInFastThrow. Коли одне й те саме системне виключення викидається багаторазово в гарячому циклі, JIT замінює його на попередньо створений синглтон без стека для економії CPU.
У чому ключова відмінність StackWalker (Java 9+) від Thread.currentThread().getStackTrace()? Відповідь: Thread.currentThread().getStackTrace() негайно і жадібно копіює всі кадри стека в масив об’єктів у купі. StackWalker працює ліниво через Stream, дозволяючи фільтрувати фрейми на льоту, читати лише потрібну глибину та отримувати живі об’єкти Class<?> без накладних витрат.
Що відбувається зі стек-трейсом у реактивному програмуванні (WebFlux, RxJava)? Відповідь: Стек-трейс розривається. Він показує лише стек потоку диспетчера подій (наприклад, Netty EventLoop), який виконує поточну задачу, але не містить історії методів потоку, що спочатку сконфігурував реактивний ланцюжок.

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

❌ Твердження: “Стек-трейс створюється в момент виклику throw”: Демонструє нерозуміння життєвого циклу Throwable та методу fillInStackTrace().
❌ Використання e.printStackTrace() у комерційному коді: Логування в System.err оминає структуровані апендери, викликає блокування потоків через синхронізацію та втрачає контекст (MDC).
❌ Нерозуміння причини зникнення стек-трейсу в логах продакшену: Сприйняття оптимізації OmitStackTraceInFastThrow за аномальний збій JVM або баг логера.
❌ Створення винятків зі стек-трейсом у високонавантажених циклах валідації: Створює колосальне навантаження на процесор через постійний нативний обхід стека.