🆕 Java Digest: Java 25, кэширование и оптимизация Maven

Топ-3 статьи о Java за неделю по мнению нашего канала. Нововведения Java 25, паттерны кэширования для микросервисов и оптимизации сборки с помощью Maven.

1️⃣ PVS-Studio: Нововведения Java 25

PVS-Studio в своей статье подробно рассматривает нововведения в Java 25, включая новые API, улучшения синтаксиса и поддержку функционального программирования.

Cтоит отметить появление ScopedValue, который решает проблемы с ThreadLocal, а также возможность использования компактных исходных файлов и методов main.

2️⃣ OTUS: Пять производительных паттернов кэширования

В статье от OTUS рассматриваются пять основных паттернов кэширования, которые могут значительно повысить производительность микросервисов. Каждый паттерн, от Cache-Aside до Write-Back Cache, имеет свои особенности и сценарии применения.

3️⃣ Spring АйО: Maven — verify или clean install

Особенно рекомендую статью от Spring АйО. Всегда использовал mvn clean install, и, думаю, так делают многие из вас.

Статья посвящена вопросам оптимизации сборки проектов с использованием Maven. Также обсуждается, когда можно обойтись без clean install.

💬 Пишите, понравилась ли подборка?

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

#News

👀 Задача с собеса: Поиск наибольшей общей подпоследовательности (LCS) (mid+)

Найдите длину наибольшей общей подпоследовательности (LCS) двух строк:

— Даны две строки A и B.
— Нужно найти длину наибольшей общей подпоследовательности между ними.

▪️ Условия

1. Строки могут быть длиной до 1000 символов.
2. Используйте динамическое программирование для решения.
3. Подсчитайте длину LCS.

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

— Используйте таблицу для хранения промежуточных результатов.
— Если символы в строках совпадают, то прибавляйте 1 к предыдущему значению. Если не совпадают — выбирайте максимум из предыдущих значений.
— Убедитесь, что алгоритм работает с большими строками за время O(n*m), где n и m — длины строк.

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

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

👑 Магия IntelliJ IDEA: Multi-Caret Editing

Хотите править код сразу в нескольких местах? Multi-Caret Editing позволяет поставить несколько курсоров и синхронно редактировать текст.

🔹 Что делает

— Позволяет редактировать одинаковые участки кода одновременно
— Ускоряет массовое переименование переменных, правки форматирования и шаблонных конструкций
— Работает не только в коде, но и в файлах конфигурации, JSON, XML

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

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

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

— Выделите слово и нажмите Alt+J (Windows/Linux) или Ctrl+G (macOS) — добавится второй курсор
— Продолжайте нажимать, чтобы выбрать следующие вхождения
— Для выбора сразу всех вхождений используйте Ctrl+Alt+Shift+J
— Для произвольных позиций используйте Alt+Click для добавления курсора в нужное место

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

#Enterprise

📈 Big-O ≠ производительность

Часто выбор коллекции ограничивается только таблицей сложностей и на этом всё.

Но реальный кейс сложнее: средняя сложность ≠ реальная скорость в продакшне. JVM, кэш процессора, GC и паттерны доступа могут радикально поменять картину.

🔑 Главная мысль

Выбирайте коллекцию под сценарий использования, а не “по самой быстрой ячейке в таблице”.

1️⃣ ArrayList — быстр в чтение, но не во вставке

ArrayList хранит элементы в массиве → локальность памяти + CPU кэш → итерации летят.
Вставка в середину за O(n), но при небольших списках разница с LinkedList исчезающе мала.

🔧 Паттерн использования:

— 90% чтение, редкие вставки → идеально.
— Если заранее известно примерное кол-во элементов → задайте initialCapacity, иначе ArrayList будет несколько раз пересоздавать массив (copy O(n) на каждом росте).

📌 Факт:

В бенчмарках JMH даже при вставке в середину ArrayList часто быстрее LinkedList просто потому, что LinkedList платит за “pointer chasing” (скачки по памяти, cache-miss).

2️⃣ LinkedList — звучит круто, но редко нужен

Да, вставка/удаление в начало или конец за O(1).
Но get(i) = O(n), и каждый шаг = новый объект, новая ссылка → нагрузка на GC.

🔧 Паттерн использования:

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

📌 Факт:

LinkedList ест больше памяти: на каждый элемент два указателя + объект-узел.

3️⃣ HashMap / HashSet — быстрые, пока не наступил resize

HashMap даёт O(1) доступ при хорошем hashCode().

Но:
— Если хэши “плохие” → коллизии → O(log n)
— При достижении load factor 0.75 → resize → перераспределение всех бакетов (дорогая операция).

🔧 Паттерн использования:

