ℹ️ Как устроен под капотом HashSet?

HashSet — это реализация множества (set), которое не допускает дублирующихся элементов. В его основе используется механизм хеширования для быстрого поиска, добавления и удаления элементов.

🔹 Хеш-таблица как основа
В основе HashSet лежит HashMap. Каждый элемент множества хранится в качестве ключа внутри объекта HashMap, а его значение всегда фиксированное — это специальный объект-заглушка. Этот объект используется для обозначения присутствия элемента, так как HashMap требует наличие пары "ключ-значение".

🔹 Хеширование
Когда вы добавляете элемент в HashSet, для него вычисляется хеш-код с помощью метода hashCode(). Этот хеш-код помогает определить, в какую "корзину" (bucket) поместится элемент. Если два элемента имеют одинаковый хеш-код (коллизия), они будут помещены в один и тот же бакет, и далее будут различаться с помощью метода equals().

🔹 Коллизии и структура бакета
До Java 8, если в бакет попадало несколько элементов (коллизия), они сохранялись в виде односвязного списка. Это приводило к тому, что в худшем случае производительность поиска и добавления элементов могла падать до O(n), если список становился слишком длинным.

С Java 8 при превышении 8 элементов в одном бакете, односвязный список преобразуется в красно-чёрное дерево, что улучшает производительность операций до O(log n). Когда количество элементов в бакете падает ниже 6, структура снова преобразуется обратно в связанный список для экономии памяти.

🔹 Добавление элементов
▪️ В среднем: добавление элемента занимает O(1), потому что благодаря хеш-кодам можно быстро находить нужную корзину для элемента.
▪️ В худшем случае: добавление элемента может занять O(n) до Java 8 (связный список) и O(log n) начиная с Java 8 (красно-чёрное дерево).

🔹 Удаление элементов
Удаление происходит также через хеш-код: ищется соответствующая корзина, а затем элемент удаляется, если он там есть. Сложность удаления аналогична добавлению: O(1) в среднем и O(n) или O(log n) в худшем случае (в зависимости от структуры бакета).

🔹 Преимущества и недостатки

▪️ Преимущества: Быстрое добавление, удаление и поиск элементов в среднем за O(1), так как используется хеширование. Улучшенная производительность с Java 8 благодаря использованию красно-чёрного дерева.
▪️ Недостатки: Не гарантирует порядок элементов, а при частых коллизиях, особенно в старых версиях Java, производительность может падать до O(n).

🕯 Паттерн Observer (Наблюдатель)

Observer — это поведенческий паттерн, который создаёт механизм подписки, позволяющий одним объектам следить и реагировать на изменения состояния других объектов. Наблюдатель предоставляет гибкую систему взаимодействия между объектами, исключая жесткую связанность.

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

🔹 Когда нужно оповещать несколько объектов об изменениях состояния другого объекта.
🔹 Когда важно обеспечить слабую связанность между компонентами системы.
🔹 При разработке систем, где одни объекты должны реагировать на изменения в других, без жёсткой привязки.

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

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

Недостатки:

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

📊 Логирование, трассировка и метрики

Логирование, трассировка и метрики — это три столпа наблюдаемости системы

🔹 Логирование
Логирование фиксирует дискретные события в системе. Например, мы можем записывать входящие запросы или обращения к базам данных как события. Это самый объемный тип данных. Для построения платформы анализа логов часто используют стек ELK (Elastic-Logstash-Kibana). Мы часто определяем стандартизированный формат логов для разных команд, чтобы использовать ключевые слова при поиске среди большого объема логов.

🔹 Трассировка
Трассировка обычно привязана к запросам. Например, пользовательский запрос проходит через API-шлюз, балансировщик нагрузки, сервис A, сервис B и базу данных — это можно визуализировать в системах трассировки. Это полезно для выявления узких мест в системе. OpenTelemetry используется для демонстрации типичной архитектуры, которая объединяет три столпа в одной платформе.

🔹 Метрики
Метрики — это обычно агрегируемая информация из системы. Например, QPS сервиса, отзывчивость API, задержка сервиса и т.д. Сырые данные записываются в базы данных временных рядов, такие как InfluxDB. Prometheus извлекает данные и преобразует их на основе предопределенных правил оповещений. Затем данные отправляются в Grafana для отображения или в менеджер оповещений, который затем рассылает уведомления по email, SMS или в Slack.

💬 Какие инструменты вы используете для мониторинга системы?

⌛ Введение в CompletableFuture

Когда дело касается выполнения асинхронных задач, класс CompletableFuture является мощным инструментом для упрощения работы с многопоточностью и асинхронным программированием. Он позволяет строить цепочки задач, обрабатывать ошибки и объединять несколько будущих значений без использования блокирующих операций.

CompletableFuture — это расширение интерфейса Future, которое упрощает работу с асинхронными вычислениями. В отличие от стандартного Future, он позволяет:

▪️ Запускать задачи асинхронно;
▪️ Комбинировать несколько задач;
▪️ Обрабатывать ошибки без try-catch;
▪️ Строить цепочки зависимостей.

