Как реализовать двусторонний обмен данными между потоками?

Вопрос, который зачастую дается в виде практической задачи. Конечно, результата можно добиться разными способами: парой атомарных переменных, критическими секциями, потокобезопасными коллекциями. Но полезно знать, что специально для этого случая в стандартной библиотеке java.util.concurrent есть простой класс Exchanger.

Класс содержит единственный метод V exchange(V x). Один поток передает в него данные, и встает в ожидание. Ожидание завершается, когда второй поток также приходит в метод exchange со своей порцией информации. В качестве результата вызова потоки получают данные друг друга.

На основе класса Exchanger удобно создавать пайплайны обработки данных. Первый поток выполняет свою часть обработки, и складывает результаты в буфер. В качестве буфера может работать любой многоразовый объект-контейнер. Когда он заполняется, следующий поток обменивает его на второй, пустой буфер. Таким образом два буфера используются поочередно, не выделяется лишний раз память и не нагружается GC. Далее из попарно обменивающихся буферами потоков может строиться длинная многопоточная цепочка обработки.

Подписывайся на наш канал в Max 🟪

👇Паттерн Строитель (Builder)

Builder — это порождающий паттерн, который позволяет пошагово создавать сложные объекты. Вместо того чтобы создавать объект одним большим конструктором с множеством параметров, Builder организует процесс создания по частям, обеспечивая гибкость и читаемость кода.

Использование:

🟡 Когда нужно создать объект с большим количеством параметров, и не все из них обязательны.
🟡 Когда процесс создания объекта требует выполнения нескольких шагов или дополнительных проверок.
🟡 В случаях, когда один и тот же код должен создавать разные представления объекта (например, текстовое и графическое).

Преимущества:

1️⃣ Упрощает создание сложных объектов, делая процесс понятным и читаемым.
2️⃣ Позволяет создавать объекты с разными вариациями без необходимости дублирования кода.
3️⃣ Разделяет логику создания объекта от его структуры, что упрощает поддержку и модификацию кода.

Недостатки:

1️⃣ Увеличивает сложность кода за счёт создания дополнительных классов и методов.
2️⃣ Может быть избыточным для простых объектов с небольшим количеством параметров.
3️⃣ Требует дополнительного внимания при проектировании, чтобы избежать путаницы между обязательными и необязательными шагами.

📌 Паттерн Builder полезен, если объект имеет много параметров и их нужно задавать гибко. Например, при создании сложных конфигураций для HTTP-запросов (заголовки, тело, параметры), построении графических интерфейсов или генерации HTML-документов. Builder помогает сделать код более понятным и избежать создания конструкций с длинными и неудобными конструкторами.

Подписывайся на наш канал в Max 🟪

Что такое функциональный интерфейс?

Так называется специальная разновидность интерфейса, который определяет тип-функцию, коллбэк.

Чтобы компилятор считал интерфейс функциональным, этот интерфейс должен добавлять единственный абстрактный метод. Вдобавок он может содержать любое количество дефолтных методов с телом. Переобъявление методов класса Object также игнорируется.

Никаких других ограничений на метод не накладывается: он не ограничен в типах аргументов и возвращаемого значения, может иметь любое название и список выбрасываемых исключений (checked и unchecked).

Даже при выполнении всех этих условий, никакие другие разновидности типов кроме interface не могут считаться функциональными интерфейсами.

Дополнительно функциональный интерфейс принято помечать аннотацией @FunctionalInterface. Наличие этой аннотации не необходимо, но оно даёт дополнительную валидацию: её присутствие на нефункциональном типе спровоцирует ошибку компиляции.

Типичные примеры функциональных интерфейсов: Callable, Supplier, Comparable.

Подписывайся на наш канал в Max 🟪

Задачи с собеседований: Проверка, является ли бинарное дерево деревом поиска (middle)

— Как определить, является ли заданное бинарное дерево деревом поиска (BST)?

📌 Ключевые моменты:

- Бинарное дерево поиска (BST) — это бинарное дерево, в котором для каждого узла все значения в левом поддереве меньше значения узла, а все значения в правом поддереве больше.
- Для проверки можно использовать рекурсивный подход с отслеживанием допустимых диапазонов значений для каждого узла.
- Как изменить реализацию для работы с любыми типами данных в узлах дерева?

Реализация с числами в узлах на картинке 👆

Подписывайся на наш канал в Max 🟪

Чем отличается final finally finalize?

Тем, что это даже синтаксически разные вещи. Как и вопрос о методах Object, это способ начать разговор.

finalize – метод-финализатор из Object.

final – модификатор, который применяется к переменным, полям, методам и классам. Переменная или поле становится неизменяемым и требует инициализации. Финальный метод нельзя переопределить в наследниках. Финальный класс не может иметь наследников вообще. Используется для создания хорошего API по принципу наименьших привилегий.

Когда в методе используется локальная переменная внешней области видимости, она обязана быть effectively final. В этом случае ключевое слово final необязательно, но значение всё равно не должно меняться.

finally – часть языковой конструкции try-catch-finally.

Любое исключение, выброшенное из блока try переводит исполнение в самый соответствующий ему catch (при наличии). Этим продиктована необходимость располагать блоки catch в строгом порядке, от типа исключения-наследника, к родителю. В случае multicatch тот же порядок должен соблюдаться и внутри одного catch. Больше примеров про порядок.

После выполнится блок finally. Выполняется он в любом случае, было исключение или нет. Типичное использование – освобождение ресурсов, обязательные завершающие действия.

Для требующих финализации классов («ресурсов») добавляется интерфейс AutoCloseable, повторяющийся код блока final выносится в метод close и вызывается неявно в конце try-with-resources. Если в этой конструкции присутствует и явный final, он будет выполнен после.

Подписывайся на наш канал в Max 🟪

Чем отличаются checked и unchecked исключения?

Вопрос формулируют по-разному, суть вопроса – объяснение иерархии классов исключений. Подробно описано в документации.

Исключения бывают checked и unchecked. Checked требуется указывать в сигнатуре метода в разделе throws; перехватывать или добавлять в throws в вызывающем его методе. Unchecked можно добавить, но не обязательно, перехватывать не обязательно даже если указана в throws.

🔘Throwable – базовый класс для всего что может быть использовано с оператором throw и в конструкции try-catch
🔘RuntimeException – «нормальные» unchecked-исключения
🔘Error – unchecked исключения, которые означают «серьезные проблемы» приложения. Не должны обрабатываться (хотя технически можно). Теоретически JVM может находиться в невалидном состоянии и не давать больше никаких гарантий
🔘Exception (кроме RuntimeException) – checked исключения

Подписывайся на наш канал в Max 🟪