👀 Задача с собеса: «Single-flight» объединение запросов к внешнему API (middle+)

Компания ловит шторма трафика: десятки потоков одновременно дергают один и тот же медленный эндпоинт (например, профили клиентов). Хотят убрать дубликаты запросов и снизить нагрузку на апстрим. Задача:

Реализуйте in-memory «single-flight» слой, который:

— Для одного и того же ключа выполняет ровно ОДНУ загрузку, остальные ожидают тот же результат.
— Имеет короткоживущий кэш (TTL) для защиты от штамповки (cache stampede).
— Потокобезопасен и работает за O(1) на обращение (без полных проходов).
— Прозрачно пробрасывает исключение всем конкурентным ожидателям, если загрузчик упал.

▪️ Условия

— API: CompletableFuture<V> getOrLoad(K key, Supplier<V> loader) (или Supplier<CompletableFuture<V>>, если загрузка уже async).

— Если в кэше есть не сгоревший ключ, вернуть немедленно. Если нет — запустить единственную загрузку на ключ и раздать один и тот же Future всем конкурентным вызовам.

— По завершении загрузки положить результат в кэш с expireAt.

— Удаление сгоревших записей ленивое (на чтении/записи), без фоновых сканеров.

— Критические секции минимальные; без глобальных блокировок.

💡 Ключевые моменты

— Объединение запросов: ConcurrentHashMap<K, CompletableFuture<V>> inFlight + computeIfAbsent исключит дубликаты.

— Кэш: ConcurrentHashMap<K, Entry<V>> cache, где Entry хранит value и expireAt.

— TTL: проверка сроков строго точечная; протухшее удаляем перед использованием.

— Ошибки: один промах/ошибка должны одинаково прилететь всем конкурентным ожидающим.

— Производительность: никакой синхронизации на весь объект; один ключ — одна «тонкая» операция.

💬 Возможная реализация в комментариях. Пишите также ваши реализация и способы оптимизации.

🐸 Библиотека собеса по Java

👑 IntelliJ IDEA: Analyze Data Flow

Когда код становится сложнее, простого Find Usages уже мало. Хотите понять, откуда пришло значение переменной или куда оно утекает? Для этого есть Analyze Data Flow.

🔹 Что делает

— Позволяет проследить поток данных: где переменная инициализируется, как модифицируется и где используется
— Работает не только для переменных, но и для параметров методов, полей и возвращаемых значений
— Может анализировать как «куда идёт», так и «откуда пришло» (Forward/Backward analysis)

🔹 Зачем это нужно

— Быстро понять, почему метод получает null (и где он берётся)
— Выявить неочевидные зависимости между частями кода
— Ускорить отладку без бесконечного «шагания» по дебаггеру

🔹 Как использовать

— Выделите переменную или метод
— Analyze → Data Flow to Here / Data Flow from Here
— IDEA визуально покажет дерево зависимостей

🐸 Библиотека джависта

#Enterprise

👀 Внутреннее устройство LinkedList

LinkedList — это классическая реализация двусвязного списка. На поверхности он выглядит как обычная коллекция, реализующая интерфейсы List, Deque и Queue. Но под капотом это структура узлов (Node), которые связаны друг с другом через ссылки на предыдущий и следующий элемент.

📦 Базовая структура

Каждый элемент списка хранится в отдельном объекте Node<E>, который содержит:

▪️ E item — сам элемент
▪️ Node<E> next — ссылка на следующий узел
▪️ Node<E> prev — ссылка на предыдущий узел

У LinkedList есть два поля:

▪️ first — голова списка
▪️ last — хвост списка

Это позволяет быстро добавлять элементы в начало и конец.

⚡️ Добавление и удаление

— Добавление в начало (addFirst) или конец (addLast) → O(1): меняем ссылки у пары узлов.
— Удаление головы или хвоста также → O(1).
— Вставка или удаление в середине требует сначала дойти до нужного узла → O(n).

🌊 Поиск элемента