Пример создания асинхронной задачи:

CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    // Эмуляция долгой задачи
    try {
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        throw new IllegalStateException(e);
    }
    return "Задача завершена!";
});

System.out.println(future.join()); // Ожидание завершения и получение результата

Здесь задача выполняется в фоновом потоке, а основной поток продолжает свою работу.

🎮 Комбинирование нескольких задач

Часто нужно дождаться завершения нескольких задач и собрать их результаты. С помощью thenCombine() можно комбинировать результаты нескольких асинхронных вычислений:

CompletableFuture<Integer> future1 = CompletableFuture.supplyAsync(() -> 50);
CompletableFuture<Integer> future2 = CompletableFuture.supplyAsync(() -> 20);

CompletableFuture<Integer> result = future1.thenCombine(future2, Integer::sum);

System.out.println(result.join()); // 70

Здесь задачи выполняются параллельно, и их результаты комбинируются, когда обе завершены.

❌ Обработка ошибок

Одним из главных преимуществ CompletableFuture является возможность обрабатывать ошибки без try-catch через метод exceptionally():

CompletableFuture<Integer> future = CompletableFuture.supplyAsync(() -> {
    if (true) throw new RuntimeException("Ошибка!");
    return 42;
}).exceptionally(ex -> {
    System.out.println("Произошла ошибка: " + ex.getMessage());
    return 0; // Возвращаем дефолтное значение в случае ошибки
});

System.out.println(future.join()); // 0

Этот подход улучшает читаемость и упрощает обработку исключений в асинхронном коде.

📎 Композиция цепочек

Вы можете строить целые цепочки задач с помощью методов thenApply(), thenAccept() и т.д. Пример использования:

CompletableFuture.supplyAsync(() -> "Hello")
    .thenApply(result -> result + " World")
    .thenAccept(finalResult -> System.out.println(finalResult)); // Hello World

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

🛠 Применение на практике

CompletableFuture идеально подходит для задач, требующих асинхронности: запросы к API, обработка данных в фоне и т.д. Пример с вызовом нескольких API параллельно:

CompletableFuture<String> api1 = CompletableFuture.supplyAsync(() -> {
    // Эмуляция запроса к первому API
    return "Response from API 1";
});

CompletableFuture<String> api2 = CompletableFuture.supplyAsync(() -> {
    // Эмуляция запроса ко второму API
    return "Response from API 2";
});

CompletableFuture<Void> allOf = CompletableFuture.allOf(api1, api2);

allOf.thenRun(() -> {
    try {
        System.out.println(api1.get() + " & " + api2.get());
    } catch (Exception e) {
        e.printStackTrace();
    }
});

🔍 Что такое MVC?

MVC (Model-View-Controller) — это популярный архитектурный паттерн, который разделяет приложение на три компонента:

Model — отвечает за бизнес-логику и управление данными. Это сердце приложения, где происходит взаимодействие с базой данных, выполнение бизнес-правил и другие операции.

View — представляет собой интерфейс пользователя. Он отвечает за отображение данных и взаимодействие с пользователем, но не содержит бизнес-логики.

Controller — посредник между Model и View. Он получает запросы от пользователя, передает их Model и возвращает результаты во View.

💡 MVC позволяет четко разделить обязанности между компонентами, облегчая поддержку и масштабирование кода.

👀 Принципы SOLID

Как разработчики, мы стремимся к тому, чтобы наш код был поддерживаемым, масштабируемым и готовым к изменениям. Один из способов достичь этого — следовать принципам SOLID. Эти пять принципов проектирования помогают создавать системы, которые легко понимать и поддерживать, что ведет к более чистому и надежному коду.

Рассмотрим каждый принцип:

1️⃣ Принцип единственной ответственности (S)
Каждый класс должен иметь только одну причину для изменения, то есть он должен отвечать за одну задачу или ответственность. Это достигается за счет того, что классы фокусируются на выполнении конкретных задач. Соблюдение этого принципа делает код более модульным и простым в поддержке.

2️⃣ Принцип открытости/закрытости (O)
Классы должны быть открыты для расширения, но закрыты для изменения. Это значит, что поведение класса можно расширять, не изменяя его существующий код. В Java это часто реализуется через использование интерфейсов или абстрактных классов.

3️⃣ Принцип подстановки Барбары Лисков (L)
Объекты суперкласса должны заменяться объектами подкласса без нарушения корректности программы. В Java это особенно важно при работе с наследованием, чтобы подклассы правильно расширяли базовые классы, не изменяя их поведение.

4️⃣ Принцип разделения интерфейса (I)
Клиенты не должны зависеть от интерфейсов, которые они не используют. В Java это достигается путем разделения крупных интерфейсов на более узкоспециализированные, чтобы классы реализовывали только те методы, которые им действительно нужны.

5️⃣ Принцип инверсии зависимостей (D)
Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракций. В Java это часто реализуется через внедрение зависимостей (Dependency Injection), которое позволяет передавать зависимости извне, что способствует слабой связности и гибкости системы.