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

Что если блок finally выбросит исключение? Блок finally выполняется вне зависимости от того, было ли выброшено в его блоке try исключение, или нет. Когда исключение не случилось в try, но случилось в finally, нет ничего интересного. Это исключение как обычно пойдет вверх по стеку вызовов, пока не попадется в соответствующий ему catch. Вопрос подразумевает второй случай, когда исполнение попадает в finally в момент выброса исключения из try. Исключение из finally заменит собой исключение из try и пойдет вверх по стеку вместо него. Оригинальная проблема будет попросту забыта. Такая маскировка исключения усложняет отладку, лучше избегать её. Например IntelliJ IDEA выводит соответствующее предупреждение на оператор throw внутри finally. Java Guru

Как объявить переменное количество аргументов метода? Для этого используется аргумент-массив. В нем может находиться любое количество элементов. Еще с Java 5 для этого случая добавился синтаксический сахар: Variable-length argument (vararg). Три точки ... ставятся между типом и именем переменной, и становится можно передать любое количество аргументов, не упаковывая их в массив. На уровне байткода применение массива и варарга не отличаются: vararg-параметр Foo... превращается в параметр-массив Foo[], на этапе вызова подставляется неявное инстанцирование и заполнение массива. Чтобы избежать неоднозначностей, на vararg наложено ограничение: им может быть только один последний аргумент. Vararg, как массив, может быть пустым. Иногда это приводит к неочевидному поведению. Допустим, имеем две перегрузки метода с аргументами int... и float.... Вызов такого метода без параметров попадает в вариант с int, как с более специфичным типом. Наличие же перегрузки с несовместимыми типами, например int... и boolean..., приводит при вызове к ошибке компиляции «Ambiguous method call». Когда типом варарга используется generic-параметр, возникает warning «Possible heap pollution from parameterized vararg type». Вам нужно убедиться, что вы понимаете в чем этот риск, что ваш код не приводит к heap pollution, и уведомить об этом компилятор аннотацией @SafeVarargs. Java Guru

Чем анонимный внутренний класс отличается от лямбды? Лямбда-выражение имеет более легковесный синтаксис. Не нужно явно указывать тип функционального интерфейса, который лямбда реализует – он автоматически выведется из контекста. Лямбда-выражения добавлены в язык в первую очередь как синтаксический сахар. С другой стороны, у класса есть поля. Экземпляр анонимного класса сохраняет свое состояние между вызовами, и меняет его при необходимости. Для лямбды доступен лишь захват и effectively final использование внешних переменных. Лямбдой реализуется только функциональный интерфейс. Функциональный интерфейс – это тип с единственным абстрактным методом. Анонимным классом же можно расширить любой расширяемый класс или реализовать интерфейс с любым количеством абстрактных методов. Анонимный класс создает новый скоуп, лямбда работает в текущем. Это значит, что объявление переменной с именем, которое уже используется снаружи, в лямбде вызовет ошибку компиляции «variable is already defined», в анонимном классе скроет (shadowing) внешнюю переменную. С точки зрения реализации JVM, для лямбды не создается дополнительного .class файла, как это происходит для анонимного класса. Соответственно, не происходит и обычной загрузки и верификации класса. Вместо этого используется механизм invokedynamic и класс генерируется на лету с помощью LambdaMetafactory. Так что лямбда-выражения обычно работают быстрее. Java Guru

Перечислите целочисленные битовые операторы Во-первых, стоит освежить знания о бинарном представлении целых знаковых чисел. В Java используется подход two's complement – для значения 0 все биты нули, при переполнении максимального значения на 1 получается минимальное. Бинарные битовые операторы &, | и ^ действуют очевидным образом: выполняют побитовые «И», «ИЛИ» и «исключающее ИЛИ» (XOR) соответственно. Здесь особенно интересен XOR: Применение к значению «исключающего или» с одним и тем же параметром два раза дает то же значение. За счет этого его можно использовать как простейшее шифрование, аргумент выступит ключом; С помощью XOR реализуется XOR-обмен – алгоритм обмена значениями переменных без дополнительной памяти и без риска переполнения. Это также один из популярных вопросов для собеседования. Унарный оператор битового отрицания (дополнения) ~. Эквивалентен «исключающему или» с самим собой – все биты инвертируются. ~x эквивалентно -x-1. ~0 == -1. Битовые сдвиги: левый << правый знаковый >> и правый беззнаковый >>>. Левый операнд – что сдвигать, правый – на сколько битов. Второй параметр, дистанция сдвига, должен быть не больше доступных разрядов – 31 для int и 63 для long. Если передано значение больше – используются младшие 5 и 7 битов соответственно. То есть для int переменной x << 33 эквивалентно x << 2. a << b эквивалентно умножению a на 2 в степени b. a >> b совпадает с делением на 2 в степени b, с округлением вниз. Для положительных a то же что a/pow(2,b). Для не делящихся нацело на pow(2,b) отрицательных это a/pow(2,b)-1. Беззнаковый сдвиг вправо трактует число не как two's complement, а как беззнаковое. То есть Integer.MIN_VALUE будет сдвинут так, как будто это сдвигается число на 1 большее чем Integer.MAX_VALUE. Беззнакового сдвига влево не существует, потому что он совпадал бы со знаковым сдвигом, и был бы избыточным. Java Guru

