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

#DevLife

🔥 Как подключить Keycloak к Spring Boot проекту

Keycloak — это современный open-source Identity Provider от Red Hat, который часто используется в enterprise-проектах для SSO (Single Sign-On), OAuth2 и OpenID Connect. Ниже — пошаговая настройка интеграции Keycloak с Spring Boot 3 и Spring Security 6.

1️⃣ Зависимости

Проверьте, что в проекте есть или добавьте следующие зависимости:

— Spring Web
— Spring Security
— OAuth2 Resource Server
— OAuth2 Client

2️⃣ Разворачиваем Keycloak

Запустите Keycloak через Docker:

docker run -d \
  -p 8080:8080 \
  -e KEYCLOAK_ADMIN=admin \
  -e KEYCLOAK_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:25.0.2 start-dev

После запуска откройте http://localhost:8080, войдите под admin/admin и создайте realm, например demo-realm.

3️⃣ Настройка клиента в Keycloak

В разделе Clients → Create client укажите:

— Client ID: spring-client
— Client Protocol: openid-connect
— Root URL: http://localhost:8081

В разделе Settings:

— Установите Access Type → confidential
— Включите Standard Flow Enabled
— Укажите Redirect URI: http://localhost:8081/login/oauth2/code/keycloak

Сохраните и перейдите на вкладку Credentials — скопируйте Client Secret.

4️⃣ Настройка application.yml

server:
  port: 8081

spring:
  security:
    oauth2:
      client:
        registration:
          keycloak:
            client-id: spring-client
            client-secret: YOUR_CLIENT_SECRET
            scope: openid, profile, email
            redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
        provider:
          keycloak:
            issuer-uri: http://localhost:8080/realms/demo-realm

5️⃣ Конфигурация безопасности

Настройте SecurityConfig.java:

@Configuration
public class SecurityConfig {

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/", "/public").permitAll()
.anyRequest().authenticated()
)
.oauth2Login(Customizer.withDefaults())
.logout(logout -> logout
.logoutSuccessUrl("/")
.invalidateHttpSession(true)
);
return http.build();
}
}

🧠 Зачем это нужно:

Keycloak снимает с вас головную боль по хранению паролей, управлению ролями и сессиями. Он интегрируется с LDAP, AD, SAML и десятками внешних OAuth-провайдеров.

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

#Enterprise

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

ConcurrentHashMap — это потокобезопасная реализация хэш-таблицы из пакета java.util.concurrent. В отличие от обычного HashMap, он допускает одновременные операции чтения и записи без глобальной блокировки всей таблицы.

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

Внутри ConcurrentHashMap хранит данные в массиве Node<K,V>[] table, где каждый элемент массива — это цепочка (связанный список или дерево).

Главная особенность:
— Вся таблица не блокируется целиком.
— Блокируется только нужный бакет при изменении.
— Для мелких структур используется synchronized на уровне ноды, для больших — tree bin locks (аналог TreeMap).

🔍 Как устроено хранение

— При вставке ключ хэшируется, чтобы равномерно распределить данные по бакетам.
— Каждая ячейка может содержать:
• Node — обычная запись (ключ/значение/ссылка).
• TreeBin — сбалансированное дерево при переполнении бакета (>8 элементов).
— Чтения (get) работают без блокировок, просто читают volatile-ссылки.

⚡️ Операции вставки и удаления

— put(K key, V value):

1. Высчитывается индекс бакета.
2. Если ячейка пустая, создаётся новая нода через CAS (Compare-And-Swap).
3. Если нет, блокируется только этот бакет (synchronized (f)), выполняется вставка.

— remove(Object key):

1. Определяется бакет.
2. Захватывается локальная блокировка на уровне бакета.
3. Узел удаляется, при необходимости структура перестраивается.

Сложность операций — O(1) в среднем случае, но с учётом блокировок.

🌊 Итераторы

Итераторы в ConcurrentHashMap — weakly consistent:
— Не выбрасывают ConcurrentModificationException.
— Видят часть изменений, сделанных другими потоками (в отличие от CopyOnWriteArrayList).
— Итерация не требует блокировок и не мешает параллельным вставкам или удалению.

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

— get() → практически O(1), без блокировок.
— put() / remove() → O(1) в среднем, но с локальной синхронизацией.
— Итерация → O(n), стабильная, но может не отражать все изменения.

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

— С 8-й Java ConcurrentHashMap отказался от сегментов (Segment[]), теперь всё управляется атомарными операциями CAS и локальными синхронизациями.
— Не допускает null ключей и значений (в отличие от HashMap).
— Внутри используется LongAdder для счётчиков, чтобы избежать ложного sharing-а.

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

— Часто читаемые и обновляемые словари (например, кэш, статистика, счётчики).
— Реализация пулов подключений, очередей задач, метрик и хранилищ состояний.
— Когда важно масштабирование под многоядерные системы без глобальных блокировок.

❗️ Не использовать, если:

— Обновления редки → Collections.synchronizedMap проще и дешевле.
— Нужен строгий порядок → лучше ConcurrentSkipListMap.

🔗 Документация: JavaDoc (Java 17)

