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

#DevLife

⚡️ Почему record не взлетел даже для DTO

Казалось бы идеальная фича для DTO. Иммутабельность, компактный синтаксис, никакого Lombok.

Но есть одна деталь, которая всё портит. В record геттер называется name(), а не getName().

Звучит мелко? Но это нарушение JavaBean-конвенции, которой 20+ лет. И всё, что на ней завязано ломается или требует допиливания:

→ Jackson — заработал только с версии 2.12. До этого name() не распознавался как property вообще
→ ModelMapper — не видит аксессоры record из коробки, нужна ручная конфигурация
→ Swagger/OpenAPI-генераторы — генерируют дублирующиеся поля или теряют их
→ BeanUtils, PropertyUtils (Apache Commons) — не работают, ждут getName()
→ Любой легаси-код с рефлексией — Introspector.getBeanInfo() record не понимает

И это не баги инструментов — это осознанное решение команды Java. Они сказали: «Мы проектируем для нового кода, а не для поддержки старых конвенций».

Звучит красиво в теории. На практике в энтерпрайзе стек из легаси-либ, и record там как белая ворона.

💬 Работаете record'ами или обходите их стороной?

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava

🔥 Spring Boot мертв?

Наткнулся на реддите на обсуждение, что спринг бут уже не тот. Как по мне уже лет 10 пытаются похоронить спринг.

Сначала Quarkus, потом Micronaut.. «вот оно, будущее». Теперь ещё и virtual threads добавились в список «убийц».

А Spring Boot как стоял в проде у банков, ритейла и корпораций так и стоит.

💬 Пишите в комментарии своё мнение умрёт ли спринг 😁

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

#DevLife

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

#DevLife

✔️ Java-тест: бин-синглтон, который не синглтон

Работает у одного, но ломается у другого. В логах каша из чужих данных 👇

📦 Задание — code review

Команда добавила контекст текущего пользователя в сервис через поле. Локально — всё ок.
На проде с несколькими потоками — пользователи видят чужие данные.

@Service
public class ReportService {

    private User currentUser;
    private ReportFilter activeFilter;

    private final ReportRepository reportRepository;

    public ReportService(ReportRepository reportRepository) {
        this.reportRepository = reportRepository;
    }

    public void initContext(User user, ReportFilter filter) {
        this.currentUser = user;
        this.activeFilter = filter;
    }

    public List<Report> getReports() {
        if (currentUser == null) {
            throw new IllegalStateException("Context not initialized");
        }

        return reportRepository.findByUserAndFilter(
            currentUser.getId(),
            activeFilter
        );
    }

    public ReportSummary getSummary() {
        List<Report> reports = getReports();
        return ReportSummary.calculate(reports, currentUser);
    }
}

▪️ Объясни

— Какой скоуп у бина по умолчанию в Spring и почему это делает поля-состояния опасными.
— Почему synchronized над методами не является правильным решением здесь.
— Как переписать код, чтобы работало.

Ставьте → 🔥, если нравится формат. Если нет → 🌚

💬 Решения под спойлер. Сравним, какое будет лучше.

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

#practise

🦾 Надоело чинить «упавших» ИИ-агентов после каждого микросбоя внешних сервисов?

Анонсируем старт продаж большого курса по AgentOps. Мы собрали опыт десятков разработчиков и сделали программу, которая учит выводить ИИ в стабильный прод.

🗓 Ждем вас 28 апреля в 19:00 МСК на эфире: «Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены».

👉 Кто вещает и в чем польза?

Спикер Кирилл Кухарев (Senior AI Engineer в Raft, спикер AI Conf и Highload++). Он реализовал более 50 коммерческих проектов в GenAI и на вебинаре покажет, как взять под контроль работу нескольких агентов, чтобы они не перекидывали друг другу лишний контекст и не сжигали ваши деньги.

В прямом эфире разберем:
• Как формируется контекст в LLM при маршрутизации между агентами;
• Куда утекают лишние токены и возникает перерасход;
• Практические методы: как сжимать историю, грамотно делить задачи, лимитировать передачу контекста и собирать промпты прямо в процессе запроса пользователя.

🔥 Два способа получить максимум:

