Java Guru

Вопрос с собеседования Где хранятся объекты? Ответ: Все объекты, создаваемые через new, размещаются в куче (heap) — области памяти, управляемой сборщиком мусора. Ссылки на эти объекты могут храниться в стеке, если они являются локальными переменными внутри метода. Таким образом, объект — в куче, ссылка на него — в стеке. Java Guru | Мы в Телеграм

Как починить мертвый ThreadLocal в пуле потоков Если положить RequestId / userId / traceId в ThreadLocal и передать задачу в ExecutorService в итоге значение пропадёт. InheritableThreadLocal помогает только при явном создании потока, но не при переиспользовании из пула. Alibaba решили это ещё в 2013 году, а библиотека до сих пор активно поддерживается → TransmittableThreadLocal (TTL). 🔹 Подключается: com.alibaba transmittable-thread-local 2.14.5 🔹 Используется как обычный ThreadLocal, только умнее: TransmittableThreadLocal traceId = new TransmittableThreadLocal<>(); traceId.set("req-123"); ExecutorService pool = TtlExecutors.getTtlExecutorService( Executors.newFixedThreadPool(4) ); pool.submit(() -> { // "req-123" — доступен здесь, в потоке из пула System.out.println(traceId.get()); }); 🔹 Три способа интеграции → Обернуть Runnable/Callable — TtlRunnable.get(task) → Обернуть пул — TtlExecutors.getTtlExecutorService(pool) → Java Agent — вообще без изменений в коде: -javaagent:transmittable-thread-local.jar Агентовый режим особенно полезен, когда нужно прозрачно встроить TTL в легаси-проект или сторонний фреймворк — он патчит JDK-классы пулов на уровне байткода. 0 зависимостей. Работает с виртуальными потоками (Project Loom). Поддерживает кастомный TtlCopier для глубокого копирования значений при передаче в дочерний поток. Актуально везде, где есть distributed tracing, MDC, tenant isolation или любой per-request контекст в многопоточке. ⚠️ README встретит иероглифами, не пугайся, английская версия лежит в README-EN.md. Java Guru | Мы в Телеграм

Магия IntelliJ IDEA Если используешь Ctrl + P (подсказка параметров метода), то вот ещё один полезный хот кей: Shift + Ctrl + I → быстрый просмотр определения. 🟢 Зачем это нужно — Позволяет посмотреть реализацию метода/класса/интерфейса без перехода в другой файл. — Работает с любыми символами: методами, переменными, константами, даже SQL-мэпперами в MyBatis. — Незаменимо, если не хочешь терять контекст текущего кода. 🟢 Как использовать — Наведи курсор на метод, поле или класс, нажми Ctrl + Shift + I — появится всплывающее окно с реализацией. — Работает и в дебаге, и при просмотре внешних библиотек (если есть исходники).

Java: используйте WeakHashMap для кэширования, когда ключи без ссылок должны удаляться сборщиком мусора. ❌В HashMap, пока существует сама мапа, ключи и связанные с ними значения не будут удаляться сборщиком мусора. ✅В WeakHashMap ключи хранятся через слабые ссылки, и если на ключ больше нет сильных ссылок в программе, сборщик мусора может его удалить, и он автоматически исчезнет из мапы. ✅Пример: Map map = new WeakHashMap<>(); User u1 = new User("Mick"); map.put(u1, "Cached data"); ... u1 = null; // С этого момента ключ u1 доступен для сборки мусора.

Утечка, которую не видит heap dump Интересная ловушка: вызываешь string.intern() на динамических строках, приложение падает с OOM, делаешь heap dump — а там всё чисто. Где утечка? 🟢 Суть проблемы String Pool до Java 7 жил в PermGen, с Java 7 переехал в heap. Казалось бы, проблема решена. Но нет. Внутри String Pool использует нативную хеш-таблицу StringTable, которая живёт в native memory (вне heap). Когда ты делаешь intern(), в heap создаётся сама строка, но ссылка на неё хранится в нативной StringTable. 🟢 Что происходит Строки попадают в heap (GC их уберёт), но StringTable в native memory растёт бесконечно. Размер StringTable фиксирован и задаётся -XX:StringTableSize. При переполнении — коллизии, деградация, OOM. 🟢 Как увидеть? bashjcmd VM.stringtable Или Native Memory Tracking: bash-XX:NativeMemoryTracking=detail jcmd VM.native_memory Ищи раздел Symbol — там StringTable. ⚠️ String Pool — это не только heap. StringTable живёт в native memory, и это классическая офф-хип утечка. Java Guru

Как устроены атомики? Начнем с того, что такое атомики и зачем нужны. Atomic* – семейство классов из java.util.concurrent. Они предоставляют набор атомарных операций для соответствующих типов. Например с помощью методов getAndIncrement/incrementAndGet класса AtomicInteger можно делать неатомарный в обычных условиях инкремент (i++). Условно можно разделить подходы реализации большинства atomic-методов на две группы: compare-and-set и set-and-get. Методы категории compare-and-set принимают старое значение и новое. Если переданное старое значение совпало с текущим, устанавливается новое. Обычно делегируют вызов в методы класса Unsafe, которые заменяются нативными реализациями виртуальной машины. Виртуальная машина в большинстве случаев использует атомарную операцию процессора compare-and-swap (CAS). Поэтому атомики обычно более эффективны чем стандартная дорогостоящая блокировка. В случае set-and-get старое значение неизвестно. Поэтому нужен небольшой трюк: программа сначала считывает текущее значение, а затем записывает новое, тоже с помощью CAS, потому что запись могла успеть поменяться даже за этот шаг. Эта попытка чтения+записи повторяется в цикле, пока старое значение не совпадет и переменная не будет успешно записана. Этот трюк называется double-checked или optimistic locking, и может быть использован и в пользовательском коде с любым способом синхронизации. Оптимистичность заключается в том, что мы надеемся что состояния гонки нет, прибегая к синхронизации только если гонка всё же случилась. Реализация оптимистичной блокировки может быть дана как отдельная задача. Java Guru