Java for Beginner
688 subscribers
586 photos
161 videos
12 files
900 links
Канал от новичков для новичков!
Изучайте Java вместе с нами!
Здесь мы обмениваемся опытом и постоянно изучаем что-то новое!

Наш YouTube канал - https://www.youtube.com/@Java_Beginner-Dev

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Как я память искал (Часть I)

Совсем недавно стал свидетелем неочевидной проблемы, когда вроде бы полностью протестированный стабильный сервис, по непонятным причинам падает на проде с ошибкой OutOfMemory.

Причинами и способами решения, сегодня я решил поделиться с Вами
.

Вводные данные:
🔵Основная сущность (к примеру User) и связанная с ней через one-to-many, вторичная сущность (пусть будет Car).
🔵Сущности описаны по стандарту Spring JPA в коде.
🔵По запросу бизнеса, при получении списка основных сущностей должна применяться пагинация, фильтрация и сортировка (для корректного отображения на web-странице).
🔵Само собой при получении основных сущностей, нужно подгружать все связанные, а так же иметь возможность фильтрации и сортировки по содержащихся в них данных.

Предложенное решение (как показала практика - неверное):
🔵Для решения подобного запроса использовать стандартные средства Spring, такие как Pageable и для формирования сложного SQL запроса средствами Java - Specification

Примерный код:

🧍 User
@Entity
public class User {
//стандартные поля
@OneToMany(mappedBy = "owner", fetch = FetchType.LAZY)
private List<Car> cars = new ArrayList<>();
}


🚗 Car
@Entity
public class Car {
//стандартные поля
@ManyToOne
@JoinColumn(name = "owner_id")
private User owner;
}


Пагинация + fetch join через Specification (без фильтров)

Page<User> users = userRepository.findAll(specification, PageRequest.of(0, 10));


настройка Specification
return (root, query, cb) -> {
root.fetch("cars", JoinType.LEFT);
query.distinct(true);
return cb.conjunction();
};


Проблема:
🔵Хотя предложенное выше решение и выглядит очевидным при озвученном кейсе требований и решении проблемы N+1, оно создает проблему о которой Вам не расскажут на хайповых курсах и видео уроках.

Вот примеры:
Пример 1
Пример 2

🔵Суть проблемы в том, что когда вы используете JOIN FETCH (например, через Specification), Hibernate подгружает связанные сущности в один SQL-запрос (чтобы избежать N+1).

Однако в сочетании с пагинацией (Pageable) Hibernate теряет корректность подсчёта количества строк и может загрузить всю таблицу в память, чтобы затем вручную "отрезать" нужную страницу на уровне Java, тем самым использовав ВСЮ выделенную JVM память для хранения
.

О последствиях такого непредсказуемого поведения можете посудить сами. 😱


Что происходит, подробно?

Когда вы вызываете, например:
Page<User> users = userRepository.findAll(specification, PageRequest.of(0, 10));


Hibernate должен выполнить:
SELECT COUNT(*) ... — чтобы узнать общее количество строк.
SELECT ... LIMIT 10 OFFSET 0 — чтобы получить только первую страницу.


❗️Но fetch join меняет семантику запроса

Когда вы пишете JOIN FETCH, например:
root.fetch("cars", JoinType.LEFT);

Или:
criteriaQuery.distinct(true);


Hibernate генерирует SQL примерно такого вида:
SELECT u.*, r.* FROM users u
LEFT JOIN roles r ON r.user_id = u.id


При этом:
Если у одного пользователя 3 cars, то он появится 3 раза в результате SQL-запроса.
Hibernate потом вручную собирает дубликаты в одну сущность User, у которой будет List<Car> с 3 элементами.
LIMIT/OFFSET применяются к строкам SQL, а не к "собранным" сущностям — и это вызывает проблемы.


⚠️ Проблема: LIMIT работает до агрегации

Hibernate не может корректно объединить дубликаты после применения LIMIT, потому что:

При использовании fetch join, результат SQL-разворачивается в несколько строк (по связям).
Но LIMIT обрезает эти строки до того, как Hibernate агрегирует их в объекты Java.
Поэтому Hibernate игнорирует LIMIT в SQL, чтобы корректно собрать сущности → он загружает все строки в память, затем отрезает нужную страницу на уровне Java.


🤯 Что я получил в результате использования неверного решения

🔜 Упавший сервис на проде 😨 (так как на тестовых средах, объем загружамых данных был в разы меньше).
🔜 Бесценный опыт, которым сейчас делюсь с Вами ☺️

А завтра я расскажу как решить данный кейс и как не попасть в подобную ловушку неочевидного поведения Hibernate ...

