Очарованные Hibernate: проблемы, которые ведут разработчика странствовать по production

«Подполз ещё ближе: гляжу, крестятся и водку пьют ...» — Н.С. Лесков, «Очарованный странник»

Abstract

Hibernate часто работает как надо ровно до того момента, пока не приходит настоящая нагрузка. И тогда выясняется, что безобидные на вид решения отключают batching, ломают пагинацию, умножают число запросов и даже незаметно открывают дополнительные транзакции — ровно там, где вы рассчитывали на один аккуратный запрос в рамках одного unit of work.

В этой статье мы постарались собрать добрую дюжину самых неочевидных и при этом действительно продакшн-критичных ошибок работы с Hibernate: как они проявляются в логах и метриках, почему возникают на уровне механики ORM, и какие предохранители помогут поймать их до релиза. Будет практично, предметно и с несколькими моментами, после которых захочется пересмотреть пару любимых паттернов в вашем проекте.

Введение

В мире Java-разработки связка Spring Boot, JPA и Hibernate стала де-факто стандартом для создания уровня доступа к данным. Эта мощная комбинация абстрагирует разработчиков от рутинного написания SQL-запросов, позволяя сосредоточиться на бизнес-логике. Однако за этой кажущейся простотой скрывается сложный механизм, неправильное использование которого может привести к катастрофическим последствиям для производительности приложения. Проблемы, такие как знаменитая N+1, неэффективная пакетная обработка или неоптимальные маппинги, могут оставаться незамеченными на этапе разработки, но проявляются под нагрузкой в production, вызывая деградацию системы.

Цель данного документа — предоставить исчерпывающий чек-лист и практическое руководство по выявлению, анализу и устранению наиболее распространенных и критичных проблем производительности и конфигурации Hibernate. Структура этого руководства основана на классификации проблем, которые автоматически обнаруживает мощный инструмент статического и динамического анализа Hypersistence Optimizer, созданный Владом Михалча (Vlad Mihalcea), одним из ведущих мировых экспертов по JPA и Hibernate. Мы систематизировали эти знания, обогатив их лучшими практиками из индустрии и детальными примерами, чтобы создать исчерпывающее руководство для разработчиков.

Проблема 1: IDENTITY убивает JDBC batching

Почему это неочевидно

Большинство разработчиков используют @GeneratedValue(strategy = GenerationType.IDENTITY) по привычке (особенно на MySQL), не понимая, что это полностью отключает JDBC batch inserts. Код компилируется, тесты проходят, но при массовых вставках в production вместо одного batch INSERT выполняется N отдельных запросов.

Как проявляется в production

Симптомы:

• В SQL-логах видны множественные отдельные INSERT вместо batch INSERT

• Операции массовой вставки выполняются в 10-50 раз медленнее, чем ожидалось

• Высокая нагрузка на БД при частых вставках (connection pool исчерпывается)

• Метрики показывают большое количество SQL statements при малом объёме данных

• hibernate.jdbc.batch_size в конфиге есть, но не работает

Метрики для мониторинга:

# Hibernate Statistics
- hibernate.batch.inserts.count = 0 (всегда ноль!)
- hibernate.statements.prepared = N (равно количеству persist)

Корень проблемы

ORM-механика: Hibernate нуждается в идентификаторе сущности сразу после persist() для создания ключа в Persistence Context. IDENTITY-стратегия генерирует ID только после выполнения INSERT в БД (через AUTO_INCREMENT/SERIAL). Поэтому Hibernate вынужден выполнять INSERT немедленно при каждом persist(), без возможности группировки в batch.

В отличие от SEQUENCE: при использовании SEQUENCE Hibernate может получить пачку ID заранее (через allocationSize), выполнить все persist() в памяти, и отправить batch INSERT при flush.

Как детектировать

Статически (по коду):

# Поиск в коде
grep -r "@GeneratedValue.*IDENTITY" src/
grep -r "GenerationType.IDENTITY" src/

Динамически (логи + метрики):

# application.properties - включить SQL logging
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.engine.jdbc.batch=DEBUG

# Проверить в логах при batch insert:
# ПЛОХО: видите отдельные INSERT
# ХОРОШО: видите "batching N statements"

Hibernate Statistics:

SessionFactory sessionFactory = entityManager.getEntityManagerFactory()
    .unwrap(SessionFactory.class);
Statistics stats = sessionFactory.getStatistics();

// После batch insert проверить:
long batchCount = stats.getPrepareStatementCount();  // Должно быть ~N/batch_size
long entityInsertCount = stats.getEntityInsertCount(); // Должно быть N

Как исправить

❌ Плохо — IDENTITY:

import jakarta.persistence.*;

@Entity
@Table(name = "posts")
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)  // ← ПРОБЛЕМА!
    private Long id;
    
    private String title;
    private String content;
}

// При массовой вставке:
for (int i = 0; i < 1000; i++) {
    Post post = new Post();
    post.setTitle("Post " + i);
    entityManager.persist(post);  // ← Каждый persist = отдельный INSERT!
}

✅ Хорошо — SEQUENCE:

import jakarta.persistence.*;

@Entity
@Table(name = "posts")
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "post_seq")
    @SequenceGenerator(
        name = "post_seq",
        sequenceName = "post_sequence",
        allocationSize = 50  // ← Hibernate получает пачку ID заранее
    )
    private Long id;
    
    private String title;
    private String content;
}

// Тот же код, но теперь batching работает:
for (int i = 0; i < 1000; i++) {
    Post post = new Post();
    post.setTitle("Post " + i);
    entityManager.persist(post);
    
    // Flush batch каждые 25 записей
    if (i > 0 && i % 25 == 0) {
        entityManager.flush();
        entityManager.clear();
    }
}

Конфигурация batching:

# application.properties
spring.jpa.properties.hibernate.jdbc.batch_size=25
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true

Миграция с IDENTITY на SEQUENCE (PostgreSQL):

-- 1. Создать sequence
CREATE SEQUENCE post_sequence START WITH 1 INCREMENT BY 50;

-- 2. Синхронизировать с существующими данными
SELECT setval('post_sequence', (SELECT MAX(id) FROM posts) + 1);

-- 3. Обновить default для колонки (опционально)
ALTER TABLE posts ALTER COLUMN id SET DEFAULT nextval('post_sequence');

Mini-checklist для code review

• [ ] Нет ни одного GenerationType.IDENTITY в проекте

• [ ] Все @Id используют GenerationType.SEQUENCE

• [ ] В @SequenceGenerator указан allocationSize (рекомендуется 20-50)

• [ ] В конфиге включён hibernate.jdbc.batch_size > 1

• [ ] В конфиге включён hibernate.order_inserts=true

• [ ] При массовых вставках используется flush() и clear() каждые N записей

Проблема 2: N+1 SELECT — классика жанра, но в production всё равно встречается

Почему это неочевидно

N+1 проблема хорошо известна, но легко пропустить в code review, особенно в сложных query методах репозиториев. Выглядит как обычный запрос, компилируется без ошибок, unit-тесты с 2-3 записями проходят быстро. Проблема проявляется только под нагрузкой, когда N становится большим.

Как проявляется в production

Симптомы:

• Один REST endpoint генерирует сотни SQL запросов

• Latency растёт пропорционально количеству записей (linear time вместо constant)

• Connection pool exhausted — все коннекты за��яты SELECT запросами

• В логах видно: 1 основной SELECT + N дополнительных SELECT для связанных сущностей

• CPU на БД растёт, но сами запросы простые (просто их слишком много)

Типичный паттерн в логах:

-- Один запрос для получения постов
SELECT * FROM posts;  -- Вернул 100 записей

-- N запросов для получения авторов (по одному на каждый пост)
SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 2;
SELECT * FROM users WHERE id = 3;
... (97 запросов)

Корень проблемы

ORM-механика: По умолчанию @ManyToOne и @OneToOne загружаются LAZY. При обращении к связанному полю (post.getAuthor()) Hibernate выполняет отдельный SELECT для этой сущности. Если вы загружаете коллекцию из N постов и для каждого обращаетесь к author, получаете 1 + N запросов.

Почему не ловится в тестах: В unit/integration тестах обычно используется 2-3 записи, и разница между 3 и 5 запросами незаметна.

Как детектировать

Статически (code review):

// ОПАСНЫЙ ПАТТЕРН: загрузка коллекции + обращение к lazy полю
List<Post> posts = postRepository.findAll();
for (Post post : posts) {
    String authorName = post.getAuthor().getName();  // ← N+1!
}

Динамически (DataSource-Proxy):

// В тестах использовать SQLStatementCountValidator
import com.github.gavlyukovskiy.boot.jdbc.decorator.DataSourceDecoratorAutoConfiguration;

@SpringBootTest
class PostServiceTest {
    @Autowired
    private PostService postService;
    
    @Test
    void shouldNotHaveNPlusOne() {
        SQLStatementCountValidator.reset();
        postService.getAllPosts();
        assertSelectCount(1);  // ← Выбросит исключение, если запросов больше 1
    }
}

