🧠 Простое ускорение @Transactional методов в Spring Boot

Знаете, что @Transactional по умолчанию оборачивает метод в прокси?

Это значит:
- Внутренние вызовы в том же классе не проходят через транзакцию;
- Каждый такой прокси — это AOP-магия, которую можно обойти ради производительности.

📌 Если вы точно знаете, что метод будет вызываться только извне, и вам не нужна прокси-обёртка — используйте @Transactional на уровне интерфейса и включите interface-based proxy.

@Configuration
@EnableTransactionManagement(proxyTargetClass = false) // JDK proxy
public class TransactionConfig {
}

public interface UserService {
    @Transactional
    void createUser(User user);
}

📉 Это немного снижает overhead, особенно в высоконагруженных сервисах, где сотни тысяч вызовов @Transactional-методов.

💡 Подходит, если:
- У вас слоистая архитектура;
- Транзакции нужны только снаружи;
- Вы не используете вызовы this.someMethod() внутри сервиса.

⚠️ Не забывайте:
- JDK Proxy работает только с интерфейсами;
- Если вызываете методы внутри того же класса — прокси не сработает (и транзакция не начнётся).

📊 Профильте. Иногда замена proxyTargetClass = true на false даёт +3-5% к throughput.

👉@BookJava

Хотите глубже разобраться в функциональном программировании и писать более качественный код на Scala? Приходите на вебинар в Otus

24 апреля в 20:00 пройдёт открытый вебинар с Алексеем Воронцом — руководителем разработки в Naumen, 14 лет опыта, из них 9 лет на Scala. На практических примерах он покажет:

— почему Scala — функциональный язык
— как работать с ключевыми библиотеками
— как повысить выразительность кода

❗️ Если вы уже знакомы со Scala или только начинаете к нему присматриваться и хотите развивать функциональный подход в своих проектах — этот вебинар для вас.

Каждый участник:
— сможет задать вопросы эксперту
— получит скидку на полный курс по Scala-разработке

👉 Регистрируйтесь и сделайте свой код лучше

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🧠 Сейчас покажу баг, который легко пропустить при работе с @Transactional в Spring Boot 3+.

📌 Проблема — транзакция не работает, потому что метод вызывается изнутри того же класса.

Рассмотрим пример:

@Service
public class UserService {

    @Transactional
    public void createUser(User user) {
        saveUser(user);
        sendWelcomeEmail(user); // бросает исключение
    }

    public void saveUser(User user) {
        userRepository.save(user);
    }
}

💥 Если sendWelcomeEmail выбросит исключение — транзакция не откатится, потому что @Transactional работает через прокси. Вызов createUser() должен идти извне, чтобы Spring "знал", что нужно обернуть вызов в транзакцию.


✅ Решения:

1. Вынести transactional-метод в отдельный бин:

   @Service
   public class UserCreationService {
       @Transactional
       public void createUser(User user) {
           // ...
       }
   }
   

2. Внедрить self-прокси:

   @Autowired
   private UserService self;

   public void externalCaller(User user) {
       self.createUser(user);
   }
   

3. Использовать AopContext:

   ((UserService) AopContext.currentProxy()).createUser(user);
   

⚠️ Не забудь включить exposeProxy = true в @EnableAspectJAutoProxy.


💡 Современный подход — разделение ответственности: transactional-методы живут в отдельных сервисах, их проще тестировать и не возникает подобных ловушек.

👉@BookJava

🧠 Lazy Initialization по-взрослому: не создавай проблемы на ровном месте

В Spring Boot часто можно встретить вот такую конструкцию:

@Service
public class EmailService {
    private final SmtpClient client = new SmtpClient(); // дорогая инициализация
}

⚠️ Проблема: SmtpClient создаётся сразу при старте приложения. Даже если EmailService ни разу не вызовется. Это не только waste of resources, но и может сломать запуск, если SmtpClient требует специфического окружения.