— По индексу: список не хранит массив, значит придётся идти по ссылкам.
— Оптимизация: если индекс ближе к голове, обход идёт с first, если к хвосту — с last.
Сложность в среднем — O(n/2), то есть линейная.

📊 Производительность

— Доступ по индексу → O(n).
— Добавление/удаление в начало или конец → O(1).
— Вставка/удаление в середину → O(n).
— Итерация по списку → O(n), но эффективно, так как используется последовательный проход по ссылкам.

⚖️ Важные нюансы

— В отличие от ArrayList, в LinkedList нет операций с массивами и «ресайзинга».
— Но расходует больше памяти: каждый узел хранит не только элемент, но и две ссылки (prev/next).
— Итераторы fail-fast: изменение списка во время обхода бросает ConcurrentModificationException.

🔄 Итераторы и Deque

LinkedList реализует Deque, что делает его удобным для очередей и стеков. Offer, poll, peek работают за O(1). Push/pop превращают список в стек.

🧮 Когда использовать

На практике ArrayList почти всегда быстрее по времени и эффективнее по памяти.
LinkedList может быть полезен только в редких случаях, когда нужны очень частые вставки/удаления в середину коллекции (без итерации по коллекции) и не важен доступ по индексу. В остальных случаях выбирайте ArrayList.

🔗 Документация: OpenJDK — LinkedList source | Официальная JavaDoc (Java 17)

Ставьте 🔥, если хотите такой же пост по другим коллекциям, например CopyOnWriteArrayList.

🐸 Библиотека джависта

#CoreJava

🐸 Библиотека джависта

#DevLife

🧩 final vs finally vs finalize()

Казалось бы, три похожих ключевых слова → final, finally, finalize(). А смысл принципиально разный. Давайте разберёмся.

🔹 final

Модификатор, который делает сущность неизменяемой:

▪️ final переменная → нельзя переприсвоить.
▪️ final метод → нельзя переопределить.
▪️ final класс → нельзя наследовать.

Используется для обеспечения immutability и контрактов в коде.

🔹 finally

Блок в try-catch, который выполняется всегда (даже если выброшено исключение).

Гарантирует освобождение ресурсов:

try {
FileReader reader = new FileReader("data.txt");
} catch (IOException e) {
e.printStackTrace();
} finally {
System.out.println("Закрываем ресурсы");
}

🔹 finalize()

Метод класса Object, вызываемый GC перед удалением объекта. Используется редко, считается устаревшим (deprecated с Java 9, удалён в Java 18).

Минус: непредсказуемое время вызова.

Современная альтернатива: try-with-resources или явная очистка.

💡 Вывод

final → контроль изменяемости.
finally → контроль завершения.
finalize() → контроль очистки (но не используйте).

🐸 Библиотека джависта

#CoreJava

Поставиллайк

🐸 Библиотека джависта

#DevLife

🐸 Библиотека джависта

#DevLife

🎮 DevTools на каждый день

Тут собраны самые популярные и эффективные инструменты для разных направлений: IDE, ИИ, безопасность и многое другое.

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

🐸 Библиотека джависта

#Enterprise

⚡️ Optional: must-have или лишний шум?

✔️ "За" Optional
— Убирает null-ы из кода
— Более читаемая и безопасная API
— Стандартный инструмент, без сторонних либ

❌ "Против" Optional
— Часто приводит к избыточным обёрткам
— Усложняет код при массовом использовании
— Всё равно не решает проблему null на 100%

💬 В комментах напишите, где используете Optional в проде.

🐸 Библиотека джависта

#DevLife

🔍 Просто о сложном: Spring Boot

Spring Boot — это не «новый фреймворк», а надстройка над Spring, которая убирает рутину и ускоряет разработку.

В обычном Spring нужно было вручную конфигурировать всё: от DataSource до DispatcherServlet. В Boot это делается автоматически через автоконфигурацию.

🔹 Как работает автоконфигурация

Spring Boot сканирует зависимости и classpath, а затем подключает нужные бины:

— Если у вас есть spring-boot-starter-data-jpa, Boot автоматически создаст EntityManagerFactory, DataSource, транзакционный менеджер.