В логах (включить SQL logging):

logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE

Как исправить

❌ Плохо — N+1 запросов:

@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
    List<Post> findAll();  // ← Загружает только Post, без Author
}

// В сервисе:
@Transactional(readOnly = true)
public List<Post> getAllPosts() {
    List<Post> posts = postRepository.findAll();  // 1 запрос
    for (Post post : posts) {
        String name = post.getAuthor().getName();  // ← N запросов!
    }
    return posts;
}

✅ Хорошо — JOIN FETCH:

@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
    @Query("SELECT p FROM Post p JOIN FETCH p.author")
    List<Post> findAllWithAuthor();  // ← Один запрос с JOIN
}

// В сервисе:
@Transactional(readOnly = true)
public List<Post> getAllPosts() {
    return postRepository.findAllWithAuthor();  // 1 запрос для всех данных
}

✅ Альтернатива — Entity Graph:

@Entity
@NamedEntityGraph(name = "Post.withAuthor",
    attributeNodes = @NamedAttributeNode("author")
)
public class Post { ... }

@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
    @EntityGraph("Post.withAuthor")
    List<Post> findAll();
}

Mini-checklist для code review

• [ ] Все методы репозиториев, возвращающие коллекции, проверены на N+1

• [ ] Используется JOIN FETCH или Entity Graph для загрузки необходимых ассоциаций

• [ ] В тестах используется SQLStatementCountValidator для проверки количества запросов

• [ ] Все @ManyToOne и @OneToOne явно помечены как FetchType.LAZY

• [ ] Нет обращений к lazy-ассоциациям вне транзакции

Проблема 3: Batch size не настроен — массовые операции в 10-50 раз медленнее

Почему это неочевидно

По умолчанию hibernate.jdbc.batch_size=0 (отключен), но это не бросается в глаза. Код работает, тесты проходят, но при массовых операциях в production каждая INSERT/UPDATE выполняется отдельным запросом. Проблема особенно критична при импорте данных, миграциях или batch processing.

Как проявляется в production

Симптомы:

• В SQL-логах видны множественные отдельные INSERT/UPDATE вместо batch операций

• Массовые операции выполняются в 10-50 раз медленнее ожидаемого

• Высокая нагрузка на сеть и БД при массовых операциях

• Connection pool может исчерпываться при частых операциях записи

• Метрики показывают большое количество SQL statements при малом объёме данных

Метрики для мониторинга:

# Hibernate Statistics
- hibernate.batch.inserts.count = 0 (всегда ноль при batch_size=0)
- hibernate.statements.prepared = N (равно количеству операций)

Корень проблемы

ORM-механика: Без batch processing Hibernate отправляет каждый SQL statement отдельно в БД. JDBC batch позволяет группировать несколько statements в один запрос, что значительно уменьшает количество round-trips между приложением и БД. При batch_size=25 вместо 100 отдельных INSERT выполняется 4 batch запроса.

Как детектировать

Статически (по конфигурации):

# Проверить application.properties
grep -r "hibernate.jdbc.batch_size" src/main/resources/
# Если не найдено или значение 0/1 — проблема есть

Динамически (логи + метрики):

# Включить логирование batch операций
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.engine.jdbc.batch.internal.BatchingBatch=DEBUG

# В логах должно быть видно:
# "batching 25 statements" вместо отдельных INSERT/UPDATE

Hibernate Statistics:

Statistics stats = sessionFactory.getStatistics();
long batchCount = stats.getBatchFetchCount();  // Должно быть > 0 при batch операциях

Как исправить

❌ Плохо — batch_size не настроен:

# application.properties
# hibernate.jdbc.batch_size отсутствует или = 0

@Transactional
public void savePosts(List<Post> posts) {
    for (Post post : posts) {
        entityManager.persist(post);  // ← Каждый persist = отдельный INSERT
    }
    // 100 записей = 100 отдельных INSERT запросов
}

✅ Хорошо — batch_size настроен:

# application.properties
spring.jpa.properties.hibernate.jdbc.batch_size=25
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true
spring.jpa.properties.hibernate.jdbc.batch_versioned_data=true

# Для PostgreSQL добавить в JDBC URL:
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb?reWriteBatchedInserts=true

# Для MySQL добавить в JDBC URL:
# spring.datasource.url=jdbc:mysql://localhost:3306/mydb?rewriteBatchedStatements=true

@Transactional
public void savePosts(List<Post> posts) {
    int batchSize = 25;
    for (int i = 0; i < posts.size(); i++) {
        entityManager.persist(posts.get(i));
        
        // Flush и clear каждые batchSize записей
        if (i > 0 && i % batchSize == 0) {
            entityManager.flush();
            entityManager.clear();
        }
    }
    // 100 записей = 4 batch INSERT запроса (по 25 записей)
}

Mini-checklist для code review

• [ ] В конфиге установлен hibernate.jdbc.batch_size (рекомендуется 25-50)

• [ ] Включены hibernate.order_inserts=true и hibernate.order_updates=true

• [ ] Для версионированных сущностей включён hibernate.jdbc.batch_versioned_data=true

• [ ] Для PostgreSQL/MySQL добавлены параметры оптимизации в JDBC URL

• [ ] При массовых операциях используется flush() и clear() каждые N записей

• [ ] НЕ используется GenerationType.IDENTITY (отключает batching)

Проблема 4: EAGER загрузка — неконтролируемые SQL-запросы

Почему это неочевидно

По умолчанию в JPA @ManyToOne и @OneToOne имеют стратегию загрузки EAGER, что означает автоматическую загрузку связанных сущностей при каждом обращении к родительской. Это выглядит удобно ("всегда загружено"), но приводит к неконтролируемому количеству SQL-запросов и изб��точной загрузке данных. EAGER ассоциации нельзя переопределить на LAZY в запросе, что делает невозможной оптимизацию под конкретные сценарии.

Как проявляется в production

Симптомы:

• В SQL-логах видны множественные SELECT запросы при загрузке сущностей через JPQL/Criteria API

• При использовании EntityManager.find() выполняются JOIN с таблицами связанных сущностей, даже когда они не нужны

• Медленная загрузка списков сущностей из-за N+1 проблемы (1 запрос для списка + N запросов для каждой связанной сущности)

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

• Невозможность оптимизировать запросы: EAGER ассоциации всегда загружаются

Типичный паттерн в логах:

-- Загрузка списка продуктов через JPQL
SELECT * FROM product;  -- Вернул 100 записей

-- EAGER @ManyToOne генерирует отдельный SELECT для каждой записи
SELECT * FROM company WHERE id = 1;
SELECT * FROM company WHERE id = 2;
... (98 запросов)

Корень проблемы

ORM-механика: EAGER загрузка принудительно загружает связанные сущности при каждом обращении к родительской, независимо от того, нужны ли они в конкретном сценарии. При использовании JPQL/Criteria API каждая EAGER ассоциация генерирует отдельный SELECT запрос, создавая классическую N+1 проблему. При использовании EntityManager.find() выполняются JOIN, увеличивая размер результирующего набора.

Как детектировать

Статически (по коду):

# Поиск EAGER ассоциаций
grep -r "FetchType.EAGER" src/
grep -r "@ManyToOne" src/ | grep -v "LAZY"  # По умолчанию EAGER!
grep -r "@OneToOne" src/ | grep -v "LAZY"   # По умолчанию EAGER!

Динамически (логи + метрики):

logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql.BasicBinder=TRACE

Как исправить

❌ Плохо — EAGER по умолчанию:

@Entity
public class Product {
    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne  // ← ПРОБЛЕМА: по умолчанию FetchType.EAGER!
    @JoinColumn(name = "company_id")
    private Company company;
    
    @OneToOne  // ← ПРОБЛЕМА: по умолчанию FetchType.EAGER!
    @JoinColumn(name = "details_id")
    private ProductDetails details;
}

// При загрузке списка:
List<Product> products = entityManager.createQuery(
    "SELECT p FROM Product p", Product.class
).getResultList();
// SQL: SELECT * FROM product
//      SELECT * FROM company WHERE id = 1  -- N+1 запрос!
//      SELECT * FROM company WHERE id = 2
//      ... (для каждой записи)

✅ Хорошо — LAZY + JOIN FETCH когда нужно:

@Entity
public class Product {
    @Id
    @GeneratedValue
    private Long id;
    
    @ManyToOne(fetch = FetchType.LAZY)  // ← РЕШЕНИЕ: всегда LAZY!
    @JoinColumn(name = "company_id")
    private Company company;
    
    @OneToOne(fetch = FetchType.LAZY)  // ← РЕШЕНИЕ: всегда LAZY!
    @JoinColumn(name = "details_id")
    private ProductDetails details;
}

// Явно загружать через JOIN FETCH когда нужно:
List<Product> products = entityManager.createQuery("""
    SELECT p 
    FROM Product p 
    JOIN FETCH p.company  -- ← Явная загрузка только когда нужна
    WHERE p.id = :id
    """, Product.class).getResultList();