📌 Решение — ленивая инициализация, но не через старый добрый null-check, а красиво, безопасно и читаемо:

💡 Способ #1: Lazy<T> wrapper

@Component
public class EmailService {
    private final Supplier<SmtpClient> client = Suppliers.memoize(SmtpClient::new);

    public void sendEmail(...) {
        client.get().send(...);
    }
}

Можно и без Guava:

public class Lazy<T> {
    private Supplier<T> supplier;

    public Lazy(Supplier<T> supplier) {
        this.supplier = () -> {
            T value = supplier.get();
            this.supplier = () -> value;
            return value;
        };
    }

    public T get() {
        return supplier.get();
    }
}

💡 Способ #2: через Spring

@Service
public class EmailService {
    private final ObjectProvider<SmtpClient> client;

    public EmailService(ObjectProvider<SmtpClient> client) {
        this.client = client;
    }

    public void sendEmail(...) {
        client.getObject().send(...);
    }
}

🧵 Итог:
- Не инициализируй тяжёлые объекты зря.
- Используй Supplier, ObjectProvider или Lazy<T>.
- Это особенно критично для тестов, лямбд и кэширования.

👉@BookJava

🧠 Spring Boot 3.2+: ускоряем стартап с помощью application.metrics.export.observation.enabled=false

Spring Boot 3.2 по умолчанию включает сбор Micrometer Observation метрик — даже если вы не используете Prometheus, Datadog и пр.
Это полезно, но часто избыточно — особенно в микросервисах, где важна скорость старта.

📌 Что это даёт?

- Отключает автоконфигурацию ObservationRegistry
- Убирает связанные Bean'ы
- Сокращает время старта до 30-60% (в зависимости от контекста)

💡 Как применить?

В application.yml или application.properties:

management:
  metrics:
    export:
      observation:
        enabled: false

Или так, если используешь .properties:

management.metrics.export.observation.enabled=false

⚠️ Важно: это не отключает другие метрики Micrometer.
Это касается только новой подсистемы Observation — она полезна для трассировки, но не всегда нужна.

📎 Документация Micrometer Observation

👉@BookJava

🧠 Spring Boot и медленные autowire — проверь, не зарыта ли у тебя бомба в @Configuration

Есть распространённый анти-паттерн: ты используешь @Configuration и внутри создаёшь бины с @Bean, а в этих методах — инжектишь зависимости через параметры. Всё выглядит красиво и «по фэншую»... но только на первый взгляд.

@Configuration
public class MyConfig {

    @Bean
    public MyService myService(SomeDep dep) {
        return new MyService(dep);
    }

    @Bean
    public SomeDep someDep() {
        return new SomeDep();
    }
}

⚠️ Проблема: такие методы вызываются при старте контекста, и если SomeDep создаётся долго (например, подтягивает настройки из удалённого конфига, делает init-запрос в БД, или тянет секьюрити-контекст), это тормозит весь старт.

📌 Хуже всего, если ты не подозреваешь об этом: ведь @Bean -методы не видны как "инициализация", и кажется, что контекст тормозит "где-то ещё".

💡 Совет:
- Используй @Lazy в нужных местах, особенно если bean тяжёлый или редко используется.
- Разделяй конфигурацию: отдельно core, отдельно init-heavy.
- Не бойся отказаться от @Configuration в пользу @Component + @Service, если это упрощает понимание.

И главное — профилируй старт. spring-boot-starter-actuator + --debug могут открыть глаза.

👉@BookJava

Осталось всего 2 дня — углубитесь в функциональное программирование на Scala в Otus 📢

24 апреля в 20:00 пройдёт открытый вебинар с Алексеем Воронцом — руководителем разработки в Naumen, 14 лет опыта, из них 9 лет на Scala. Он расскажет:

— почему Scala — функциональный язык
— как работать с ключевыми библиотеками
— как повысить выразительность кода

