💬 Менеджер: важное звено разработки или скрытая угроза?😁

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

#DevLife

🎯 Spring Boot + Docker Compose: пошаговая интеграция

В проде редко гоняют приложения напрямую — почти всегда через Docker. А с появлением spring-boot-docker-compose интеграция стала проще: можно поднимать всю инфраструктуру (Postgres, Redis, Kafka и т.д.) одной командой вместе с приложением.

1️⃣ Подготовка зависимостей

В Spring Boot 3.1 добавили официальный стартер:

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-docker-compose</artifactId>
<scope>runtime</scope>
</dependency>

ИЛИ

dependencies {
runtimeOnly("org.springframework.boot:spring-boot-docker-compose")
}

2️⃣ docker-compose.yml

Определим инфраструктуру (например, Postgres + pgAdmin):

version: '3.8'
services:
postgres:
image: postgres:16-alpine
container_name: app-postgres
environment:
POSTGRES_DB: app
POSTGRES_USER: app
POSTGRES_PASSWORD: secret
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data

pgadmin:
image: dpage/pgadmin4
environment:
PGADMIN_DEFAULT_EMAIL: [email protected]
PGADMIN_DEFAULT_PASSWORD: secret
ports:
- "8081:80"
depends_on:
- postgres

volumes:
postgres_data:

3️⃣ Автоматическая интеграция

Spring Boot сам подтянет конфигурацию из docker-compose.yml. Просто укажите профиль:

./mvnw spring-boot:run -Dspring.profiles.active=compose

или

./gradlew bootRun --args='--spring.profiles.active=compose'

При старте Boot поднимет контейнеры и подставит spring.datasource.url, username, password.

4️⃣ Кастомизация application-compose.yml

Если нужны дополнительные параметры — кладём их в src/main/resources/application-compose.yml:

spring:
  datasource:
    hikari:
      maximum-pool-size: 5

5️⃣ Полезные приёмы

— Фиксируйте версии образов, а не latest (для воспроизводимости).

— Healthcheck в docker-compose.yml помогает Boot ждать готовности контейнера.

— Можно запускать docker compose up -d руками, если не хотите, чтобы Boot сам управлял контейнерами.

— Для CI/CD обычно используют отдельные docker-compose.override.yml или Helm чарты, но для дев-окружения spring-boot-docker-compose очень экономит время.

Ставьте 👍🏼, если нужен более подробный пост про настройку docker-compose.yml

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

#Enterprise

👀 Внутреннее устройства HashMap

HashMap — один из базовых и в то же время самых хитро устроенных контейнеров в JDK. На поверхности простая структура «ключ–значение», но под капотом она сочетает массивы, списки и даже деревья, чтобы оставаться быстрой в разных сценариях нагрузки.

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

HashMap хранит данные в массиве бакетов (Node<K,V>[] table). Каждый бакет — это «корзина» для элементов, чей hashCode после хеширования и применения & (n-1) (где n — длина массива) указывает на конкретный индекс.

🔑 Хэш и распределение

1. Вызов hashCode() у ключа.
2. Дополнительное хеширование (spread), чтобы снизить коллизии из-за плохой реализации hashCode.
3. Индекс бакета = hash & (table.length - 1).

🌊 Коллизии

Если несколько ключей попали в один бакет:

— до Java 8 это всегда был связанный список (linked list),

— начиная с Java 8: при росте числа элементов в бакете больше 8 и достаточном размере таблицы он превращается в сбалансированное красно-чёрное дерево. Это резко ускоряет поиск в «плохих» случаях (с O(n) до O(log n)).

⚡️ Ресайзинг

Когда количество элементов превышает capacity * loadFactor (по умолчанию 0.75), создаётся новый массив в 2 раза больше, все элементы перехешируются и раскладываются по новым бакетам. Это дорогостоящая операция, но благодаря амортизации остаётся приемлемой.

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

— Поиск/вставка/удаление в среднем: O(1).

— В худшем случае (плохой hashCode + коллизии): O(log n) благодаря деревьям.

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

— Ключи неупорядочены. Для упорядоченности есть LinkedHashMap.

— HashMap не потокобезопасен. Для многопоточной среды нужен ConcurrentHashMap или синхронизация.

— Хорошо реализованный hashCode и equals критичны, иначе получите «забитые» бакеты и деградацию.

🧮 loadFactor и capacity

— Capacity — размер массива бакетов. По умолчанию 16.

— LoadFactor — коэффициент заполнения. По умолчанию 0.75.

Почему именно 0.75? Это компромисс: выше → меньше памяти, но больше коллизий; ниже → быстрее доступ, но больше памяти уходит впустую. Capacity всегда степень двойки, чтобы можно было вычислять индекс через hash & (n-1) вместо затратного %.

🔄 Итераторы и fail-fast

Если во время обхода карта меняется (кроме iterator.remove()), бросается ConcurrentModificationException. Под капотом это работает через счётчик модификаций (modCount), который проверяется в каждом next().

🌳 Деревья в деталях

Коллизии превращаются в красно-чёрное дерево, если размер списка в бакете > 8 и общее количество бакетов ≥ 64. Обратно в список (untreeify) при падении количества элементов < 6. Это сделано, чтобы не тратить память и CPU на лишнюю балансировку при малых размерах.

🔗 Документация: OpenJDK — HashMap source

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

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

#CoreJava

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

#DevLife

Звучит как бизнес план😁

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

#DevLife

🚀 Java Rock Stars Meetup — 25 сентября, Москва

📍 Лофт Casa Picassa (м. Бауманская)
⏰ Начало в 17:30
💸 Бесплатно, нужна регистрация