// SQL: SELECT p.*, c.* FROM product p 
//      INNER JOIN company c ON p.company_id = c.id
//      WHERE p.id = ?  -- Один запрос!

✅ Альтернатива — Entity Graph:

@Entity
@NamedEntityGraph(name = "Product.withCompany",
    attributeNodes = @NamedAttributeNode("company")
)
public class Product { ... }

@Repository
public interface ProductRepository extends JpaRepository<Product, Long> {
    @EntityGraph("Product.withCompany")
    List<Product> findAll();
}

Mini-checklist для code review

• [ ] Все @ManyToOne и @OneToOne явно помечены как FetchType.LAZY

• [ ] Нет ни одного FetchType.EAGER в проекте (кроме специальных случаев)

• [ ] Используется JOIN FETCH или Entity Graph для явной загрузки ассоциаций когда нужно

• [ ] Коллекции (@OneToMany, @ManyToMany) всегда LAZY (они не могут быть EAGER по умолчанию)

• [ ] В тестах проверяется количество SQL-запросов при загрузке сущностей

Проблема 5: Большие колонки загружаются всегда — избыточный трафик и память

Почему это неочевидно

Hibernate по умолчанию загружает все поля сущности при каждом SELECT запросе, включая большие колонки (BLOB, CLOB, TEXT, JSON). Это выглядит нормально, пока не начинаешь работать с таблицами, где каждая запись содержит несколько мегабайт данных. Проблема особенно критична при загрузке списков сущностей, где содержимое больших колонок не используется.

Как проявляется в production

Симптомы:

• Медленное выполнение SELECT запросов для сущностей с большими колонками

• Высокое потребление памяти при загрузке коллекций сущностей с BLOB/CLOB полями

• Увеличение размера transaction log при UPDATE операциях, даже если большие колонки не изменялись

• Высокая нагрузка на сеть при передаче больших объёмов данных из БД в приложение

• OutOfMemoryError при загрузке больших коллекций с BLOB полями

Метрики для мониторинга:

# Размер результата запроса
- Средний размер строки в результате
- Количество загруженных BLOB/CLOB полей
- Время выполнения запросов с большими колонками

Корень проблемы

ORM-механика: Hibernate не может автоматически определить, нужна ли большая колонка в конкретном сценарии, поэтому загружает все поля сущности при выборке. Для колонок размером в несколько мегабайт это может критически влиять на производительность приложения. Без @Basic(fetch = FetchType.LAZY) и bytecode enhancement большие колонки загружаются всегда.

Как детектировать

Статически (по коду):

# Поиск больших колонок без LAZY
grep -r "@Lob" src/
grep -r "byte\[\]" src/
grep -r "columnDefinition.*TEXT\|JSON\|BLOB\|CLOB" src/

Динамически (логи + метрики):

logging.level.org.hibernate.SQL=DEBUG
# Проверить размер результатов запросов

Как исправить

❌ Плохо — большие колонки загружаются всегда:

@Entity
public class Attachment {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @Lob
    private byte[] content;  // ← ПРОБЛЕМА: загружается при каждом SELECT
    // Без @Basic(fetch = FetchType.LAZY) и без bytecode enhancement
}

@Entity
public class Post {
    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @Lob
    @Column(columnDefinition = "TEXT")
    private String fullText;  // ← ПРОБЛЕМА: большой текст загружается всегда
}

✅ Хорошо — LAZY загрузка больших колонок:

@Entity
@DynamicUpdate  // ← Исключает неизменённые колонки из UPDATE
public class Attachment {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    @Lob
    @Basic(fetch = FetchType.LAZY)  // ← LAZY загрузка для больших колонок
    private byte[] content;
}

Конфигурация bytecode enhancement (Maven):

<plugin>
    <groupId>org.hibernate.orm.tooling</groupId>
    <artifactId>hibernate-enhance-maven-plugin</artifactId>
    <version>${hibernate.version}</version>
    <executions>
        <execution>
            <configuration>
                <enableLazyInitialization>true</enableLazyInitialization>
            </configuration>
            <goals>
                <goal>enhance</goal>
            </goals>
        </execution>
    </executions>
</plugin>

✅ Альтернатива — вынос в отдельную таблицу:

@Entity
public class Post {
    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @OneToOne(mappedBy = "post", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private PostContent content;  // ← Отдельная сущность для большого контента
}

@Entity
@Table(name = "post_content")
public class PostContent {
    @Id
    private Long id;

    @OneToOne(fetch = FetchType.LAZY)
    @MapsId
    @JoinColumn(name = "id")
    private Post post;

    @Lob
    @Column(columnDefinition = "TEXT")
    private String fullText;  // Загружается только при явном обращении
}

Mini-checklist для code review

• [ ] Все @Lob поля помечены как @Basic(fetch = FetchType.LAZY)

• [ ] Настроен bytecode enhancement для поддержки lazy loading больших колонок

• [ ] Используется @DynamicUpdate для сущностей с большими колонками

• [ ] Для критичных случаев большие колонки вынесены в отдельную таблицу с @OneToOne

• [ ] Используются DTO проекции для запросов, где большие колонки не нужны

Проблема 6: TABLE генератор — самая неэффективная стратегия идентификаторов

Почему это неочевидно

TABLE генератор эмулирует последовательности с помощью отдельной таблицы и блокировок на уровне строк. Это выглядит как универсальное решение (работает на всех БД), но на самом деле это самая неэффективная стратегия генерации идентификаторов. Проблема особенно критична при высокой конкурентности: транзакции выстраиваются в очередь из-за блокировок.

Как проявляется в production

Симптомы:

• Медленное выполнение массовых вставок (в 5-10 раз медленнее SEQUENCE)

• Высокая нагрузка на БД из-за блокировок на уровне строк

• Сериализация выполнения — конкурентные транзакции выстраиваются в очередь

• При увеличении количества потоков производительность деградирует линейно

• В логах видно множественные SELECT и UPDATE для таблицы генератора

Benchmark результаты (вставка 100 записей):

Потоки	TABLE	SEQUENCE
1	~500ms	~200ms
16	~2500ms	~500ms

Корень проблемы

ORM-механика: TABLE генератор использует отдельную таблицу для хранения текущего значения последовательности. При каждом запросе нового ID выполняется SELECT для получения текущего значения, затем UPDATE для его увеличения. Эти операции выполняются в транзакции с блокировкой строки, что создаёт узкое место: конкурентные транзакции выстраиваются в очередь, ожидая освобождения блокировки.

Как детектировать

Статически (по коду):

# Поиск TABLE генератора
grep -r "GenerationType.TABLE" src/
grep -r "@TableGenerator" src/

Динамически (логи + метрики):

-- Проверить наличие таблицы генератора
SELECT * FROM hibernate_sequences;  -- Или другое имя таблицы

-- В логах SQL видно множественные SELECT и UPDATE для таблицы генератора

Как исправить

❌ Плохо — TABLE генератор:

@Entity
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE)  // ← НИКОГДА не использовать!
    private Long id;
}

✅ Хорошо — SEQUENCE (для PostgreSQL, Oracle, SQL Server 2012+):

@Entity
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "post_seq")
    @SequenceGenerator(
        name = "post_seq",
        sequenceName = "post_sequence",
        allocationSize = 50
    )
    private Long id;
}

✅ Для MySQL — IDENTITY (если SEQUENCE недоступен):

@Entity
public class Post {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)  // Лучше чем TABLE, но не идеально
    private Long id;
}

Миграция с TABLE на SEQUENCE (PostgreSQL):

-- 1. Создать sequence
CREATE SEQUENCE post_sequence START WITH 1 INCREMENT BY 50;

-- 2. Установить значение последовательности на максимальный ID + 1
SELECT setval('post_sequence', (SELECT COALESCE(MAX(id), 0) + 1 FROM post));

-- 3. Удалить таблицу генератора (если больше не используется)
DROP TABLE hibernate_sequences;

Mini-checklist для code review

• [ ] Нет ни одного GenerationType.TABLE в проекте

• [ ] Используется SEQUENCE для PostgreSQL, Oracle, SQL Server 2012+

• [ ] Для MySQL используется IDENTITY (или переход на MariaDB 10.3+ для поддержки SEQUENCE)

• [ ] В @SequenceGenerator указан allocationSize (рекомендуется 20-50)

• [ ] Значение последовательности синхронизировано с максимальным ID в таблице

Проблема 7: Запрос возвращает слишком много записей — OutOfMemoryError

Почему это неочевидно

Запросы без пагинации, возвращающие тысячи или десятки тысяч записей, выглядят нормально в development с небольшим объёмом данных. Проблема проявляется только в production, когда данных становится много. Загрузка большого количества записей в память может привести к исчерпанию памяти, увеличению времени выполнения запросов и созданию избыточной нагрузки на сеть и базу данных.

Как проявляется в production

Симптомы:

• Высокое потребление памяти при выполнении запросов

• Медленное выполнение запросов, возвращающих большие результаты

• Увеличение времени GC паузы и возможные OutOfMemoryError

• Высокая нагрузка на сеть при передаче больших объёмов данных