Что такое короткое замыкание логического оператора? Логические операторы || и && лево-ассоциативны, то есть их параметры вычисляются слева направо. Если первое значение оказалось true в || или false в && – конечный результат уже предрешен, он будет тем же. В этом случае происходит так называемое «короткое замыкание» (short-circuiting) – оставшийся второй аргумент не вычисляется за ненадобностью. Эту особенность иногда удобно эксплуатировать, например для проверки на null в одну строку: return param != null && param.getBoolMember(); Но иногда такая ситуация влечет за собой неожиданные плавающие баги, если второй аргумент – не переменная, а функция с побочным эффектом. Для этой ситуации введены версии операторов без короткого замыкания: | и &. Это логические вариации «битового и» и «битового или». Вдобавок доступен оператор «исключающее или» ^. Он почти никогда не используется для булевых параметров, потому что абсолютно эквивалентен более интуитивно понятному !=. Другие битовые операторы для логических аргументов недоступны. Java Guru

В каком порядке указываются модификаторы? Правила применения модификаторов поля описаны в JLS 8.3.1: 🔘Нельзя указывать один модификатор дважды; 🔘Нельзя использовать несколько модификаторов доступа одновременно. Порядок указания вообще свободный, но обычно используется следующий: @Аннотации, доступ, static final transient volatile Требования для модификаторов метода находятся в JLS 8.4.3: 🔘Те же требования, что и к полю; 🔘Совместно с abstract кроме аннотаций можно использовать только protected или public; 🔘native метод не может использовать strictfp. И так же не требуется, но рекомендуется использовать такой порядок: @Аннотации, доступ, abstract static final synchronized native strictfp Java Guru

Зачем нужно ключевое слово default? Изначально (с Java 1.5) это слово использовалось для объявления дефолтного значения элементов аннотации. В Java 8 вместе с лямбдами и стримами появилась острая необходимость дополнить стандартные интерфейсы новыми методами. Никто естественно не собирался ломать обратную совместимость, и было предложено добавить методы по умолчанию. Теперь добавление ключевого слова default к методу интерфейса позволяет добавить ему тело. Все новые методы старых интерфейсов снабжаются дефолтной реализацией. В реализации такого метода его дефолтный вариант вызывается тем же синтаксисом, что и внешний класс из вложенного: InterfaceName.super.methodName(). Методы по умолчанию подошли еще на шаг к введению в Java беспроблемной версии множественного наследования – примесям (mixin). Интерфейс не может иметь состояния, поэтому полноценные примеси всё ещё недоступны. Java Guru

Как реализовать двусторонний обмен данными между потоками? Вопрос, который зачастую дается в виде практической задачи. Конечно, результата можно добиться разными способами: парой атомарных переменных, критическими секциями, потокобезопасными коллекциями. Но полезно знать, что специально для этого случая в стандартной библиотеке java.util.concurrent есть простой класс Exchanger. Класс содержит единственный метод V exchange(V x). Один поток передает в него данные, и встает в ожидание. Ожидание завершается, когда второй поток также приходит в метод exchange со своей порцией информации. В качестве результата вызова потоки получают данные друг друга. На основе класса Exchanger удобно создавать пайплайны обработки данных. Первый поток выполняет свою часть обработки, и складывает результаты в буфер. В качестве буфера может работать любой многоразовый объект-контейнер. Когда он заполняется, следующий поток обменивает его на второй, пустой буфер. Таким образом два буфера используются поочередно, не выделяется лишний раз память и не нагружается GC. Далее из попарно обменивающихся буферами потоков может строиться длинная многопоточная цепочка обработки. Java Guru

Приведите примеры использования fork/join framework Как следует из названий связанных классов, ForkJoinPool используется для рекурсивных задач. Это такие задачи, которые можно делить на порции, подзадачи. Отделение подзадачи – это операция fork, финальная агрегация результатов подзадач – join. Реализация fork/join для самых популярных общих случаев уже есть в стандартной библиотеке, работать непосредственно с классом ForkJoinPool не потребуется. Метод parallelSetAll из класса Arrays применяет fork/join для генерации элементов массива; parallelPrefix для модификации; parallelSort для сортировки. Фреймворк неявно работает и в параллельных стримах. В этом случае логику fork определяет его сплитератор, а join выполняют потоковые операции. Классический пример: Arrays.stream(new int[]{1, 2, 3, 4}).parallel().sum(); Существуют целые категории частных задач, решения которых хорошо параллелизуются: векторные операции, работа с графами, поиск данных. Для специфичных задач придется реализовывать собственные RecursiveTask, RecursiveAction, или Spliterator. Java Guru