Если вы уже знакомы со Scala или желаете перейти на него и хотите развивать функциональный подход в своих проектах — этот вебинар для вас.

Каждый участник:
— сможет задать вопросы эксперту
— получит скидку на полный курс по Scala-разработке

👉 Не упустите возможность перейти на новый уровень — регистрируйтесь, осталось 2 дня до начала

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🧠 JPA: не забывай про flush() перед clear() — иначе словишь баг

Если ты используешь EntityManager вручную, например, при батчевой вставке или обновлении, то, скорее всего, пишешь что-то вроде:

for (int i = 0; i < entities.size(); i++) {
    em.persist(entities.get(i));
    if (i % 50 == 0) {
        em.clear(); // чтобы не росла память
    }
}

⚠️ Но тут баг: без flush() перед clear() ты теряешь все неперсистенные изменения! Hibernate просто забудет про них.

✅ Правильно так:

for (int i = 0; i < entities.size(); i++) {
    em.persist(entities.get(i));
    if (i % 50 == 0) {
        em.flush();
        em.clear();
    }
}

📌 flush() гарантирует, что все накопленные изменения пойдут в базу, а clear() уже безопасно очищает контекст.

💡 Эта ошибка особенно коварна, потому что не всегда проявляется — зависит от настроек, триггеров в БД, кэша и т.д.

👉@BookJava

Чем отличаются checked и unchecked исключения в java?

В Java исключения делятся на два основных типа: checked и unchecked. Разница между ними ключевая и касается как обработки, так и структуры кода.

✅ Checked Exceptions (Проверяемые исключения)

Примеры: IOException, SQLException, FileNotFoundException

Отличия:
1. Проверяются компилятором — вы обязаны либо обработать их с помощью try-catch, либо явно пробросить (throws) в сигнатуре метода.
2. Производные от Exception, но не от RuntimeException.
3. Используются для ситуаций, которые можно разумно ожидать и обработать (например, отсутствие файла, проблемы с сетью).

Пример:

public void readFile(String path) throws IOException {
    FileReader reader = new FileReader(path);  // может выбросить IOException
}

❌ Unchecked Exceptions (Непроверяемые исключения)

Примеры: NullPointerException, ArrayIndexOutOfBoundsException, IllegalArgumentException

Отличия:
1. Не проверяются компилятором — вы не обязаны их обрабатывать или декларировать.
2. Производные от RuntimeException.
3. Возникают в результате ошибок в логике программы или непредвиденных ситуаций.

Пример:

public void printLength(String str) {
    System.out.println(str.length());  // может выбросить NullPointerException
}

Если кратко:

Checked — ошибки среды, требующие явной обработки.

Unchecked — ошибки в логике, ответственность программиста.

👉@BookJava

🧠 Как избежать N+1 при использовании @OneToMany в JPA

Одна из самых коварных ловушек JPA - это N+1 проблема. Особенно часто она проявляется при @OneToMany, например:

@Entity
class Author {
    @OneToMany(mappedBy = "author", fetch = FetchType.LAZY)
    private List<Book> books;
}

Вы загружаете список авторов, а потом проходите по каждому и вызываете getBooks() — и BAM 💥: 1 запрос на авторов и N запросов на книги.

📌 Решение - @EntityGraph или JOIN FETCH
Оба варианта решают проблему, но @EntityGraph — декларативный и более гибкий способ:

@EntityGraph(attributePaths = "books")
List<Author> findAll(); // Spring Data JPA

⚡️ Или через JPQL:

@Query("SELECT a FROM Author a JOIN FETCH a.books")
List<Author> findAllWithBooks();

💡 Совет: всегда думайте о графе объектов. Если вам нужно сразу подтянуть связанные сущности — делайте это явно. Не надейтесь на LAZY по умолчанию.

⚠️ Осторожно с пагинацией и JOIN FETCH — могут появиться дубликаты или проблемы с LIMIT. В таких случаях лучше использовать @BatchSize или подзапросы.