Ставьте 🔥, если хотите разбор ConcurrentSkipListMap или LinkedBlockingQueue.

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

#CoreJava

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

#DevLife

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

#DevLife

⌛ Сохраняйте шпаргалку по командам docker

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

#Enterprise

💻 Hardware для Java-разработки в 2025

За последние несколько лет я видел всё: от героических попыток поднять Spring Boot на 4GB RAM до сборок, где даже хром со 100+ вкладками IDEA + микросервисы + инфра в докере не вешает систему.

🤔 Интересно узнать реальную картину по рынку.

Что компании реально предоставляют разработчикам? С какими конфигурациями вы работаете комфортно, а где начинаете упираться в потолок?

💬 Поделитесь опытом:

— Модель и конфигурация вашего рабочего ноутбука
— Достаточно ли мощности для ваших задач

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

#DevLife

🔍 Просто о сложном: CompletableFuture

В Java 8 появился CompletableFuture — это реализация паттерна Promise, которая позволяет строить декларативные цепочки асинхронных операций.

По сути, это обёртка над Future, которая может быть завершена вручную (отсюда "Completable") и предоставляет богатый API для композиции.

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

Классический Future не позволяет:

— Комбинировать несколько асинхронных операций.
— Обрабатывать результат без блокировки.
— Реагировать на ошибки внутри цепочки.

CompletableFuture решает эти проблемы, предоставляя fluent API для композиции асинхронных вычислений.

🔹 Базовый пример

javaCompletableFuture<String> future = CompletableFuture
    .supplyAsync(() -> fetchUserFromDB(userId))
    .thenApply(user -> user.getEmail())
    .thenApply(String::toUpperCase)
    .exceptionally(ex -> "default@example.com");

future.thenAccept(System.out::println); // не блокирует

Здесь каждый этап выполняется асинхронно. Если где-то произошла ошибка, сработает exceptionally().

🔹 Ключевые методы

▪️ supplyAsync() / runAsync() — запустить задачу асинхронно.
▪️ thenApply() — трансформировать результат.
▪️ thenAccept() — обработать результат (void).
▪️ thenCompose() — развернуть вложенный CompletableFuture.
▪️ thenCombine() — объединить результаты двух независимых future.
▪️ exceptionally() / handle() — обработка ошибок.
▪️ allOf() / anyOf() — дождаться завершения нескольких задач.

🔹 Пулы потоков

По умолчанию CompletableFuture использует ForkJoinPool.commonPool(). Для задач с блокирующими операциями (IO, БД) лучше передать свой Executor. Иначе можно заблокировать общий пул и замедлить всё приложение.

🔹 Подводные камни

— Отсутствие отмены

CompletableFuture.cancel() не останавливает выполнение задачи, а только меняет статус. Реальная отмена требует проверки Thread.interrupted() внутри задачи.

— Проглатывание исключений

Если не добавить exceptionally() или handle(), исключение останется внутри future до вызова get() или join().

— Цепочки могут выполняться синхронно

Методы без суффикса Async (например, thenApply) могут выполниться в том же потоке, где завершился предыдущий этап. Если нужна гарантия асинхронности, используйте thenApplyAsync().

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

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

❌ Не подходит:

— Для CPU-bound задач с высокой конкуренцией (лучше использовать параллельные стримы или явное управление потоками).
— Когда важна отмена выполняющейся задачи.

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

#CoreJava

📋 Чек-лист Code Review

Собрал в один PDF всё, что нужно проверять при код-ревью — от архитектуры до безопасности. 75+ пунктов с цветовой маркировкой по приоритетам.

❓ Зачем?

Чтобы ничего не упустить и держать единый стандарт качества в команде.

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

Открываете при каждом PR, идёте по чек-листу. Красные пункты — критично, жёлтые — важно, белые — рекомендации.

Адаптируйте под свой проект и дополняйте на основе опыта команды.

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

#Enterprise

🎧 Что послушать — #подкаст Javaswag #81

🔹 Дата выпуска: 6 сентября 2025
🔹 Ведущий: Дмитрий Волыхин
🔹 Гость: Михаил Поливаха
🔹 Продолжительность: 1 час 56 минут

В выпуске обсуждают реактивное программирование и Open Source. Михаил рассказывает о своём опыте работы со стартапами, вкладе в открытые проекты, R2DBC, реактивных системах и спецификации реактивных потоков, а также делится взглядами на современные требования бизнеса и роль опыта в карьере разработчика.

🔹 Ключевые темы выпуска

00:00 — Начало
15:42 — Стартапы
19:04 — Культура стартапов или университетская жизнь
23:49 — ВУЗ или работа
28:30 — История про тимлида
30:42 — Город N
34:15 — Open Source
51:03 — Реактивное программирование
56:37 — R2DBC
01:00:46 — Open Source проекты
01:09:08 — Реактивная парадигма
01:11:02 — Реактивные системы
01:15:41 — Спецификация реактивных потоков
01:18:49 — Реактивное программирование и реляционные БД
01:23:09 — Непопулярное мнение
01:30:55 — Проблемы с производительностью
01:36:29 — Требования бизнеса
01:41:33 — Опыт уже не решает

🔗 Слушать выпуск

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

#DevLife