• События QueryResultListSizeEvent в логах Hypersistence Optimizer

Метрики для мониторинга:

# Размер результатов запросов
- Количество записей в результате
- Потребление памяти при выполнении запросов
- Время выполнения запросов

Корень проблемы

ORM-механика: Hibernate загружает все результаты запроса в память при использовании getResultList(). Для запроса, возвращающего 10 000 записей, может потребоваться несколько сотен мегабайт памяти, что критично для приложений с ограниченными ресурсами или высокой частотой запросов. Без пагинации или потоковой обработки все данные загружаются в память сразу.

Как детектировать

Статически (по коду):

# Поиск запросов без пагинации
grep -r "getResultList()" src/
grep -r "@Query.*SELECT" src/ | grep -v "Page\|Pageable"

Динамически (Hypersistence Optimizer):

# Настроить пороговое значение для мониторинга
spring.jpa.properties.hypersistence.query.max_result_size=100

Как исправить

❌ Плохо — запрос без пагинации:

@Repository
public class PostRepository {
    @Query("SELECT p FROM Post p WHERE p.status = :status")
    List<Post> findAllByStatus(@Param("status") String status);
    // ← ПРОБЛЕМА: может вернуть тысячи записей без ограничений
    // Если записей 10 000, все загружаются в память
}

✅ Хорошо — пагинация:

@Repository
public class PostRepository {
    // РЕШЕНИЕ: использовать пагинацию через Pageable
    @Query("SELECT p FROM Post p WHERE p.status = :status ORDER BY p.createdDate DESC")
    Page<Post> findAllByStatus(@Param("status") String status, Pageable pageable);
    // При вызове: Pageable pageable = PageRequest.of(0, 20);  // Первая страница, 20 записей
}

✅ Альтернатива — потоковая обработка для больших результатов:

@Repository
public class PostRepository {
    // РЕШЕНИЕ: использовать ScrollableResults для потоковой обработки
    public void processAllPosts(String status) {
        Session session = entityManager.unwrap(Session.class);
        ScrollableResults<Post> results = session.createQuery(
            "SELECT p FROM Post p WHERE p.status = :status",
            Post.class
        )
        .setParameter("status", status)
        .scroll(ScrollMode.FORWARD_ONLY);
        
        try {
            while (results.next()) {
                Post post = results.get();
                // Обработка одной записи за раз, не загружая все в память
                processPost(post);
            }
        } finally {
            results.close();
        }
    }
}

Настройка порогового значения для мониторинга:

# Настроить пороговое значение для мониторинга размера результатов
spring.jpa.properties.hypersistence.query.max_result_size=100

Mini-checklist для code review

• [ ] Все запросы, возвращающие списки сущностей, используют пагинацию

• [ ] Используется Pageable или setFirstResult/setMaxResults для ограничения размера результата

• [ ] Для очень больших объёмов данных используется потоковая обработка (ScrollableResults)

• [ ] Настроено пороговое значение hypersistence.query.max_result_size для мониторинга

• [ ] Нет использования getResultList() для запросов, которые могут вернуть тысячи записей

Проблема 8: DriverManager вместо пула соединений — создание соединения на каждый запрос

Почему это неочевидно

DriverManagerConnectionProvider — это встроенный провайдер соединений Hibernate, который использует DriverManager.getConnection() для получения каждого соединения напрямую от JDBC драйвера. Этот провайдер не использует пул соединений, создавая новое соединение для каждого запроса и закрывая его после использования. Проблема возникает при отсутствии явной настройки DataSource в Spring Boot или при явной настройке DriverManagerConnectionProvider.

Как проявляется в production

Симптомы:

• Медленное выполнение запросов, особенно при высокой нагрузке

• Высокое потребление ресурсов БД (множество одновременных соединений)

• Ошибки подключения при пиковых нагрузках

• В логах видно множество операций открытия/закрытия соединений

• Время получения соединения составляет 10-100 мс вместо микросекунд

Метрики для мониторинга:

# Метрики пула соединений
- Время получения соединения из пула
- Количество активных соединений
- Количество операций открытия/закрытия соединений

Корень проблемы

ORM-механика: Создание нового соединения требует установки TCP-соединения, аутентификации и инициализации, что занимает 10-100 мс. При высокой нагрузке это приводит к деградации производительности, исчерпанию ресурсов БД и нестабильности приложения. Профессиональные пулы соединений (HikariCP) переиспользуют соединения, сокращая время получения соединения до микросекунд.

Как детектировать

Статически (по конфигурации):

# Проверить наличие DataSource в конфигурации
grep -r "DataSource" src/main/java/
grep -r "spring.datasource" src/main/resources/

Динамически (логи + метрики):

# Включить логирование операций с соединениями
logging.level.com.zaxxer.hikari=DEBUG

Как исправить

❌ Плохо — DriverManager (явная настройка):

// В persistence.xml или конфигура��ии Hibernate:
<persistence-unit name="myPU">
    <properties>
        <property name="hibernate.connection.provider_class" 
                  value="org.hibernate.connection.DriverManagerConnectionProvider"/>  // ← ПРОБЛЕМА
        <property name="hibernate.connection.url" value="jdbc:postgresql://localhost/mydb"/>
        <property name="hibernate.connection.username" value="user"/>
        <property name="hibernate.connection.password" value="pass"/>
    </properties>
</persistence-unit>

✅ Хорошо — DataSource с пулом соединений (Spring Boot):

# Spring Boot автоматически настраивает HikariCP
spring.datasource.url=jdbc:postgresql://localhost:5432/mydb
spring.datasource.username=user
spring.datasource.password=pass
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5

✅ Явная настройка DataSource (без Spring Boot):

@Configuration
public class DataSourceConfig {
    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb");
        config.setUsername("user");
        config.setPassword("pass");
        config.setMaximumPoolSize(20);
        config.setMinimumIdle(5);
        return new HikariDataSource(config);
    }
}

Mini-checklist для code review

• [ ] Используется DataSource с пулом соединений (HikariCP, DBCP2, C3P0)

• [ ] Нет явной настройки DriverManagerConnectionProvider

• [ ] Размер пула соединений настроен в зависимости от нагрузки (обычно 10-50)

• [ ] Мониторятся метрики пула соединений через HikariCP

• [ ] HikariCP — рекомендуемый выбор для большинства приложений

Проблема 9: Auto-commit включён — нарушение транзакционности и отключение batching

Почему это неочевидно

JDBC Connection получен в auto-commit режиме, когда каждое SQL statement автоматически коммитится сразу после выполнения. Это нарушает транзакционную семантику Hibernate: невозможно группировать несколько операций в одну транзакцию, откатывать изменения при ошибках и использовать batch processing для оптимизации производительности. Проблема возникает при неправильной конфигурации пула соединений или при отсутствии явной настройки auto-commit=false.

Как проявляется в production

Симптомы:

• События AutoCommittingConnectionEvent в логах Hypersistence Optimizer

• В логах SQL видно, что каждое statement выполняется с auto-commit

• Batch processing не работает даже при настройке hibernate.jdbc.batch_size

• Невозможность отката изменений при ошибках (частичное сохранение данных)

• Высокая нагрузка на БД из-за множественных операций commit

Метрики для мониторинга:

# Метрики транзакций
- Количество операций commit на транзакцию
- Время выполнения транзакций
- Количество откатов транзакций

Корень проблемы

ORM-механика: В auto-commit режиме каждое INSERT, UPDATE или DELETE выполняется как отдельная транзакция с автоматическим commit, что полностью отключает batch processing и создаёт избыточные накладные расходы на операции commit. При вставке 100 записей выполняется 100 отдельных транзакций вместо одной, что увеличивает время выполнения в 10-50 раз и создаёт избыточную нагрузку на БД.

Как детектировать

Статически (по конфигурации):

# Проверить настройки auto-commit
grep -r "auto-commit" src/main/resources/
grep -r "provider_disables_autocommit" src/main/resources/

Динамически (Hypersistence Optimizer):

# Hypersistence Optimizer автоматически детектирует auto-commit соединения
# События AutoCommittingConnectionEvent в логах

Как исправить

❌ Плохо — auto-commit включён:

# В application.properties отсутствует настройка или установлено true:
# spring.datasource.hikari.auto-commit отсутствует  // ← ПРОБЛЕМА
# spring.datasource.hikari.auto-commit=true  // ← ПРОБЛЕМА

✅ Хорошо — auto-commit отключён:

# Шаг 1: Отключить auto-commit в пуле соединений
spring.datasource.hikari.auto-commit=false

# Шаг 2: Сообщить Hibernate, что пул управляет auto-commit
spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true

✅ Явная настройка в конфигурации DataSource:

@Configuration
public class DataSourceConfig {
    @Bean
    public DataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb");
        config.setUsername("user");
        config.setPassword("pass");
        config.setAutoCommit(false);  // ← Обязательно отключить auto-commit
        return new HikariDataSource(config);
    }
}

Mini-checklist для code review

• [ ] В конфиге установлено spring.datasource.hikari.auto-commit=false