👉@BookJava

🧠 JPA: подводный камень с @ElementCollection и fetch = FetchType.EAGER

Сегодня покажу, почему @ElementCollection(fetch = FetchType.EAGER) — скрытая угроза производительности и неожиданного поведения.

📌 Суть проблемы
При использовании @ElementCollection с EAGER Hibernate делает отдельный SELECT на каждую коллекцию, даже при JOIN FETCH на родительскую сущность.

@Entity
class User {
    @Id Long id;

    @ElementCollection(fetch = FetchType.EAGER)
    List<String> tags;
}

Запрос findAll() приведёт к N+1 проблеме:
1 запрос на User, потом по одному на каждый tags.

💡 Почему это больно
Даже если вы используете JOIN FETCH на User, Hibernate не может сделать JOIN на @ElementCollection. Это ограничение — Hibernate всегда грузит коллекцию отдельным запросом.

⚠️ Особенно опасно при pagination
Если вы делаете Page<User> — Hibernate сначала грузит User'ов, а затем делает N запросов на коллекции. В проде это быстро становится проблемой.

✅ Что делать
1. Делайте fetch = FetchType.LAZY (по умолчанию так и есть).
2. Если нужно подгрузить коллекцию — используйте @BatchSize:

@ElementCollection
@BatchSize(size = 20)
List<String> tags;

Или вручную:

SELECT u FROM User u LEFT JOIN FETCH u.tags WHERE u.id IN :ids

👉 Следи за @ElementCollection — он не так прост, как кажется.

👉@BookJava

Сегодня покажу вам 🧠 один тонкий момент в работе с Optional, который часто ловит даже опытных.

Многие пишут так:

Optional<String> optional = getValue();
if (optional.isPresent()) {
    doSomething(optional.get());
}

⚠️ Это антипаттерн! Вы теряете суть Optional и рискуете ошибками в многопоточке.

📌 Правильный способ — использовать функциональный стиль:

getValue().ifPresent(this::doSomething);

Или ещё элегантнее:

getValue()
    .map(this::transform)
    .filter(this::isValid)
    .ifPresent(this::doSomething);

💡 Подходы:
- map для преобразования значения
- filter для отсеивания ненужных
- orElse, orElseGet, orElseThrow для обработки отсутствия
- ifPresentOrElse в Java 9+ для двух вариантов действий

📈 Выгоды:
- Код становится компактнее
- Безопаснее при рефакторинге
- Лучше для чтения в потоковых операциях (Stream API)

🛠 Если нужно вынуть значение — используйте orElseThrow() вместо .get():

String value = getValue().orElseThrow(() -> new IllegalStateException("Value not found"));

👉 Отказывайтесь от .isPresent() и .get() связки — используйте силу функционального подхода! 🚀

👉@BookJava

🚀 Подборка Telegram каналов для программистов

Системное администрирование, DevOps 📌

https://t.me/bash_srv Bash Советы
https://t.me/win_sysadmin Системный Администратор Windows
https://t.me/sysadmin_girl Девочка Сисадмин
https://t.me/srv_admin_linux Админские угодья
https://t.me/linux_srv Типичный Сисадмин
https://t.me/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.me/linux_odmin Linux: Системный администратор
https://t.me/devops_star DevOps Star (Звезда Девопса)
https://t.me/i_linux Системный администратор
https://t.me/linuxchmod Linux
https://t.me/sys_adminos Системный Администратор
https://t.me/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.me/sysadminof Книги для админов, полезные материалы
https://t.me/i_odmin Все для системного администратора
https://t.me/i_odmin_book Библиотека Системного Администратора
https://t.me/i_odmin_chat Чат системных администраторов
https://t.me/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.me/sysadminoff Новости Линукс Linux

1C разработка 📌
https://t.me/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.me/DevLab1C 1С:Предприятие 8
https://t.me/razrab_1C 1C Разработчик
https://t.me/buh1C_prog 1C Программист | Бухгалтерия и Учёт
https://t.me/rabota1C_rus Вакансии для программистов 1С

