Спасаемся от Spring: есть ли альтернативы репозиторным фреймворкам? Часть вторая. Альтернативы В предыдущей статье мы обсудили недостатки решений Spring в части доступа к данным. В ходе анализа решений Spring стало очевидно, что оба фреймворка используют радикально разные подходы в работе с данными. Казалось бы, контроль над запросами очень важен для приложений, особенно высоконагруженных. Но Spring Data JPA такого контроля не даёт. Лёгкость и простота изменения кода является залогом его чистоты и работоспособности, однако с этим есть сложности уже у Spring JDBC. Всего-то нужен фреймворк, предоставляющий полный контроль над запросами со стороны разработчика и не создающий трудностей при развитии, изменении и рефакторинге кода. В этой статье мы разберём две альтернативы, которые, на мой взгляд, в меньшей степени подвержены проблемам Spring Data JPA и Spring JDBC. Это будут jOOQ и Exposed. Читать статью Наш канал в Макс 🟪
JaJava библиотека
КатегорияOtherЯзыкRUДобавлен06 июл. 2026 г.КачествоПроверен
Подписчики1.2K
Сред. просмотры1.6K
ERR129.8%
Цена-- RUB
Цена / подписчик--
Цена / просмотр--
Метрики обновлены: 07 июл. 2026 г.
Последние посты
Знакомо чувство, когда код вроде работает, но любое изменение вызывает тревогу? Новая фича затрагивает десятки файлов. После рефакторинга начинают падать тесты. А когда бизнес меняет требования, приходится переписывать половину сервиса. Часто проблема не в коде. 🚫 Проблема в том, что в Use Case бизнес-логика идёт вперемешку с инфраструктурными вызовами, а архитектура больше не помогает контролировать сложность проекта. 🔥 15 июля стартует практический курс по Domain-Driven Design и Clean Architecture на Java. За 6 недель вы научитесь: ✔️ Выделять доменную модель и проектировать Aggregate, Entity и Value Object ✔️ Отделять бизнес-логику от HTTP, БД, Kafka и внешних сервисов ✔️ Писать тесты, которые проверяют логику, а не количество моков ✔️ Реализовывать Domain Events и Domain Service без сложных абстракций ✔️ Подключать HTTP, gRPC и Kafka через адаптеры, не затрагивая доменную модель ✔️ Строить сервисы, которые проще развивать при изменении требований 📦 На курсе вы соберёте полноценный сервис диспетчеризации заказов на Java и получите готовый шаблон архитектуры, который сможете использовать в рабочих проектах. Автор курса — Кирилл Ветчинкин, архитектор Авито, ex Staff Engineer в Купер, с 15-летним опытом разработки и 6+ годами практического применения DDD. 🎁 Первый модуль можно пройти бесплатно и понять , какие архитектурные решения помогают удерживать кодовую базу под контролем: https://microarch.ru/courses/ddd/languages/java?utm_source=posev&utm_medium=erid:2Vtzqv8mHrR&utm_campaign=7 Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2Vtzqv8mHrR
StampedLock: когда ReentrantReadWriteLock уже не справляется Если знаком с ReentrantReadWriteLock, то знаешь идею: много читателей одновременно, но запись эксклюзивна. Звучит разумно, но у этой модели есть фундаментальная проблема: читатели блокируют писателей. Поток, который хочет писать, ждёт пока все читатели закончат. При высокой read-нагрузке писатель может ждать очень долго. StampedLock решает именно это. 🔵 Три режима, не два ReentrantReadWriteLock даёт два режима — read и write. StampedLock добавляет третий — optimistic read. StampedLock lock = new StampedLock(); // обычный read lock long stamp = lock.readLock(); try { // читаем } finally { lock.unlockRead(stamp); } // write lock long stamp = lock.writeLock(); try { // пишем } finally { lock.unlockWrite(stamp); } Это знакомо. Но вот где начинается интересное: long stamp = lock.tryOptimisticRead(); // читаем данные без блокировки вообще int value = this.value; if (!lock.validate(stamp)) { // кто-то писал пока мы читали — перечитываем под реальным локом stamp = lock.readLock(); try { value = this.value; } finally { lock.unlockRead(stamp); } } tryOptimisticRead() не захватывает никакого лока, а просто возвращает штамп. validate() проверяет — была ли запись с момента получения штампа. Если нет, то данные консистентны, идём дальше, если да, то фолбэк на обычный read lock. 🔵 Что такое stamp Это long, который кодирует состояние лока. Каждая успешная запись инвалидирует все оптимистичные штампы. Поэтому validate() — это просто битовая проверка, без CAS, без синхронизации, так что она очень дешёвая. 🔵 Где это реально даёт профит Сценарий: данные читаются в 95% случаев, пишутся редко. Классический пример — кеш, конфигурация, счётчики с инкрементом. С ReentrantReadWriteLock все читатели всё равно захватывают shared lock — это операция на AQS, есть накладные расходы. С StampedLock + optimistic read при отсутствии конкурентных записей блокировки нет вообще. 🔵 Подводные камни — StampedLock не реентерабельный. Если поток захватил write lock и попытается захватить его снова — дедлок. Это принципиальное отличие от ReentrantReadWriteLock. — Нет поддержки Condition. Если тебе нужен await/signal — StampedLock не подойдёт. — Нет поддержки прерывания в обычных методах readLock()/writeLock(). Есть отдельные readLockInterruptibly() — но это уже осознанный выбор. StampedLock — инструмент для конкретного профиля нагрузки: много чтений, редкие записи, нет реентерабельности. Не замена всем локам подряд. Но в правильном месте даёт ощутимый прирост без усложнения архитектуры. Подписывайся на наш канал в Max 🟪
Вопрос с собеседования В чём разница между @Bean и @Component в Spring? Ответ: @Bean используется в конфигурационных классах Spring. Он используется для непосредственного создания бина. @Component используется со всеми классами, которыми должен управлять Spring. Когда Spring видит класс с @Component , Spring определяет этот класс как кандидата для создания bean. Подписывайся на наш канал в Max 🟪
Hibernate Reactive: опыт миграции, архитектурные компромиссы и скрытая сложность Наш проект на Quarkus столкнулся с необходимостью более эффективного использования ресурсов под высокой нагрузкой. В поисках решения мы решили попробовать миграцию с классического Hibernate ORM на Hibernate Reactive (HR). В этой статье я поделюсь реальным опытом этого перехода: разберу ключевые архитектурные различия, расскажу о неочевидных «граблях», на которые мы наступили, и покажу на production-коде, какую цену пришлось заплатить за реактивность. Версии используемого ПО: Quarkus: 3.31.3, Quarkus Hibernate Reactive: 3.31.3 и Vertx-pg-client (реактивный клиент PostgreSQL): 4.5.24. Все описанные ниже вопросы и особенности актуальны именно для этих версий. Читать статью Наш канал в Макс 🟪