• [ ] Установлено hibernate.connection.provider_disables_autocommit=true

• [ ] Нет явной установки auto-commit=true в коде

• [ ] Проверяются метрики пула соединений для выявления соединений в auto-commit режиме

• [ ] Мониторятся события AutoCommittingConnectionEvent для выявления проблемных участков кода

Проблема 10: enable_lazy_load_no_trans — антипаттерн, который маскирует проблемы

Почему это неочевидно

Свойство hibernate.enable_lazy_load_no_trans=true позволяет Hibernate создавать временные сессии и транзакции для загрузки lazy-ассоциаций вне активной транзакции. Это выглядит как удобное решение проблемы LazyInitializationException, но на самом деле это критический антипаттерн, который создаёт новую сессию и транзакцию для каждого обращения к lazy-ассоциации после закрытия основной транзакции.

Как проявляется в production

Симптомы:

• Множественные транзакции в логах для одного запроса

• Медленное выполнение при обращении к lazy-ассоциациям после закрытия транзакции

• Проблемы с пулом соединений (исчерпание соединений)

• Нарушение консистентности данных из-за чтения в разных транзакциях

• Ошибки LazyInitializationException заменяются на множественные транзакции

Типичный паттерн в логах:

Transaction started (для author)
SELECT ... FROM author WHERE id = ?
Transaction committed
Transaction started (для comments)  // ← Новая транзакция!
SELECT ... FROM comment WHERE post_id = ?
Transaction committed

Корень проблемы

ORM-механика: Каждая lazy-ассоциация требует отдельной транзакции, что может привести к сотням транзакций для одного запроса. Это увеличивает время выполнения в 10-100 раз, создаёт избыточную нагрузку на пул соединений и может привести к исчерпанию ресурсов БД. Кроме того, множественные транзакции нарушают изоляцию данных и могут привести к проблемам с консистентностью.

Как детектировать

Статически (по конфигурации):

# Поиск проблемного свойства
grep -r "enable_lazy_load_no_trans" src/main/resources/

Динамически (логи + метрики):

# В логах видно множественные транзакции для одного запроса
logging.level.org.hibernate.transaction=DEBUG

Как исправить

❌ Плохо — enable_lazy_load_no_trans включён:

# В application.properties установлено проблемное свойство:
spring.jpa.properties.hibernate.enable_lazy_load_no_trans=true  // ← КРИТИЧЕСКИЙ АНТИПАТТЕРН!

@Transactional
public Post getPost(Long id) {
    return postRepository.findById(id).orElse(null);
    // Транзакция закрывается здесь
}

// В контроллере или сервисе:
Post post = postService.getPost(1L);
// Следующее обращение создаёт новую транзакцию!
String authorName = post.getAuthor().getName();  // ← Новая транзакция для каждого обращения
List<Comment> comments = post.getComments();     // ← Ещё одна транзакция!

✅ Хорошо — JOIN FETCH в запросе:

@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
    @Query("SELECT p FROM Post p JOIN FETCH p.author JOIN FETCH p.comments WHERE p.id = :id")
    Optional<Post> findByIdWithAssociations(@Param("id") Long id);
}

// Использование:
Post post = postRepository.findByIdWithAssociations(1L).orElse(null);
// Все ассоциации загружены в одной транзакции

✅ Альтернатива — Entity Graph:

@Entity
@NamedEntityGraph(name = "Post.withAssociations",
    attributeNodes = {
        @NamedAttributeNode("author"),
        @NamedAttributeNode("comments")
    }
)
public class Post { ... }

// Использование:
EntityGraph graph = entityManager.getEntityGraph("Post.withAssociations");
Post post = entityManager.find(Post.class, 1L, 
    Map.of("jakarta.persistence.fetchgraph", graph));

✅ Альтернатива — DTO проекции:

@Query("SELECT new com.example.dto.PostDTO(p.id, p.title, a.name, SIZE(p.comments)) " +
       "FROM Post p JOIN p.author a WHERE p.id = :id")
PostDTO findPostDTO(@Param("id") Long id);

Mini-checklist для code review

• [ ] НИКОГДА не устанавливать hibernate.enable_lazy_load_no_trans=true

• [ ] Всегда загружать необходимые ассоциации явно в запросе через JOIN FETCH

• [ ] Использовать Entity Graph для переиспользуемых паттернов загрузки

• [ ] Для представлений использовать DTO проекции вместо сущностей с lazy-ассоциациями

• [ ] Если нужно инициализировать ассоциации, делать это внутри транзакции через Hibernate.initialize()

Проблема 11: FlushMode.AUTO нарушает read-your-writes для native SQL

Почему это неочевидно

FlushMode.AUTO (режим по умолчанию) выполняет flush Persistence Context перед запросами, которые могут конфликтовать с незакоммиченными изменениями, но только для JPQL и Criteria API запросов. Для native SQL запросов Hibernate не может определить, какие таблицы затрагивает запрос, поэтому flush может не выполниться. Это нарушает семантику read-your-writes: изменения, сделанные через Hibernate в текущей транзакции, могут быть не видны в последующих native SQL запросах.

Как проявляется в production

Симптомы:

• Native SQL запросы не видят изменений, сделанных через Hibernate в текущей транзакции

• Неожиданные результаты запросов: данные, которые должны были быть изменены, остаются старыми

• Нарушение бизнес-логики из-за чтения устаревших данных

• Проблемы с консистентностью данных в транзакциях, смешивающих Hibernate операции и native SQL

Типичный паттерн в логах:

-- Изменение через Hibernate
UPDATE post SET title = ? WHERE id = ?

-- Native SQL запрос может не увидеть изменение
SELECT title FROM post WHERE id = ?  -- ← Может вернуть старое значение

Корень проблемы

ORM-механика: Hibernate не может определить, какие таблицы затрагивает native SQL запрос, поэтому не выполняет flush перед ним. Это нарушает read-your-writes семантику: изменения, сделанные через Hibernate в текущей транзакции, могут быть не видны в последующих native SQL запросах, что приводит к проблемам консистентности данных и неожиданному поведению приложения.

Как детектировать

Статически (по коду):

# Поиск native SQL запросов
grep -r "nativeQuery.*true" src/
grep -r "createNativeQuery" src/

Динамически (логи + тесты):

// Тест на read-your-writes семантику
@Test
void shouldSeeChangesInNativeQuery() {
    Post post = postRepository.findById(1L).orElseThrow();
    post.setTitle("New Title");
    entityManager.flush();  // Явный flush
    
    String title = entityManager.createNativeQuery(
        "SELECT title FROM post WHERE id = :id", String.class
    )
    .setParameter("id", 1L)
    .getSingleResult();
    
    assertEquals("New Title", title);  // ← Может упасть без явного flush
}

Как исправить

❌ Плохо — FlushMode.AUTO с native SQL:

@Transactional
public void updateAndQuery(Long postId, String title) {
    // Изменение через Hibernate
    Post post = postRepository.findById(postId).orElseThrow();
    post.setTitle(title);
    // Hibernate отслеживает изменение, но flush может не выполниться перед native SQL
    
    // Native SQL запрос может не увидеть изменение!
    String currentTitle = entityManager.createNativeQuery(
        "SELECT title FROM post WHERE id = :id", String.class
    )
    .setParameter("id", postId)
    .getSingleResult();
    // currentTitle может содержать старое значение, если flush не выполнился
}

✅ Хорошо — FlushMode.ALWAYS:

# Гарантировать flush перед всеми запросами, включая native SQL
spring.jpa.properties.hibernate.flushMode=always
# Альтернатива через org.hibernate:
# spring.jpa.properties.org.hibernate.flushMode=always

✅ Альтернатива — явный flush перед native SQL:

@Transactional
public void updateAndQuery(Long postId, String title) {
    Post post = postRepository.findById(postId).orElseThrow();
    post.setTitle(title);
    
    // Явный flush перед native SQL
    entityManager.flush();  // ← Гарантирует, что изменения видны в native SQL
    
    String currentTitle = entityManager.createNativeQuery(
        "SELECT title FROM post WHERE id = :id", String.class
    )
    .setParameter("id", postId)
    .getSingleResult();
    // Теперь currentTitle содержит актуальное значение
}

Mini-checklist для code review

• [ ] Используется hibernate.flushMode=always для приложений, смешивающих Hibernate операции с native SQL

• [ ] Если используется FlushMode.AUTO, явно вызывается entityManager.flush() перед native SQL запросами

• [ ] Избегается смешивание Hibernate операций и native SQL в одной транзакции, если это возможно

• [ ] Для read-only операций используется @Transactional(readOnly = true), что исключает необходимость flush

• [ ] Тестируются транзакции, содержащие native SQL, на предмет read-your-writes семантики

Проблема 12: OptimisticLockMode — race condition при оптимистичной блокировке

Почему это неочевидно

LockModeType.OPTIMISTIC проверяет версию сущности только при commit транзакции, а не при чтении. Это создаёт race condition: между чтением сущности и commit другая транзакция может изменить сущность, что приведёт к OptimisticLockException только при commit, а не сразу. В критических операциях, таких как резервирование товара или списание средств, это может привести к нарушению бизнес-логики.