— Когда нужен быстрый поиск по ключу без сохранения порядка или когда важно хранить уникальные элементы или строить словари/кэши по ключу.
— Если знаете примерное кол-во элементов → сразу задайте кол-во элементов в конструкторе new HashMap<>(N).

📌 Факт:

Начиная с Java 8 при коллизии, когда LinkedList становится длинным (по умолчанию ≥ 8 элементов) → список превращается в красно-чёрное дерево.

4️⃣ TreeMap / TreeSet — порядок стоит денег

Дают O(log n) доступ и всегда хранят ключи отсортированными.
Но если сортировка нужна редко, дешевле собрать HashMap и вызвать sorted() на стриме.

🔧 Паттерн использования:

— Когда важно поддерживать сортировку на каждой операции (напр. Top-N задач в приоритетной очереди).
— Не храните mutable-ключи, т.к. можно “потерять” элемент при изменении поля, участвующего в compareTo.

📌 Факт:

TreeMap хранит узлы с балансировкой (красно-чёрное дерево) → накладные расходы на память + сравнения ключей.

5️⃣ LinkedHashMap — скрытый герой для кэшей

LinkedHashMap поддерживает порядок вставки или порядок доступа (accessOrder=true).
Можно сделать LRU-кэш, переопределив removeEldestEntry.

🔧 Паттерн использования:

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

📌 Факт:

Каждый get() в режиме accessOrder вызывает перестановку в двусвязном списке → небольшие накладные расходы.

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

#CoreJava

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

#DevLife

🎯 Интеграционные тесты с Testcontainers

Пошаговая настройка тестов на Spring Boot 3 с Testcontainers + PostgreSQL: быстро, изолированно, воспроизводимо.

1️⃣ Зависимости (Maven/Gradle)

— Maven (pom.xml):

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-bom</artifactId>
<version>1.20.3</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>postgresql</artifactId>
<scope>test</scope>
</dependency>
</dependencies>

— Gradle (Kotlin DSL):

dependencies {
implementation("org.springframework.boot:spring-boot-starter-data-jpa")
testImplementation("org.flywaydb:flyway-core")
testImplementation("org.postgresql:postgresql")
testImplementation(platform("org.testcontainers:testcontainers-bom:1.20.3"))
testImplementation("org.testcontainers:junit-jupiter")
testImplementation("org.testcontainers:postgresql")
}

2️⃣ Включаем Testcontainers

C Spring Boot 3.1 контейнер можно подключить одной аннотацией без ручного прописывания spring.datasource.*.

@Testcontainers
@ExtendWith(SpringExtension.class)
@SpringBootTest
class PostgresIT {

@Container
@ServiceConnection // Spring сам подставит URL/логин/пароль в DataSource
static PostgreSQLContainer<?> postgres =
new PostgreSQLContainer<>("postgres:16-alpine")
.withDatabaseName("app")
.withUsername("app")
.withPassword("secret");

@Test
void contextLoads() {
// проверяем, что контекст и datasource поднялись на контейнере
}
}

3️⃣ Миграции для тестов (Flyway)

Положите миграции в src/test/resources/db/migration (отдельно от продовых — удобно для фикстур):

src/
└─ test/
└─ resources/
└─ db/
└─ migration/
├─ V1__init.sql
└─ V2__seed.sql

4️⃣ Ускоряем прогоны

▪️ Reusable containers (кэшируемый демон): добавьте в ~/.testcontainers.properties

testcontainers.reuse.enable=true

и .withReuse(true) для контейнера в тесте.

▪️ Singleton-паттерн контейнера: вынесите контейнер в общий абстрактный класс теста, чтобы один контейнер работал на все тесты.

5️⃣ Полезные трюки и подводные камни

— Если на MacOS/Colima, проверьте доступность Docker API (docker info) перед тестами.
— Для детерминизма фиксируйте теги образов (например, postgres:16-alpine), не latest.
— Логи контейнеров доступны: postgres.followOutput(...) — удобно для диагностики нестабильных тестов.
— Если нужен R2DBC: поднимайте Postgres как выше, а в application-test.yml указывайте r2dbc URL; @ServiceConnection корректно сконфигурирует оба коннектора, если они в classpath.
— Тяжёлые фикстуры → создавайте через SQL-маски (V*_seed.sql) или @Sql прямо в тестах — не смешивайте тестовые данные с продовыми миграциями.

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

#Enterprise

💎 Как работает String.intern() под капотом

Многие знают, что строки в Java «живут в пуле». Но что реально происходит, когда мы вызываем intern()?

1️⃣ Что такое String Pool

Java хранит все строковые литералы в специальной области памяти — String Intern Pool. Зачем? Чтобы одинаковые строки не занимали память несколько раз.

String a = "hello";
String b = "hello";
System.out.println(a == b); // true