1. Приходите на вебинар 28 апреля. Дарим участникам промокод на 5.000 ₽ (работает 3 дня после эфира - это шанс забрать курс по самому низу рынка).

2. Выбирайте Инженерный трек. В подарок к нему идет полный доступ к записям и автопроверкам завершенного курса «Разработка ИИ-агентов».

👉 Занять место на вебинаре и стать профи в AgentOps

💬 Обратная связь

Какая рубрика нравится больше? Если забыли, о чём рубрика, можно освежить в памяти тут.

🔥 → #CoreJava
👍🏼 → #Enterprise
👾 → #DevLife
🤔 → #News
❤️ → Всё нравится :))

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

#DevLife

☕️ Магия JVM Flags

Запустите своё приложение с -XX:+PrintFlagsFinal, и вы увидите все настройки JVM.

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

— Показывает финальные значения всех JVM-флагов после применения эргономики, дефолтов и ваших переопределений.
— Полезно для Java-сервисов в контейнерах: вы думаете, что выставили -Xmx512m, а JVM видит 4GB хоста и живёт своей жизнью.
— Мгновенно отвечает на вопрос «а почему heap такой большой?».
— Работает на любом JDK без агентов, плагинов и прав суперпользователя.

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

— Дамп всех флагов при старте:

java -XX:+PrintFlagsFinal -version

— Только интересующее фильтруем через grep:

java -XX:+PrintFlagsFinal -version 2>&1 | grep -i heapsize

— Посмотреть, какой GC выбрала эргономика:

java -XX:+PrintFlagsFinal -version 2>&1 | grep -i "use.*gc"

— На живом процессе без рестарта:

jcmd <pid> VM.flags

jcmd <pid> VM.flags — особенно удобен в проде: не надо убивать процесс, видите текущее состояние прямо сейчас.

⚠️ Флаги делятся на три типа в выводе: product — обычный флаг, manageable — можно менять на лету через jcmd, diagnostic — требует -XX:+UnlockDiagnosticVMOptions. Если видите флаг, который хотите поменять, сначала смотрите его тип — сэкономит кучу времени на отладке.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

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

#DevLife

⚡️ Мы рады представить команду экспертов курса AgentOps!

— Дмитрий Антипов расскажет, как грамотно проверить работу AI-моделей
— Курилл Кухарев поделится, почему компаниям выгодно использовать локальные модели и как их развернуть
— Андрей Носов расскажет, как работать с данными и знаниями в AI-системах: построение RAG, выбор подходов к поиску и организация хранения данных
— Антон Будняк разберет, как обеспечить устойчивость сервиса, в котором используется ИИ
— Александр Ошурков расскажет, как оценивать качество работы LLM в backend-сервисах
— Екатерина Трофимов разберет, как проектировать инструменты для AI-агентов и выстраивать взаимодействие с внешними сервисами

Курс для backend-разработчиков, тимлидов и LLM инженеров о том, как внедрять AI-логику в бэкенд IT-продуктов и сохранять стабильность сервиса.

К концу обучения вы получите:

• Структурированный подход к архитектуре и деплою AI-агентов
• Навыки настройки мониторинга, тестирования и контроля расходов на токены
• Разбор сложных инженерных кейсов из реальной практики

🎁 Доступ к материалам курса «Разработка ИИ-агентов» в подарок при покупке Инженерного трека

👉 Все подробности и программа обучения.

🔧 Hibernate Batch Processing

@BatchSize и hibernate.jdbc.batch_size — две разные вещи, которые иногда путают. Разбираем обе.

🔹 Решение

▪️ JDBC batch insert/update

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 50          # отправлять INSERT пачками по 50
          order_inserts: true     # группировать INSERT по типу сущности
          order_updates: true     # то же для UPDATE
        cache:
          use_second_level_cache: false

Без order_inserts: true батчинг часто не работает. Hibernate вперемешку отправляет INSERT для разных таблиц, JDBC driver не может их объединить.

@Transactional
public void saveAll(List<Order> orders) {
    for (int i = 0; i < orders.size(); i++) {
        entityManager.persist(orders.get(i));
        if (i % 50 == 0) {
            entityManager.flush();
            entityManager.clear(); // освобождаем first-level cache
        }
    }
}