— Если добавлен spring-boot-starter-web, он поднимет встроенный Tomcat/Jetty и зарегистрирует контроллеры. И так далее.

Магия кроется в аннотации @EnableAutoConfiguration (включается через @SpringBootApplication). Она загружает META-INF/spring.factories → список классов-конфигов → каждый проверяет условия @ConditionalOnClass, @ConditionalOnMissingBean и решает: активироваться или нет.

💡 Почему это работает так гладко

Потому что в Boot сотни готовых конфигураций «на все случаи жизни».

Фактически, это огромная библиотека «если увидишь X — настрой Y».

👀 Подводный слой магии

— Черный ящик

Легко забыть, что именно сконфигурировал Boot. Иногда приходится «копать» в автоконфигурацию, чтобы понять, какой бин реально используется.

— Избыточные зависимости

Подключив Starter, можно случайно притащить половину экосистемы Spring. Это увеличивает время старта и усложняет дебаг.

— Конфликт настроек

Собственная конфигурация может пересечься с автоконфигурацией.

⚡️ Хорошая практика

— Не доверяйте «чёрному ящику»: при старте приложения смотрите Spring Boot Actuator и логи автоконфигурации.

— Знайте про --debug при старте: он показывает, какие автоконфигурации включены или отключены.

— В продакшене лучше контролировать, какие именно стартеры вы тянете. Иногда spring-boot-starter-web приносит в проект в три раза больше, чем реально нужно.

🎯 Итог

Spring Boot — это ускоритель, но не магия. Его сила в автоконфигурациях, а слабость в том, что легко потерять контроль.

Понимание того, как работает @EnableAutoConfiguration и условия @Conditional, отличает разработчика, который «просто пишет на Boot», от того, кто реально управляет приложением.

🐸 Библиотека джависта

#CoreJava

🔥 Spring Security: как работает @PreAuthorize и зачем он нужен

В продакшн-коде часто возникает задача ограничить доступ к методам сервиса или контроллера. Делать это вручную — значит плодить дублирование и путать бизнес-логику с проверками. Для этого в Spring Security есть аннотация @PreAuthorize.

🔵 Как это работает

1. Аннотация вешается на метод (контроллер или сервис).

2. При вызове метода Spring Security перехватывает обращение и проверяет условие, указанное в аннотации.

3. Условие описывается на языке SpEL (Spring Expression Language), где доступно:

▪️ authentication — текущий объект аутентификации;
▪️ principal — данные текущего пользователя;
▪️ #id, #dto и т.д. — аргументы метода, к которым можно обратиться напрямую.

Пример:

@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long id) { ... }

→ метод вызовется только для пользователей с ролью ADMIN.

🔵 Что можно писать внутри

— Проверка ролей и прав

hasRole('USER'), hasAnyRole('ADMIN','MODERATOR')

hasAuthority('SCOPE_read') (актуально при работе с OAuth2)

— Собственные условия

@PreAuthorize("#id == authentication.principal.id")
public UserProfile getProfile(Long id) { ... }

→ Здесь доступ только к своему профилю.

— Комбинации условий

Логика пишется прямо в SpEL:

@PreAuthorize("hasRole('ADMIN') or @securityService.isOwner(#docId)")
public Document update(Long docId) { ... }

— Сервисы внутри выражений

В выражение можно подключать свои бины:

@PreAuthorize("@reviewSecurity.isOwner(#id, authentication)")
public Review update(Long id) { ... }

→ бин reviewSecurity должен быть в контексте Spring и возвращать true/false.

🔵 Зачем это нужно

— Не надо вручную писать проверки в каждом методе.

— Авторизация централизована и читается прямо на уровне API.

— Условия можно вынести в отдельный сервис, чтобы не захламлять аннотацию.

👉 В итоге @PreAuthorize — это не только про роли, а про гибкий DSL проверки доступа, который можно расширять под проект: от банальной проверки ролей до бизнес-логики уровня "пользователь может редактировать только свои документы, если они ещё не опубликованы".

🐸 Библиотека джависта

#Enterprise