Программирование C++📌
https://t.me/cpp_lib Библиотека C/C++ разработчика
https://t.me/cpp_knigi Книги для программистов C/C++
https://t.me/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
https://t.me/pythonofff Python академия.
https://t.me/BookPython Библиотека Python разработчика
https://t.me/python_real Python подборки на русском и английском
https://t.me/python_360 Книги по Python

Java разработка 📌
https://t.me/BookJava Библиотека Java разработчика
https://t.me/java_360 Книги по Java Rus
https://t.me/java_geek Учим Java на примерах

GitHub Сообщество 📌
https://t.me/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://t.me/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
https://t.me/developer_mobila Мобильная разработка
https://t.me/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
https://t.me/frontend_1 Подборки для frontend разработчиков
https://t.me/frontend_sovet Frontend советы, примеры и практика!
https://t.me/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
https://t.me/game_devv Все о разработке игр

Библиотеки 📌
https://t.me/book_for_dev Книги для программистов Rus
https://t.me/programmist_of Книги по программированию
https://t.me/proglb Библиотека программиста
https://t.me/bfbook Книги для программистов

БигДата, машинное обучение 📌
https://t.me/bigdata_1 Big Data, Machine Learning

Программирование 📌
https://t.me/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.me/rust_lib Полезный контент по программированию на Rust
https://t.me/golang_lib Библиотека Go (Golang) разработчика
https://t.me/itmozg Программисты, дизайнеры, новости из мира IT
https://t.me/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
https://t.me/nodejs_lib Подборки по Node js и все что с ним связано
https://t.me/ruby_lib Библиотека Ruby программиста
https://t.me/lifeproger Жизнь программиста. Авторский канал.

QA, тестирование 📌
https://t.me/testlab_qa Библиотека тестировщика

Шутки программистов 📌
https://t.me/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://t.me/thehaking Канал о кибербезопасности
https://t.me/xakep_2 Хакер Free

Книги, статьи для дизайнеров 📌
https://t.me/ux_web Статьи, книги для дизайнеров

Математика 📌
https://t.me/Pomatematike Канал по математике
https://t.me/phis_mat Обучающие видео, книги по Физике и Математике
https://t.me/matgeoru Математика | Геометрия | Логика

Excel лайфхак📌
https://t.me/Excel_lifehack

https://t.me/mir_teh Мир технологий (Technology World)

Вакансии 📌
https://t.me/sysadmin_rabota Системный Администратор
https://t.me/progjob Вакансии в IT

📌 Ошибка: Вызов метода с @Transactional внутри того же класса не запускает новую транзакцию.

Почему? Spring оборачивает бин в прокси, а внутренние вызовы проходят мимо прокси, значит, аннотация игнорируется.

Пример проблемы:

@Service
public class OrderService {

    @Transactional
    public void createOrder() {
        saveOrder();
    }

    @Transactional
    public void saveOrder() {
        // Новый транзакционный контекст не создастся!
    }
}

💡 Как правильно:
1. Вынести saveOrder() в отдельный бин.
2. Или получить прокси текущего бина через AopContext:

@Service
@EnableAspectJAutoProxy(exposeProxy = true) // важно!
public class OrderService {

    @Transactional
    public void createOrder() {
        ((OrderService) AopContext.currentProxy()).saveOrder();
    }

    @Transactional
    public void saveOrder() {
        // Теперь всё ок ✅
    }
}

⚠️ Важный момент: exposeProxy = true нужен на уровне конфигурации, иначе AopContext не заработает.


Понимание этой тонкости критично для корректного управления транзакциями в Spring! 🚀

👉@BookJava

🧠 Сегодня покажу вам полезный трюк для Spring Boot: как элегантно валидировать параметры контроллера без лишнего кода.