Как проявляется в production

Симптомы:

• OptimisticLockException выбрасывается при commit транзакции, а не при чтени�� сущности

• Транзакция выполняет все операции, но завершается с ошибкой при commit

• Нарушение бизнес-правил: перерасход товара, двойное списание средств

• Необходимость повторной обработки после отката транзакции

Типичный паттерн в логах:

-- Транзакция 1: Чтение product
SELECT * FROM product WHERE id = 1

-- Транзакция 2: Изменение product
UPDATE product SET stock = stock - 1 WHERE id = 1

-- Транзакция 1: Commit (выбрасывает OptimisticLockException)
-- Все операции выполнены, но commit не удался

Корень проблемы

ORM-механика: LockModeType.OPTIMISTIC проверяет версию сущности только при commit транзакции, а не при чтении. Это создаёт race condition: между чтением сущности и commit другая транзакция может изменить сущность, что приведёт к OptimisticLockException только при commit. Транзакция может выполнить все операции (создание заказов, списание средств), но завершиться с ошибкой при commit, оставив систему в несогласованном состоянии.

Как детектировать

Статически (по коду):

# Поиск использования LockModeType.OPTIMISTIC
grep -r "LockModeType.OPTIMISTIC" src/
grep -r "find.*LockModeType" src/

Динамически (логи + метрики):

# Мониторинг OptimisticLockException
logging.level.org.hibernate.OptimisticLockException=DEBUG

Как исправить

❌ Плохо — OPTIMISTIC без пессимистичной блокировки:

@Transactional
public PurchaseOrder orderProduct(Long productId, int quantity) {
    Product product = entityManager.find(Product.class, productId, LockModeType.OPTIMISTIC);
    // ← ПРОБЛЕМА: версия проверяется только при commit, не при чтении
    
    // Между чтением и commit другая транзакция может изменить product
    if (product.getStock() < quantity) {
        throw new InsufficientStockException();
    }
    
    PurchaseOrder order = new PurchaseOrder().setProduct(product).setQuantity(quantity);
    entityManager.persist(order);
    
    // При commit может быть выброшено OptimisticLockException,
    // даже если stock был достаточен при чтении
    // ← Race condition: другая транзакция могла изменить stock между чтением и commit
}

✅ Хорошо — пессимистичная блокировка перед commit:

@Transactional
public PurchaseOrder orderProduct(Long productId, int quantity) {
    Product product = entityManager.find(Product.class, productId, LockModeType.OPTIMISTIC);
    
    // Выполнить все проверки и операции
    if (product.getStock() < quantity) {
        throw new InsufficientStockException();
    }
    
    PurchaseOrder order = new PurchaseOrder().setProduct(product).setQuantity(quantity);
    entityManager.persist(order);
    
    // Пессимистичная блокировка перед commit гарантирует, что сущность не изменится
    entityManager.lock(product, LockModeType.PESSIMISTIC_READ);  // ← Перед commit!
    // Теперь product заблокирован до завершения транзакции
    // Другие транзакции не смогут изменить product до commit/rollback
    
    return order;
}

✅ Альтернатива — PESSIMISTIC_WRITE с самого начала:

@Transactional
public PurchaseOrder orderProduct(Long productId, int quantity) {
    // Использовать PESSIMISTIC_WRITE вместо OPTIMISTIC для критических операций
    Product product = entityManager.find(Product.class, productId, LockModeType.PESSIMISTIC_WRITE);
    
    if (product.getStock() < quantity) {
        throw new InsufficientStockException();
    }
    
    PurchaseOrder order = new PurchaseOrder().setProduct(product).setQuantity(quantity);
    entityManager.persist(order);
    
    return order;
}

Mini-checklist для code review

• [ ] Всегда использовать пессимистичную блокировку перед commit при критических операциях с LockModeType.OPTIMISTIC

• [ ] Применять блокировку после выполнения всех проверок и операций, но до commit

• [ ] Для операций с ограниченными ресурсами рассмотреть использование LockModeType.PESSIMISTIC_WRITE вместо OPTIMISTIC

• [ ] Мониторить количество OptimisticLockException для выявления проблемных участков кода

• [ ] Использовать @Version для всех сущностей, участвующих в критических операциях

Проблема 13: Пагинация без ORDER BY — недетерминированные результаты

Почему это неочевидно

При использовании пагинации (LIMIT/OFFSET или setFirstResult/setMaxResults) без указания ORDER BY порядок записей в результате не гарантирован и может изменяться между запросами. Без явного указания порядка база данных может возвращать записи в произвольном порядке, который зависит от физического расположения данных на диске, индексов, плана выполнения запроса и других факторов. Это приводит к недетерминированным результатам: при повторных запросах одной и той же страницы могут возвращаться разные записи.

Как проявляется в production

Симптомы:

• При повторных запросах одной страницы возвращаются разные записи

• Некоторые записи пропускаются при навигации по страницам

• Одинаковые записи появляются на разных страницах

• Порядок записей изменяется между запросами

• События PaginationWithoutOrderByEvent в логах Hypersistence Optimizer

Типичный паттерн в логах:

-- Запрос страницы 1 без ORDER BY
SELECT * FROM post WHERE status = 'ACTIVE' LIMIT 10 OFFSET 0

-- Запрос страницы 1 повторно (может вернуть другие записи!)
SELECT * FROM post WHERE status = 'ACTIVE' LIMIT 10 OFFSET 0

Корень проблемы

ORM-механика: Без явного указания ORDER BY база данных может возвращать записи в произвольном порядке, который зависит от физического расположения данных на диске, индексов, плана выполнения запроса и других факторов. Это приводит к недетерминированным результатам: при повторных запросах одной и той же страницы могут возвращаться разные записи, некоторые записи могут быть пропущены, а другие — дублироваться на разных страницах.

Как детектировать

Статически (по коду):

# Поиск запросов с пагинацией без ORDER BY
grep -r "Pageable\|setFirstResult\|setMaxResults" src/ | grep -v "ORDER BY\|orderBy"

Динамически (Hypersistence Optimizer):

# Hypersistence Optimizer автоматически детектирует пагинацию без ORDER BY
# События PaginationWithoutOrderByEvent в логах

Как исправить

❌ Плохо — пагинация без ORDER BY:

@Repository
public class PostRepository {
    @Query("SELECT p FROM Post p WHERE p.status = :status")
    List<Post> findPosts(@Param("status") String status, Pageable pageable);  
    // ← ПРОБЛЕМА: пагинация без ORDER BY
    // Порядок записей не гарантирован, результаты могут изменяться
}

✅ Хорошо — пагинация с ORDER BY:

@Repository
public class PostRepository {
    // РЕШЕНИЕ: явное указание ORDER BY
    @Query("SELECT p FROM Post p WHERE p.status = :status ORDER BY p.createdDate DESC, p.id ASC")
    List<Post> findPosts(@Param("status") String status, Pageable pageable);
    // Порядок записей гарантирован, результаты детерминированы
}

✅ Альтернатива — Sort в Spring Data JPA:

@Repository
public interface PostRepository extends JpaRepository<Post, Long> {
    // РЕШЕНИЕ: Pageable с Sort
    Page<Post> findByStatus(String status, Pageable pageable);
    // При вызове:
    // Sort sort = Sort.by("createdDate").descending().and(Sort.by("id").ascending());
    // Pageable pageable = PageRequest.of(0, 10, sort);
}

Mini-checklist для code review

• [ ] Всегда указывать ORDER BY при использовании пагинации

• [ ] Использовать вторичную сортировку по уникальному полю (например, id) для стабильности результатов

• [ ] Предпочитать сортировку по индексированным полям для лучшей производительности

• [ ] Избегать сортировки по вычисляемым полям или функциям, если это возможно

• [ ] Мониторить события PaginationWithoutOrderByEvent для выявления проблемных запросов

Проблема 14: Несколько экземпляров одной сущности в Persistence Context

Почему это неочевидно

В Hibernate каждая запись базы данных должна управляться только одной сущностью в Persistence Context в рамках одной транзакции. Проблема возникает, когда одна и та же запись БД загружается несколько раз, создавая несколько экземпляров сущности с одинаковым идентификатором. Это нарушает принцип единственности сущности в Persistence Context и создаёт риск несогласованности данных: изменения, сделанные в одном экземпляре, могут не отразиться в другом.

Как проявляется в production

Симптомы:

• События TableRowAlreadyManagedEvent в логах Hypersistence Optimizer

• Потеря изменений данных: изменения в одном экземпляре не сохраняются при commit

• Конфликтующие UPDATE операции для одной записи в логах SQL

• Ошибки оптимистичной блокировки (OptimisticLockException) при отсутствии реальных конфликтов

• Непредсказуемое поведение при изменении полей через разные экземпляры сущности

Типичный паттерн в логах:

-- Первая загрузка
SELECT * FROM post WHERE id = 1

-- Вторая загрузка той же записи
SELECT * FROM post WHERE id = 1

