[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-hibernate-chto-takoe-kesh-pervogo-urovnya-l1-cache":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":19,"progress":20,"seo":21},757,"chto-takoe-kesh-pervogo-urovnya-l1-cache",19,"hibernate","Hibernate","🐻","Что такое кэш первого уровня (L1 Cache)?","Кэш первого уровня (L1 Cache) — это Persistence Context, привязанный к Session (или EntityManager). Это обязательный кэш, который нельзя отключить.\n\n### Как работает\n\n```java\n@Transactional\npublic void example() {\n    \u002F\u002F Запрос к БД — объект помещается в L1 Cache\n    User user1 = entityManager.find(User.class, 1L);  \u002F\u002F SQL SELECT\n\n    \u002F\u002F Повторный запрос — объект берётся из L1 Cache, без SQL\n    User user2 = entityManager.find(User.class, 1L);  \u002F\u002F НЕТ SQL\n\n    \u002F\u002F Гарантия идентичности\n    assert user1 == user2;  \u002F\u002F true — один и тот же объект\n\n    \u002F\u002F Изменение объекта — Dirty Checking отслеживает\n    user1.setName(\"New Name\");\n    \u002F\u002F При commit\u002Fflush → UPDATE users SET name = 'New Name' WHERE id = 1\n}\n\u002F\u002F L1 Cache уничтожается при закрытии Session\u002Fтранзакции\n```\n\n### Свойства L1 Cache\n\n- Привязан к Session, живёт в рамках одной транзакции\n- Хранит управляемые (Persistent) сущности\n- Гарантирует identity — один ID → один объект в рамках Session\n- Обеспечивает Dirty Checking — автоматическое обнаружение изменений\n- Write-behind — SQL-запросы откладываются до flush\n\n### Очистка L1 Cache\n\n```java\nentityManager.clear();          \u002F\u002F очистить весь L1 Cache\nentityManager.detach(user);     \u002F\u002F убрать конкретную сущность из кэша\n```\n\n### Важное\n\n- L1 Cache = Persistence Context = Session — это одно и то же\n- Нельзя отключить — это фундаментальная часть Hibernate\n- Живёт в рамках одной транзакции (`@Transactional`)\n- Гарантирует, что два вызова `find(User.class, 1L)` вернут один и тот же Java-объект\n\n### Частые ошибки\n\n- Загрузка слишком большого количества сущностей — все загруженные сущности хранятся в L1 Cache; 100K сущностей → OutOfMemoryError\n- Не использовать `clear()` при batch-обработке — при вставке миллиона записей L1 Cache переполняется\n- Ожидать L1 Cache между транзакциями — каждая транзакция имеет свой Persistence Context; кэш не переживает транзакцию\n\n### Как используется в 2026\n\n- L1 Cache работает прозрачно, разработчик взаимодействует с ним косвенно\n- Для batch-операций: `clear()` каждые N записей — обязательный паттерн\n- Spring `@Transactional(readOnly = true)` оптимизирует L1 Cache — отключает Dirty Checking\n\n> **На собеседовании:** ключевое — L1 Cache = Persistence Context = Session. Он обязателен и живёт в рамках одной транзакции. Интервьюер может спросить «что будет, если дважды вызвать find() с одинаковым ID?» — ответ: второй вызов вернёт тот же объект из кэша без SQL. Упомяните проблему OOM при batch-обработке и решение через `clear()`.","","junior",[15,16,17,7,18],"persistence-context","l1-cache","jpa","caching",[],null,{"title":22,"description":23,"ogTitle":24,"ogDescription":25,"keywords":26,"schemaAnswer":34,"featuredSnippetReady":35},"Кэш первого уровня (L1 Cache) в Hibernate — Gymterview","L1 Cache = Persistence Context = Session. Обязательный кэш в рамках транзакции: identity guarantee, Dirty Checking, write-behind. Очистка через clear().","L1 Cache в Hibernate: Persistence Context и identity guarantee — Gymterview","L1 Cache — обязательный кэш Hibernate, привязанный к Session. Гарантия identity, Dirty Checking, write-behind. Проблема OOM при batch.",[27,28,29,30,31,32,8,33],"L1 Cache","кэш первого уровня","Persistence Context","Session","Dirty Checking","identity","JPA","L1 Cache (кэш первого уровня) — Persistence Context, привязанный к Session\u002FEntityManager. Обязательный кэш, нельзя отключить. Живёт в рамках одной транзакции. Гарантирует identity (один ID → один объект), обеспечивает Dirty Checking и write-behind (SQL откладывается до flush). При batch-обработке нужен clear() для предотвращения OutOfMemoryError.",true]