Обе ссылки указывают на одну и ту же строку из пула.

2️⃣ Как работает intern()

Если вызвать s.intern():

— JVM проверит, есть ли такая строка в пуле.
— Если есть, вернёт ссылку на неё.
— Если нет, добавит текущую строку в пул и вернёт ссылку.

Пример:

String x = new String("world");
String y = x.intern();
String z = "world";

System.out.println(x == z); // false
System.out.println(y == z); // true

3️⃣ Под капотом JVM

🔹 До Java 7 String Pool находился в PermGen → можно было легко словить OOM.
🔹 Начиная с Java 7 (HotSpot) пул перенесли в heap, что сильно упростило жизнь.
🔹 Реализация — ConcurrentHashMap внутри JVM, так что intern() потокобезопасен.

4️⃣ Где это полезно

🔹 Оптимизация памяти при большом количестве одинаковых строк (например, при парсинге XML/JSON).
🔹 Сравнение строк через == (только если они гарантированно interned).
🔹 При работе с ключами в больших мапах, чтобы уменьшить дубли.

5️⃣ Подводные камни

🔹 intern() не бесплатен — поиск в пуле и вставка стоят ресурсов.
🔹 Чрезмерное использование может привести к росту heap-а и GC-паузам.
🔹 Нельзя бездумно использовать вместо обычных строк → легко получить деградацию.

🔗 Документация: String.intern()

💬 Использовали когда-нибудь intern() в продакшене?

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

#CoreJava

📌 Как пользоваться тегами в канале

Чтобы вам было проще ориентироваться в постах, мы разделили весь контент по 4 основным направлениям:

🔹 #CoreJava — фундаментальные знания: JVM, JDK, ООП, многопоточность, паттерны и базовые концепции. Всё, что помогает понимать Java глубже, а не просто «писать код, чтобы работало».

🔹 #Enterprise — прикладные инструменты и практика: Spring, Hibernate, Kafka, Docker, микросервисы. Всё, что встречается в работе разработчика каждый день.

🔹 #DevLife — сообщество и карьера: мемы, холивары, задачи с собесов, советы по развитию и личные рубрики. Всё, что создаёт атмосферу и объединяет нас как комьюнити.

🔹 #News — дайджесты, свежие анонсы, релизы и новости. А также реклама и инфоповоды, которые стоит знать.

👉 Используйте теги, чтобы быстро находить посты по интересующей теме.

💬 Расскажите о странной или забавной таске?

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

#DevLife

🚀 Релиз Java 25

Сегодня, 16 сентября 2025 года, вышла Java 25, новая версия с долгосрочной поддержкой (LTS). Выпуск включает 18 JEP'ов, среди которых как стабильные, так и экспериментальные и предварительные.

🔹 Полезные новшества:

— JEP 502: Stable Values. Введение нового типа для неизменяемых объектов с отложенной инициализацией.

— JEP 505: Structured Concurrency. Упрощение работы с многозадачностью.

— JEP 506: Scoped Values. Новый способ передачи неизменяемых данных между потоками.

— JEP 513: Flexible Constructor Bodies. Упрощение написания конструктора с кодом до вызова родительского конструктора.

🔹 Не очень важные:

— JEP 512: Compact Source Files. Убирает необходимость в public static void main(String[] args) — интересно только для скриптов и быстрых утилит.

— JEP 511: Module Import Declarations. Упрощение импорта классов и интерфейсов из модулей, хотя это и так на себя берёт IDE.

— JEP 470: PEM Encodings of Cryptographic Objects. Нужно для специфических криптографических нужд, но для большинства проектов — не критично.

— JEP 510: Key Derivation Function API. Обеспечивает работу с производными ключами, но для большинства приложений не станет приоритетом.

— JEP 521: Generational Shenandoah. Улучшения в сборщике мусора для специфических сценариев — для обычных проектов изменения не значительны.

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

#News

💬 Удалёнщики + в комменты

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

#DevLife

⚙️ Byteman

Byteman — это фреймворк для «инъекций» в байткод во время выполнения. Он позволяет менять поведение Java-программ без пересборки и изменения исходного кода.

📌 Фичи:

— Правила-инъекции на DSL (можно подмешать логику в любой метод).
— Удобен для тестирования сложных сценариев (например, эмуляция исключений или задержек).
— Поддержка динамической подгрузки/удаления правил без перезапуска приложения.
— Используется для отладки, тестирования отказоустойчивости и профилирования.

💡 Особенно полезен, когда нужно воспроизвести «трудноуловимый баг» или проверить поведение системы под нестандартными условиями.

🔗 Byteman

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

#Enterprise

🔍 Просто о сложном: ORM в Java