-- При flush: два UPDATE для одной записи
UPDATE post SET title = ? WHERE id = 1
UPDATE post SET content = ? WHERE id = 1  -- ← Последний перезаписывает первый

Корень проблемы

ORM-механика: При flush Hibernate может выполнить несколько UPDATE операций для одной записи, что приводит к потере данных (последний UPDATE перезаписывает предыдущие изменения) или к ошибкам оптимистичной блокировки. Кроме того, наличие нескольких экземпляров одной сущности в памяти увеличивает потребление памяти и создаёт избыточную нагрузку на Persistence Context.

Как детектировать

Статически (по коду):

# Поиск множественной загрузки одной записи
# Проверить методы, которые могут загружать одну и ту же запись несколько раз

Динамически (Hypersistence Optimizer):

# Hypersistence Optimizer автоматически детектирует несколько экземпляров одной сущности
# События TableRowAlreadyManagedEvent в логах

Как исправить

❌ Плохо — множественная загрузка одной записи:

@Transactional
public void updatePost(Long postId, String title, String content) {
    Post post1 = postRepository.findById(postId).orElseThrow();  // ← Первая загрузка
    post1.setTitle(title);
    
    // ПРОБЛЕМА: та же запись загружается снова!
    Post post2 = entityManager.createQuery(
        "SELECT p FROM Post p WHERE p.id = :id", Post.class
    )
    .setParameter("id", postId)
    .getSingleResult();  // ← Вторая загрузка той же записи
    post2.setContent(content);
    
    // При flush: два UPDATE для одной записи, последний перезапишет изменения первого
}

✅ Хорошо — переиспользование загруженной сущности:

@Transactional
public void updatePost(Long postId, String title, String content) {
    // Загрузить один раз и переиспользовать
    Post post = postRepository.findById(postId).orElseThrow();
    post.setTitle(title);
    post.setContent(content);  // ← Изменения в одном экземпляре
    // При flush: один UPDATE с обоими изменениями
}

✅ Альтернатива — EntityManager.getReference():

@Transactional
public void updatePostFields(Long postId, String title, String content) {
    // getReference() возвращает proxy, не загружая данные, если сущность уже в контексте
    Post post = entityManager.getReference(Post.class, postId);
    post.setTitle(title);
    post.setContent(content);
}

Mini-checklist для code review

• [ ] Всегда переиспользовать загруженные сущности в рамках одной транзакции

• [ ] Избегать множественной загрузки одной записи через разные методы

• [ ] Использовать EntityManager.getReference() для получения ссылки на сущность без загрузки данных

• [ ] Никогда не создавать новые экземпляры сущностей с существующими ID — всегда загружать из БД

• [ ] Мониторить события TableRowAlreadyManagedEvent для выявления проблемных участков кода

Проблема 15: Работа с Persistence Context без транзакции

Почему это неочевидно

Hibernate Persistence Context должен работать в рамках транзакции для обеспечения ACID-свойств и корректного управления жизненным циклом сущностей. Проблема возникает, когда Persistence Context используется без активной транзакции: каждое обращение к базе данных требует получения нового JDBC Connection, что нарушает принципы работы Persistence Context и создаёт проблемы с консистентностью данных.

Как проявляется в production

Симптомы:

• События TransactionlessSessionEvent в логах Hypersistence Optimizer

• Множественные операции получения JDBC Connection для одной сессии в логах

• Потеря изменений при ошибках (невозможность отката без транзакции)

• Нарушение изоляции данных: изменения видны другим транзакциям до commit

• Проблемы с lazy loading: ассоциации не могут быть загружены без активной транзакции

Типичный паттерн в логах:

Connection obtained from pool (для первого запроса)
SELECT ... FROM post WHERE id = 1
Connection released to pool
Connection obtained from pool (для второго запроса)  // ← Новое соединение!
SELECT ... FROM post WHERE id = 2
Connection released to pool

Корень проблемы

ORM-механика: Без транзакции невозможно использовать batch processing, оптимистичную блокировку и механизм dirty checking для автоматической синхронизации изменений. Это может привести к потере данных при ошибках, нарушению изоляции операций и деградации производительности из-за множественных операций получения/освобождения соединений.

Как детектировать

Статически (по коду):

# Поиск методов без @Transactional
grep -r "EntityManager\|Session" src/ | grep -v "@Transactional"

Динамическ�� (Hypersistence Optimizer):

# Hypersistence Optimizer автоматически детектирует работу без транзакции
# События TransactionlessSessionEvent в логах

Как исправить

❌ Плохо — работа без транзакции:

@Service
public class PostService {
    @Autowired
    private EntityManager entityManager;
    
    public void createPost(String title) {
        // ПРОБЛЕМА: нет @Transactional, каждое обращение получает новое соединение
        Post post = new Post();
        post.setTitle(title);
        entityManager.persist(post);  // ← Получает Connection 1
        entityManager.flush();        // ← Получает Connection 2 (если flush выполняется)
        // Изменения могут быть потеряны при ошибке, нет отката
    }
}

✅ Хорошо — работа в транзакции:

@Service
public class PostService {
    @Autowired
    private EntityManager entityManager;
    
    @Transactional  // ← Обязательно для операций с БД
    public void createPost(String title) {
        Post post = new Post();
        post.setTitle(title);
        entityManager.persist(post);
        // Все операции выполняются в одной транзакции с одним Connection
        // При ошибке выполнится откат, изменения не будут потеряны
    }
}

✅ Загрузка необходимых ассоциаций в транзакции:

@Service
public class PostService {
    @Transactional
    public Post getPostWithAuthor(Long id) {
        // Загрузить все необходимые ассоциации в транзакции
        return entityManager.createQuery(
            "SELECT p FROM Post p JOIN FETCH p.author WHERE p.id = :id", Post.class
        )
        .setParameter("id", id)
        .getSingleResult();
    }
    
    public void processPost(Long id) {
        Post post = getPostWithAuthor(id);  // Все данные загружены в транзакции
        String authorName = post.getAuthor().getName();  // ← Работает, данные уже загружены
    }
}

Mini-checklist для code review

• [ ] Все методы, работающие с БД, помечены аннотацией @Transactional

• [ ] Используется @Transactional(readOnly = true) для операций чтения

• [ ] Загружаются все необходимые ассоциации в рамках транзакции через JOIN FETCH или Entity Graph

• [ ] Избегается работа с Persistence Context в конструкторах, инициализаторах и статических методах

• [ ] Используются DTO проекции для передачи данных вне транзакции вместо сущностей с lazy-ассоциациями

Проблема 16: Избыточный save/merge для managed сущностей

Почему это неочевидно

Hibernate автоматически отслеживает изменения сущностей, которые находятся в Persistence Context (managed entities), через механизм dirty checking. При вызове save() или merge() для сущности, которая уже загружена в текущей транзакции, Hibernate выполняет избыточные операции: проверяет состояние сущности, сравнивает её с текущим состоянием в БД и может выполнить ненужные запросы. Это создаёт дополнительную нагрузку на систему и усложняет код без какой-либо пользы.

Как проявляется в production

Симптомы:

• В логах SQL видны избыточные SELECT запросы для проверки состояния сущности перед save/merge

• Код содержит явные вызовы save() или merge() для сущностей, загруженных в текущей транзакции

• Методы сервисов содержат избыточные операции сохранения после изменения полей

• Небольшое увеличение времени выполнения на 5-15% из-за избыточных проверок

Типичный паттерн в логах:

-- Загрузка сущности
SELECT ... FROM post WHERE id = ?

-- Избыточный SELECT перед save/merge (если включён)
SELECT ... FROM post WHERE id = ?

-- UPDATE выполнится в любом случае при commit
UPDATE post SET title = ? WHERE id = ?

Корень проблемы

ORM-механика: save() и merge() нужны только в определённых случаях: save() для новых (transient) сущностей, merge() для detached сущностей (загружены вне текущей транзакции). Для managed сущностей (загружены в текущей транзакции) Hibernate автоматически отслеживает изменения через dirty checking и выполнит UPDATE при flush или commit без явного вызова save() или merge().

Как детектировать

Статически (по коду):

# Поиск избыточных save/merge
grep -r "\.save(\|\.merge(" src/ | grep -v "//.*нов\|//.*detached"

Динамически (логи + метрики):

# Включить логирование SQL для выявления избыточных SELECT
logging.level.org.hibernate.SQL=DEBUG

Как исправить

❌ Плохо — избыточный save/merge:

@Transactional
public void updatePost(Long postId, String title) {
    Post post = postRepository.findById(postId).orElseThrow();  // ← Сущность загружена, теперь managed
    post.setTitle(title);
    postRepository.save(post);  // ← ИЗБЫТОЧНО! Сущность уже в Persistence Context
    // Hibernate выполнит избыточные проверки и может сделать лишний SELECT
}

// Или с merge:
@Transactional
public void updatePostDetails(Long postId, String content) {
    Post post = postRepository.findById(postId).orElseThrow();
    post.setContent(content);
    entityManager.merge(post);  // ← ИЗБЫТОЧНО! merge нужен только для detached сущностей
}