Без flush/clear каждые N записей first-level cache растёт до OOM при больших объёмах.

▪️ @BatchSize для загрузки коллекций

@Entity
public class Author {

    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY)
    @BatchSize(size = 25)
    private List<Book> books;
}

При загрузке 100 авторов и обращении к books — вместо 100 SELECT будет 4 (100/25). Hibernate собирает ID авторов в пачки и загружает WHERE author_id IN (?, ?, ..., ?).

Это не решение N+1, это смягчение его последствий. Правильное решение — JOIN FETCH или EntityGraph для конкретного запроса. @BatchSize — запасной вариант для случаев когда JOIN FETCH неприменим.

▪️ @BatchSize на уровне класса

@Entity
@BatchSize(size = 25)
public class Book { ... }

Работает для загрузки по ID: entityManager.find(Book.class, id) будет батчиться. Полезно при большом количестве lazy-загружаемых ссылок типа @ManyToOne.

▪️ Проверка что батчинг реально работает

spring:
  jpa:
    show-sql: true
  datasource:
    url: jdbc:postgresql://...?reWriteBatchedInserts=true  # для PostgreSQL

Для PostgreSQL нужен флаг reWriteBatchedInserts=true в URL — иначе JDBC драйвер отправляет запросы по одному даже при включённом батчинге Hibernate.

⚠️ Сущности с @GeneratedValue(strategy = IDENTITY) (auto-increment) не батчируются при INSERT — Hibernate вынужден получать ID после каждой вставки. Для батчинга используйте SEQUENCE стратегию с allocationSize равным batch_size.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

🗄 Как не «положить» базу данных?

В большинстве веб-приложений (например, Instagram или Twitter) соотношение чтения к записи составляет примерно 10 к 1. То есть люди в 10 раз чаще смотрят чужие посты, чем пишут свои. Эту особенность как раз можно использовать.

🔹 Репликация (Master-Slave / Leader-Follower)

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

— Master (Лидер): Это единственная база данных, в которую разрешено ПИСАТЬ (INSERT, UPDATE, DELETE).
— Slave (Ведомые/Реплики): Это точные копии Мастера. Из них можно ТОЛЬКО ЧИТАТЬ (SELECT).

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

1. Пользователь публикует фото. Запрос идет на Master-базу.
2. Master сохраняет фото и мгновенно отправляет новые данные всем своим Slave-копиям (реплицирует).
3. 1000 других пользователей открывают ленту. Их запросы на чтение распределяются между тремя Slave-базами.

Итог: нагрузка на чтение размазана, Мастер спокойно занимается только записью.

🔹 Шардирование (Sharding / Горизонтальное партиционирование)

Репликация спасает, когда много читают. Но что делать, если пользователи слишком много пишут (например, это система сбора логов или мессенджер)? Мастер перестает справляться.

Приходит время рубить данные на части - Шардировать.

Мы берем нашу огромную таблицу Users и разбиваем её на несколько независимых баз данных (шардов).

— Шард 1: хранит пользователей с ID от 1 до 1,000,000.
— Шард 2: хранит пользователей с ID от 1,000,001 до 2,000,000.

Каждый шард - это отдельный сервер со своим процессором и диском.

Сложность: теперь вашему приложению (или специальному роутеру) нужно понимать, в какую именно базу отправлять SQL-запрос. А сделать JOIN между таблицами, лежащими на разных серверах, становится практически невозможно.

🔹 Теорема CAP (закон распределенных систем)

Как только ваша база данных перестает жить на одном сервере и разъезжается на несколько (реплики или шарды), вступает в силу закон - теорема CAP.

Она гласит, что в распределенной системе вы можете выбрать только ДВА из ТРЕХ свойств:

1. C (Consistency / Консистентность): все клиенты видят одни и те же данные в один и тот же момент времени. Если я обновил аватарку на Мастере, следующий же запрос к любому Слейву должен вернуть новую аватарку.

2. A (Availability / Доступность): система всегда отвечает на запрос, даже если часть серверов сгорела.

3. P (Partition Tolerance / Устойчивость к разделению): система продолжает работать, даже если между серверами БД пропала сеть (они перестали видеть друг друга).