ORM (Object-Relational Mapping) — это мост между объектами Java и реляционными базами данных. Вместо того, чтобы писать SQL-запросы руками, вы работаете с привычными объектами и методами.

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

В Java идет работа с классами, полями, методами. В базе данных всё хранится в виде таблиц, строк и столбцов. ORM выступает «переводчиком»:

— Таблица ↔️ Класс
— Строка ↔️ Объект
— Столбец ↔️ Поле

ORM берёт на себя «грязную работу»:

1. При создании объекта в коде (new User("Alex")) и вызове save(), ORM формирует SQL-запрос INSERT INTO users (name) VALUES ('Alex') и отправляет его в базу.

2. Когда вы хотите достать данные (userRepository.findById(1)), ORM делает SELECT * FROM users WHERE id=1, создаёт объект User и наполняет его полями из результата запроса.

3. Если вы меняете поле (user.setName("Ivan")) и сохраняете, ORM сгенерирует UPDATE users SET name='Ivan' WHERE id=1.

4. Если объект больше не нужен и вы вызываете delete(), ORM сформирует DELETE FROM users WHERE id=1.

То есть вы оперируете объектами и методами, а ORM переводит ваши действия в SQL и обратно.

🔹 Плюсы ORM

— Меньше шаблонного кода. Не нужно постоянно писать INSERT, SELECT, UPDATE.

— Более читаемо. Идет работа с методами вроде userRepository.findByEmail(), а не с SQL запросами.

— Кросс-СУБД. ORM умеет подстраиваться под разные базы (PostgreSQL, MySQL, Oracle).

— Интеграция. Легко комбинируется со Spring и другими фреймворками.

🔹 Минусы ORM

— Иллюзия простоты. Кажется, что можно забыть про SQL, но «под капотом» всё равно генерируются запросы.

— Проблема N+1. Частая ошибка, когда ORM делает сотни мелких запросов вместо одного «жирного».

— Сложные кейсы. Для тяжёлой аналитики или оптимизации всё равно пишут чистый SQL или хранят процедуры.

— Производительность. ORM добавляет прослойку, которая может стать узким местом при больших нагрузках.

🔹 Типичные ловушки ORM

— Ленивая загрузка (Lazy Loading). Может неожиданно тянуть данные из БД в середине транзакции.

— Кэширование. ORM кэширует объекты, но если работать невнимательно, то легко получить «старые» данные.

— Транзакции. Многие забывают, что ORM не волшебная палочка: без грамотной работы с транзакциями данные могут остаться в полупрозрачном состоянии.

🔹 Основные инструменты в Java

— JPA (Java Persistence API). Стандарт, описывающий, как именно должны работать ORM-инструменты.

— Hibernate. Самый популярный провайдер JPA, фактический стандарт в экосистеме Java.

— EclipseLink, OpenJPA. Альтернативные реализации, реже используемые.

— Spring Data JPA. Надстройка над JPA, позволяющая писать репозитории и автогенерировать запросы из названий методов.

🔹 ORM или не ORM

✔️ ORM полезен, если:

— Приложение типовое (CRUD, REST API, веб-сервисы)
— Важна скорость разработки и поддерживаемость
— Команда не хочет тратить часы на ручные SQL-запросы

❌ ORM мешает, если:

— Высоконагруженная система с миллионами записей
— Важен каждый миллисекундный отклик
— Есть сложная аналитика или отчёты (там SQL быстрее и прозрачнее)

📌 Итог

ORM — это «помощник», а не замена знаний SQL. Он снимает рутину и ускоряет разработку, но требует грамотного использования. Понимать, что происходит «под капотом», — ключ к тому, чтобы не наступать на грабли.

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

#CoreJava

✅ Чек-лист по Spring Boot профилям

Чтобы не путаться в окружениях и не тащить dev в прод 🚨 — держите компактный список best practices.
Карточка для сохранения👆🏻

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

#Enterprise

Приглашаем на Java Jam — бесплатный митап ЮMoney для Java-разработчиков 🔥

Спикеры из ЮMoney и главный эксперт по технологиям Сбера расскажут о своём опыте и пообщаются с аудиторией.

Вот какие темы будут на митапе:

🟣 Как мы уменьшали нагрузку на базы данных в очередях задач. Расскажем, как реализовать надёжное асинхронное и отложенное исполнение задач.
🟣 Советы по производительному коду. Поговорим про время выполнения программ, работу со строками и коллекциями, вещественную и битовую арифметику, алгоритмические трюки и многое другое.
🟣 Уязвимости не пройдут. Обсудим, как повысить безопасность разработки с помощью SAST и SCA.

25 сентября, в четверг, в 18:30 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн.

Зарегистрируйтесь, чтобы принять участие. Все подробности — на сайте митапа Java Jam™