✅ Хорошо — полагаться на dirty checking:

@Transactional
public void updatePost(Long postId, String title) {
    Post post = postRepository.findById(postId).orElseThrow();
    post.setTitle(title);
    // Dirty checking автоматически обнаружит изменение и выполнит UPDATE при commit
    // Явный вызов save/merge не нужен!
}

// Для detached сущностей (загружены вне транзакции) merge действительно нужен:
@Transactional
public void updateDetachedPost(Post detachedPost, String title) {
    detachedPost.setTitle(title);
    Post managedPost = entityManager.merge(detachedPost);  // ← Правильно: merge для detached сущности
    // Теперь managedPost находится в Persistence Context, дальнейшие изменения отслеживаются автоматически
}

Mini-checklist для code review

• [ ] Никогда не вызывать save() или merge() для managed сущностей (загружены в текущей транзакции)

• [ ] Использовать save() только для новых (transient) сущностей перед первым сохранением

• [ ] Использовать merge() только для detached сущностей (загружены вне текущей транзакции)

• [ ] Полагаться на автоматический dirty checking Hibernate для managed сущностей

• [ ] Обучать команду пониманию жизненного цикла сущностей в Hibernate (transient, managed, detached, removed)

Эталонная конфигурация Spring Boot

# ========================================
# BATCHING
# ========================================
spring.jpa.properties.hibernate.jdbc.batch_size=25
spring.jpa.properties.hibernate.order_inserts=true
spring.jpa.properties.hibernate.order_updates=true
spring.jpa.properties.hibernate.jdbc.batch_versioned_data=true

# ========================================
# CONNECTIONS
# ========================================
spring.datasource.hikari.auto-commit=false
spring.jpa.properties.hibernate.connection.provider_disables_autocommit=true

# ========================================
# QUERY OPTIMIZATION
# ========================================
spring.jpa.properties.hibernate.criteria.literal_handling_mode=bind
spring.jpa.properties.hibernate.query.in_clause_parameter_padding=true
spring.jpa.properties.hibernate.query.plan_cache_max_size=4096
spring.jpa.properties.hibernate.query.fail_on_pagination_over_collection_fetch=true
spring.jpa.properties.hibernate.jdbc.fetch_size=100

# ========================================
# MONITORING
# ========================================
spring.jpa.properties.hibernate.generate_statistics=true

# ========================================
# SCHEMA GENERATION
# ========================================
spring.jpa.hibernate.ddl-auto=validate

# ========================================
# HYPERSISTENCE OPTIMIZER RUNTIME
# ========================================
spring.jpa.properties.hypersistence.session.timeout_millis=3000
spring.jpa.properties.hypersistence.session.flush_timeout_millis=1000
spring.jpa.properties.hypersistence.query.max_result_size=100
spring.jpa.properties.hypersistence.query.timeout_millis=250

Сводный чек-лист для code review

Мапп��нг сущностей

• [ ] Идентификаторы используют SEQUENCE вместо IDENTITY/TABLE

• [ ] Идентификаторы — wrapper-типы (Long, не long)

• [ ] @Version — short/smallint, не timestamp

• [ ] equals/hashCode реализованы на основе natural id или с константным hashCode

• [ ] Все @ManyToOne и @OneToOne — FetchType.LAZY

• [ ] Bidirectional ассоциации имеют методы синхронизации

• [ ] @ManyToMany использует Set, не List

• [ ] @ManyToMany без CascadeType.REMOVE

• [ ] @OneToOne использует @MapsId

• [ ] @ElementCollection имеет @OrderColumn

• [ ] Коллекции инициализированы при создании

Конфигурация

• [ ] hibernate.jdbc.batch_size > 1

• [ ] hibernate.order_inserts = true

• [ ] hibernate.order_updates = true

• [ ] hibernate.connection.provider_disables_autocommit = true

• [ ] hibernate.criteria.literal_handling_mode = bind

• [ ] hibernate.query.in_clause_parameter_padding = true

• [ ] hibernate.query.fail_on_pagination_over_collection_fetch = true

• [ ] hibernate.enable_lazy_load_no_trans = false (или отсутствует)

• [ ] Используется Flyway/Liquibase вместо hbm2ddl

Runtime

• [ ] Read-only операции используют @Transactional(readOnly=true)

• [ ] Нет вызова save/merge для managed сущностей

• [ ] Запросы с пагинацией имеют ORDER BY

• [ ] Используется JOIN FETCH вместо N+1 запросов

Как поставить предохранители

Мониторинг через Hypersistence Optimizer

# Настроить пороговые значения для мониторинга
spring.jpa.properties.hypersistence.session.timeout_millis=3000
spring.jpa.properties.hypersistence.session.flush_timeout_millis=1000
spring.jpa.properties.hypersistence.query.max_result_size=100
spring.jpa.properties.hypersistence.query.timeout_millis=250

Статический анализ в CI/CD

# Проверка на IDENTITY генераторы
grep -r "GenerationType.IDENTITY" src/ && exit 1

# Проверка на EAGER загрузку
grep -r "FetchType.EAGER" src/ && exit 1

# Проверка на enable_lazy_load_no_trans
grep -r "enable_lazy_load_no_trans.*true" src/ && exit 1

Тестирование с SQLStatementCountValidator

@SpringBootTest
class PostServiceTest {
    @Test
    void shouldNotHaveNPlusOne() {
        SQLStatementCountValidator.reset();
        postService.getAllPosts();
        assertSelectCount(1);
    }
}

Метрики Hibernate Statistics

Statistics stats = sessionFactory.getStatistics();
long batchCount = stats.getBatchFetchCount();
long queryCount = stats.getQueryExecutionCount();
double cacheHitRate = stats.getQueryCacheHitCount() / 
    (double) (stats.getQueryCacheHitCount() + stats.getQueryCacheMissCount());

Заключение

Ключевое отличие между приложением, которое падает под нагрузкой, и приложением, которое масштабируется, часто лежит именно в не всегда очевидных деталях: правильный fetch type здесь, readOnly=true там, allocationSize в третьем месте. Hibernate - это не чёрный ящик, который магически решает все проблемы персистентности. Это мощный фреймворк, который даёт вам множество способов выстрелить себе в ногу, если вы не понимаете, что происходит под капотом.

Практический путь от понимания к результату прост: прогоните чек-листы по вашему проекту (вы почти наверняка найдёте парочку проблем), включите предохранители (Hibernate Statistics, fail-fast конфиги, SQL logging), настройте мониторинг критичных метрик, сделайте эти паттерны частью вашего code review процесса. Начните с одной проблемы - изучите, примените решение, измерьте результат. Затем следующая.

Невозможно эффективно использовать инструмент, который абстрагирует вас от SQL, не понимая SQL. Невозможно доверять Hibernate управление вашими данными, не зная, как именно он это делает. Разница между ремесленником и мастером в работе с ORM - это разница между тем, кто надеется, что "оно само заработает", и тем, кто точно знает, какой SQL будет выполнен, сколько запросов, в какой транзакции, и почему именно так.

Помните, Левша тонкую работу сделал, а машину испортил, потому что механику работы ее не понимал.

«Тогда бы вы могли сообразить, что в каждой-машине расчет силы есть; а то вот хоша вы очень в руках искусны, а не сообразили, что такая малая машинка, ..., на самую аккуратную точность рассчитана» — Н.С. Лесков, «Левша»

Список литературы

1. Что такое N+1 SELECT проблема и как с ней бороться? [Электронный ресурс] // Proselyte: образовательный портал. – Режим доступа: https://proselyte.net/jpa-n-plus-1-select-problem/

2. Глава 26. Лучшие практики [Электронный ресурс] // Hibernate Reference Documentation (русская локализация). – Режим доступа: https://hibernate-refdoc.3141.ru/ch26.BestPractices

3. Глава 20. Повышение производительности [Электронный ресурс] // Hibernate Reference Documentation (русская локализация). – Режим доступа: https://hibernate-refdoc.3141.ru/ch20.ImprovingPerformance

4. Batch Processing Best Practices With JPA And Hibernate [Электронный ресурс] / J. Costa // GitHub. – Режим доступа: https://github.com/jlmc/hibernate-tunings/blob/master/batch-processing-best-practices-with-jpa-and-hibernate/README.md

5. Hibernate Performance Best Practices (2025): 9 Expert Tips You Won't Find in Generic Blogs [Электронный ресурс] // Medium: Javarevisited. – Режим доступа: https://medium.com/javarevisited/hibernate-performance-best-practices-2025-9-expert-tips-you-wont-find-in-generic-blogs-87b4a02013e0

6. Mihalcea, V. Hypersistence Optimizer User Guide [Электронный ресурс] / V. Mihalcea. – Режим доступа: https://vladmihalcea.com/hypersistence-optimizer/docs/user-guide/

7. Mihalcea, V. Hypersistence Optimizer [Электронный ресурс] / V. Mihalcea. – Режим доступа: https://vladmihalcea.com/hypersistence-optimizer/