✅ Что в программе:

• Оптимизация вставки данных в PostgreSQL
• Новинки Java 25 под капотом
• Дискуссия о будущем Spring в России + секретный анонс
• Нетворкинг и розыгрыш мерча

👉 Детали и регистрация: habr.com

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

#News

🔥 Вечерний холиварчик: стоит ли вообще посещать Java-конференции?

С одной стороны:

— живое общение, нетворкинг, свежие идеи и практики из первых уст
— возможность поговорить с авторами библиотек и топовыми инженерами
— комьюнити-движ и вдохновение

С другой стороны:

— иногда билеты стоят как половина MacBook'а
— многие доклады потом доступны на YouTube
— часть контента выглядит «для новичков», хотя и подаётся как «advanced»

💬 А как считаете вы: конференции — это must have или пустая трата времени?

#DevLife

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

В многопоточном коде даже простая операция count++ не является атомарной. Она распадается на три шага:

1. Прочитать значение переменной.
2. Увеличить его.
3. Записать обратно.

Если два потока выполнят это одновременно, получится гонка данных (race condition). Итоговое значение будет меньше ожидаемого.

🔹 Как решает проблему AtomicInteger

AtomicInteger — это класс из пакета java.util.concurrent.atomic, который предоставляет атомарные (неделимые) операции над целыми числами.

Под капотом он использует механизм CAS (Compare-And-Swap), который поддерживается на уровне процессора.

Принцип работы:
— Читаем текущее значение.
— Проверяем, не изменилось ли оно за это время.
— Если совпадает, записываем новое.
— Если нет, повторяем попытку (spin loop).

🔹 Пример использования

public class Counter {
private final AtomicInteger count = new AtomicInteger(0);

public void increment() {
count.incrementAndGet(); // атомарное ++
}

public int get() {
return count.get();
}
}

Здесь incrementAndGet() гарантирует, что два потока не «перетрут» друг друга, а каждый инкремент будет учтён.

🔹 Основные методы

▪️ get() — получить текущее значение.
▪️ set(int newValue) — установить новое значение.
▪️ incrementAndGet() / getAndIncrement() — инкремент.
▪️ decrementAndGet() — декремент.
▪️ addAndGet(int delta) — прибавить значение.
▪️ compareAndSet(int expect, int update) — вручную применить CAS.

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

— Спин-блокировки

CAS может крутиться в цикле, пока не удастся обновить значение. При высокой конкуренции это нагружает процессор.

— ABA-проблема

Значение могло измениться на «A → B → A». Для простых счётчиков это не критично, но в сложных структурах данных используют AtomicStampedReference.

— Ограниченность

AtomicInteger работает только с int. Для более сложных случаев есть AtomicLong, AtomicReference, LongAdder (оптимизирован для высокой конкуренции).

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

✔️ Подходит:

— Для простых счётчиков, метрик.
— В неблокирующих алгоритмах (lock-free).
— В высоконагруженных сценариях, где synchronized слишком дорог.

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

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

🔹 Итог

AtomicInteger — это лёгкий способ избавиться от гонок при работе с числами в многопоточности.

Это не магия, а всего лишь тонкая обёртка над CAS, встроенным в процессоры. Понимание этого механизма помогает писать по-настоящему безопасный и быстрый многопоточный код.

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

#CoreJava

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

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

#CoreJava

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

#DevLife

🛡 Role-Based Access Control (RBAC) в Spring Security

В корпоративных системах управление доступом часто становится узким местом — особенно когда речь идёт о гибкой настройке ролей и разрешений. Вместо ручного «if-else администрирования» можно подключить AI и быстро нагенерировать полноценный слой RBAC.

📝 Промпт:

Generate a Spring Security configuration for a Spring Boot 3 application with Role-Based Access Control (RBAC).

— Configure Spring Security with role-based access (ADMIN, USER, MANAGER).
— Implement method-level security with @PreAuthorize and SpEL expressions.
— Set up JWT authentication with custom claims (roles, permissions).
— Create a PermissionEvaluator for fine-grained access checks (e.g. entity-level access).
— Integrate with a database-backed UserDetailsService for dynamic role management.
— Add an admin API endpoint for managing roles and permissions at runtime.
— Ensure audit logging of access control decisions.

💡 Расширения:

— Добавьте Multi-tenancy support with tenant-aware role resolution.
— Добавьте Attribute-Based Access Control (ABAC) для сложных бизнес-правил.
— Добавьте Integration with Keycloak или OAuth2 provider для централизованного управления доступом.

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

#Enterprise

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

#DevLife

🆕 Java Digest: IDE, виртуальные потоки и OLAP-запросы

Топ-3 статьи о Java и смежных технологиях за неделю по версии нашего канала.

1️⃣ IDE для Java-разработчиков

Исследование по выбору IDE среди российских Java/Spring-разработчиков. Интересно посмотреть, как распределяются предпочтения между IntelliJ IDEA, VS Code и другими инструментами.

2️⃣ Подводные камни виртуальных потоков

Статья подробно разбирает, где виртуальные потоки Java могут подвести: от deadlock’ов и проблем с synchronized до нюансов работы с блокирующими API. Отличный разбор для тех, кто планирует использовать Project Loom в продакшене.

3️⃣ Оптимизация OLAP-запросов

Практика ускорения аналитических запросов: профилирование на уровне СУБД, Linux perf и eBPF-трассировка, методики Intel Top-down. Полезный материал для тех, кто работает с хранилищами данных и high-load аналитикой.

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

#News