Суровая реальность: в интернете сеть пропадает всегда. Поэтому свойство P мы обязаны брать по умолчанию. Остается выбор между CP и AP.

🔵 Системы CP (Консистентные): банковские приложения. Если сеть между Мастером и Репликой упала, база откажется отдавать вам баланс, потому что боится отдать устаревшие данные. Лучше выдать ошибку, чем соврать.

🔵 Системы AP (Доступные): соцсети (Instagram, YouTube). Если вы поставили лайк, а сеть внутри дата-центра моргнула, ваш друг может еще пару минут не видеть этот лайк (данные не консистентны). Но сайт при этом не "лежит", лента листается.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

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

Собрали шпаргалку по Spring для тех, кто только начинает.

Карта экосистемы, главные аннотации и стартеры, типичные ошибки новичков всего на двух страницах.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#Enterprise

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

#DevLife

🗓 В следующий вторник (28.04) в 19:00 встречаемся в онлайне.

Тема:

Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены

В кружке Кирилл рассказал, какие именно подходы будем разбирать.

👉 Занять место на вебинаре

😮 Топ-вакансий для джавистов за неделю

Java-разработчик (GitFlic, гибрид) — от 200 000 ₽ — гибрид (Москва)

Java разработчик — 330 000 ₽ — гибрид/Удалёнка (Москве, Санкт-Петербург, Екатеринбург)

Senior Java Engineer (JavaSE, algorithms, optimization) — от 5 000 $ — удалёнка

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

⚙️ Compressed OOPs

На 64-битной JVM каждая ссылка на объект — это 64-битный указатель. При большом количестве объектов это заметно увеличивает потребление памяти и снижает эффективность кеша: меньше ссылок помещается в cache line. Compressed OOPs (Ordinary Object Pointers) — механизм, который решает эту проблему, но с нетривиальными последствиями при масштабировании heap.

🔹 Механика

JVM выравнивает объекты по 8 байт. Значит, три младших бита любого указателя всегда равны нулю и их можно не хранить. Если сдвинуть 32-битное значение влево на 3 бита, получим 35 бит адресного пространства — 32GB. Именно поэтому compressed oops работают при heap до 32GB: 32-битная "сжатая" ссылка декодируется в реальный 64-битный адрес сдвигом.

реальный адрес = сжатая_ссылка << 3

При heap ≤ 4GB сдвиг не нужен — просто zero-based, ссылка используется напрямую как смещение от адреса 0.

🔹 Пороговые значения

До 4GB heap: нулевое смещение, нет сдвига. Самый быстрый вариант.
4GB — 32GB: сдвиг на 3 бита, смещение ненулевое.
Выше 32GB: compressed oops отключаются, все ссылки становятся 64-битными.

Здесь ловушка. Если поднять heap с 28GB до 33GB — потребление памяти может вырасти не на 5GB, а значительно больше. Все ссылки удваиваются в размере: с 4 до 8 байт. На приложении с десятками миллионов объектов это легко даёт +20-30% к реальному потреблению.

🔹 Как проверить что включено

java -XX:+PrintFlagsFinal -version | grep UseCompressedOops

Или в логах GC при старте с -Xlog:gc+heap=info:

Heap address: 0x00000006c0000000, size: 28672 MB, Compressed Oops mode: Non-zero based

"Zero based" — heap ≤ 4GB, оптимально.
"Non-zero based" — 4-32GB, compressed oops работают но со сдвигом.
Если строки нет и ссылки 8 байт — compressed oops выключены.

🔹 Compressed Class Pointers

Помимо ссылок на объекты, в заголовке каждого объекта есть ссылка на klass (метаданные класса). Она тоже сжимается отдельным механизмом — Compressed Class Pointers, отдельное 32-битное пространство (Metaspace). Управляется -XX:CompressedClassSpaceSize, по умолчанию 1GB.

🔹 Практический вывод

Граница в 32GB — критическая при планировании capacity. Стандартная рекомендация: если нужно чуть больше 32GB, рассмотреть heap в 26-30GB с compressed oops вместо 33GB без них. Реальная эффективная ёмкость может оказаться выше за счёт лучшей утилизации кеша процессора и меньшего давления на GC.

══════ Навигация ══════
Вакансии • Задачи • Собесы

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

#CoreJava