Часто вижу, как в контроллерах вручную проверяют @RequestParam на пустоту или формат. Это шумит код и приводит к ошибкам.

Вместо этого используйте аннотации валидации прямо на параметрах:

@RestController
@RequestMapping("/api")
@Validated // Обязательно!
public class UserController {

    @GetMapping("/users")
    public List<User> getUsers(
            @RequestParam @NotBlank String name,
            @RequestParam @Min(18) int age
    ) {
        // Если валидация не пройдена — автоматически вернётся 400 Bad Request
        return userService.findUsers(name, age);
    }
}

📌 Ключевые моменты:
- Обязательно ставим @Validated над классом контроллера.
- На параметры добавляем любые стандартные аннотации из jakarta.validation.constraints.
- Ошибки валидации Spring обработает автоматически через MethodArgumentNotValidException.

💡 Можно кастомизировать ответ на ошибку, добавив глобальный @ExceptionHandler.

⚠️ Без @Validated аннотации на контроллере валидация параметров работать не будет!

👉@BookJava

Есть фича. Есть дедлайн. Есть понимание, что тесты надо писать… но они отъедают время, которого итак впритык.

Один наш знакомый девелопер сказал: «С тех пор как поставил Explyt Test — начал писать меньше тестов… но покрытие стало лучше. Как это вообще возможно?!»

Попробуйте сами. Плагин сам предлагает тесты для вашего кода — прямо в IDE.
👉 explyt.ai — сэкономь себе пару часов уже сегодня.

В Java instance initializer blocks (блоки инициализации экземпляра) выполняются в следующем порядке:

- Они выполняются каждый раз, когда создается новый объект класса.
- Выполнение происходит после вызова конструктора родительского класса (super()), но до тела конструктора текущего класса.

Порядок инициализации:

1. Сначала инициализируются поля в порядке их объявления.
2. Затем выполняются instance initializer blocks, в том порядке, в котором они написаны в коде.
3. После этого выполняется тело конструктора.

Пример:

class Example {
    int x = 10;

    {
        System.out.println("Instance initializer block");
        x = 20;
    }

    Example() {
        System.out.println("Constructor");
        System.out.println("x = " + x);
    }

    public static void main(String[] args) {
        Example ex = new Example();
    }
}

Вывод:

Instance initializer block
Constructor
x = 20

Ключевые моменты:
- Статические блоки (static {}) — другое дело: они выполняются один раз при загрузке класса.
- Instance initializer blocks полезны для общей инициализации, которую нужно выполнять вне зависимости от того, какой конструктор вызывается.

👉@BookJava

Как работают instance initializer blocks.


Пример с родительским и дочерним классами:

class Parent {
    int a = 5;

    {
        System.out.println("Parent instance initializer");
        a = 10;
    }

    Parent() {
        System.out.println("Parent constructor, a = " + a);
    }
}

class Child extends Parent {
    int b = 15;

    {
        System.out.println("Child instance initializer");
        b = 25;
    }

    Child() {
        System.out.println("Child constructor, b = " + b);
    }
}

public class Test {
    public static void main(String[] args) {
        Child child = new Child();
    }
}

Вывод программы:

Parent instance initializer
Parent constructor, a = 10
Child instance initializer
Child constructor, b = 25

Пошаговое выполнение:

1. Сначала загружается родительский класс Parent.
2. Выполняется:
- Инициализация полей родителя (a = 5),
- Потом instance initializer блока родителя (a = 10),
- Потом конструктор родителя (Parent()).
3. Далее переходим к дочернему классу Child:
- Инициализация полей дочернего класса (b = 15),
- Потом instance initializer блока дочернего класса (b = 25),
- Потом конструктор дочернего класса (Child()).


Важный порядок действий:

1. Инициализация родителя → 2. Конструктор родителя → 3. Инициализация потомка → 4. Конструктор потомка.

Блоки инициализации всегда выполняются до тела конструктора, но после вызова super().

👉@BookJava