Понравился стиль подачи материала?

Отправь другу и ставь -
🔥

#Java #fetch #autor
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9
Как я память искал (Часть II)

В предыдущей части мы рассмотрели составные части возникновения проблемы.

А теперь давайте рассмотрим, как решить данный кейс и как не попасть в подобную ловушку неочевидного поведения Hibernate.

Решения 🤓

🟡Первое и самое очевидное:

Избегать fetch join при пагинации в Hibernate

Да так просто.

Но вы скажете: "А как же проблема N+1"? Ее я предлагаю решить всем известной аннотацией
@BatchSize.
@Entity
public class User {
//стандартные поля
@OneToMany(mappedBy = "owner")
@BatchSize(size = 50)
private List<Car> cars = new ArrayList<>();
}
Количество запросов существенно уменьшится — на тот размер size, который мы задали. Это значит, что проблема N+1 решена.


Да, запросов станет точно больше чем 1. Но такова цена использования Spring Hibernate 🤷‍♀️

🟡Второе и не очень хорошее, а при увеличении количества связанных сущностей в запросе - опасное:

разделение запроса на две части с использованием @EntityGraph

@EntityGraph(attributePaths = {"cars"})
Page<User> findAll(Pageable pageable);


При таком решении в первой части запроса мы запрашиваем id наших User с определенной страницы. А во второй части запроса с помощью @EntityGraph и JOIN мы получаем все Car которые им принадлежат.

Но как показали тестовые запуски с использованием @EntityGraph над множеством связанных сущностей в основной, проведенные автором статьи(спасибо ему) :
"При пяти загружаемых коллекциях производительность разделенного запроса с @EntityGraph хуже в 2 раза. При десяти — в 45 раз. А при загрузке 15 коллекций — в 1401 раз! На графике нет данных по разделенному запросу для 20 коллекций, так как я просто-напросто получил ошибку OutOfMemoryError."

С @BatchSize же никаких JOIN не происходит, и при добавлении дополнительной коллекции с ассоциацией @OneToMany просто добавляются дополнительные select для этой коллекции.


🟡И третье, элементарное как свет солнца 😏

Использовать Нативный SQL - запрос.

Да, больше мороки с формированием динамического SQL (если у тебя 10 разных фильтров, ты сам будешь собирать SQL строку).
@Query(value = """
SELECT u.id AS userId, u.name AS userName, c.model AS carModel
FROM user u
LEFT JOIN car c ON c.owner_id = u.id
WHERE (:name IS NULL OR u.name ILIKE %:name%)
ORDER BY
CASE WHEN :sortBy = 'name' THEN u.name
WHEN :sortBy = 'id' THEN CAST(u.id AS TEXT)
ELSE u.name
END ASC
LIMIT :limit OFFSET :offset
""", nativeQuery = true)
List<UserCarDTO> findWithFilters(
@Param("name") String name,
@Param("sortBy") String sortBy,
@Param("limit") int limit,
@Param("offset") int offset
);


Да, придется использовать дополнительный count-запрос: SELECT COUNT(*) , для обеспечения пагинации
@Query(value = """
SELECT COUNT(DISTINCT u.id)
FROM user u
WHERE (:name IS NULL OR u.name ILIKE %:name%)
""", nativeQuery = true)
long countUsers(@Param("name") String name);


но, ты сам полностью управляешь процессом и скорее всего не встретишь неочевидного поведения 💪

И на сладкое

Какие ещё конструкции в JPA/Hibernate могут привести к аналогичным проблемам, когда ты используешь fetch join и неожиданно получаешь избыточную загрузку в память, ломающую пагинацию или вызывающую дублирование/нагрузку?

1. Pageable + @Query (с JPQL) и JOIN FETCH
Даже если ты не используешь Specification, а пишешь JPQL с @Query, проблема остаётся.

2. EntityManager + JPQL с fetch и пагинацией
Даже ручной вызов через EntityManager может привести к тому же эффекту.

3. Criteria API с fetch + .setMaxResults()/.setFirstResult()
Даже если ты используешь чистый JPA Criteria API, проблема может проявиться.

4. Spring Data REST + @RepositoryRestResource + fetch join
Если ты используешь Spring Data REST, и в репозитории включён fetch join, например через @Query, то Spring сам применяет Pageable, и может попасть в эту ловушку. Опять же — всё сломается.


И личный совет: изучайте матчасть! Читайте наш канал и шанс, что Ваш прод упадет - существенно снизится!

Понравился стиль подачи материала?

Отправь другу и ставь -
🔥

#Java #fetch #autor
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6