10986
📚 Лайфхаки, приёмы и лучшие практики для Java-разработчиков. Всё, что ускорит код и прокачает навыки. Java, Spring, Maven, Hibernate. По всем вопросам @evgenycarter РКН clck.ru/3KoGeP
🧠 Чем Spring Native Image отличается от обычного Spring-приложения?
📌 Обычный Spring:
* Запускается на JVM, динамически загружает классы, использует рефлексию.
* Медленный старт (секунды), выше потребление памяти.
* Подходит для сложной логики с динамическим поведением (настройки, рефлексия, прокси).
📌 Spring Native Image (GraalVM):
* Компиляция в нативный бинарник.
* ⚡️ Мгновенный старт (миллисекунды), низкое потребление памяти.
* Отсутствие динамики: ограничения в рефлексии, прокси и динамической загрузке.
💡 Когда что использовать?
* Native Image — идеален для микросервисов и Serverless-приложений.
* Обычный JVM Spring — когда важна максимальная гибкость и динамика.
⚠️ Помни, что Native Image требует больше усилий по настройке и ограничений на библиотеки.
📲 Мы в MAX
👉@BookJava
👨💻 Код на внимательность! Что выведет эта программа?
Посмотрите на фрагмент кода ниже. Как думаете, какой результат мы увидим в консоли? Отработает ли он вообще или упадет с ошибкой?
public class Main {
public static void main(String[] args) {
Integer a = 100;
Integer b = 100;
Integer c = 500;
Integer d = 500;
System.out.println(a == b);
System.out.println(c == d);
}
}
truefalseInteger Cache. В Java объекты класса Integer автоматически кэшируются в диапазоне от -128 до 127.a и b (значение 100) указывают на один и тот же закэшированный объект в памяти. Сравнение ссылок == для них выдаст true.c и d создаются два абсолютно разных объекта в куче. Сравнение их ссылок через == вернет false..equals()! 😉|
Как не завалить приложение из-за N+1 запросов в Hibernate 🧨
N+1 проблема — больной зуб почти любого Java-разработчика. Hibernate делает жизнь проще, пока не сталкиваешься с этим 👻
📌 Суть проблемы
Допустим, у тебя есть сущности User и связанные с ними сущности Order. При запросе пользователей:
List<User> users = userRepository.findAll(); // Один запрос
for(User user : users) {
List<Order> orders = user.getOrders(); // +1 запрос на каждого пользователя!
}
@Query("SELECT u FROM User u JOIN FETCH u.orders")
List<User> findAllWithOrders();
@EntityGraph(attributePaths = {"orders"})
List<User> findAll();
spring.jpa.properties.hibernate.default_batch_fetch_size=20
🧠 Сегодня разберём Saga — паттерн, который часто всплывает на собеседованиях уровня сеньор, особенно если речь о микросервисах.
📌 Зачем нужна Saga?
Когда нужно выполнить бизнес-операцию, затрагивающую несколько микросервисов, важно обеспечить целостность данных. Классические транзакции (@Transactional) тут не подходят — нет распределённого ACID. Saga решает эту проблему через последовательность локальных транзакций с возможностью отката (compensation).
💡 Виды Saga
1. Choreography
Нет единого оркестратора. Каждый сервис реагирует на события предыдущих через очередь (Kafka, RabbitMQ).
* Простой flow
* Меньше точек отказа
2. Orchestration
Есть выделенный "оркестратор", который координирует выполнение саги, рассылая команды сервисам.
* Более явный контроль
* Лучше трассировка
Плюсы
* Обеспечивает согласованность между сервисами
* Высокая отказоустойчивость: каждый шаг можно компенсировать
* Гибкость — легко расширять и модифицировать бизнес-логику
⚠️ Минусы
* Сложнее реализовать, чем простые транзакции
* Не моментальная консистентность — возможны временные аномалии
* Нужно проектировать compensating transactions для каждого шага
* Тяжело тестировать крайние случаи и "сорванные" шаги
🔁 Альтернативы
* Distributed Transactions (XA, 2PC) — редко используются из-за сложности и слабой поддержки в современных cloud-системах.
* Event Sourcing — другой паттерн работы с изменениями, но сложнее для чтения.
* Idempotency + Retry — иногда достаточно, если бизнес-процесс допускает.
💡 Совет: для большинства бизнес-операций с межсервисным взаимодействием, где требуется отмена — Saga остаётся самым практичным выбором. В Spring есть библиотека Axon Framework, также стоит посмотреть на Camunda.
📲 Мы в MAX
👉@BookJava
🧠 Как быстро написать компаратор в Java и не забыть про null
Часто нужно сортировать коллекции по какому-то полю. Вместо старых анонимных классов используем лямбды и статические методы из Comparator:
List<User> users = ...;
users.sort(Comparator
.comparing(User::getName, Comparator.nullsLast(String::compareToIgnoreCase))
.thenComparingInt(User::getAge)
);
comparing — сравнивает по полю (например, name).nullsLast или nullsFirst — удобно обрабатывать возможные null.thenComparingInt — дополнительная сортировка (например, по возрасту).NullPointerException во время сортировки может неожиданно прилететь в проде.
🗄 Вебинар: JDBC: как Java-приложения взаимодействуют с базами данных
JDBC позволяет Java-приложениям работать с базами данных. Разберём подключение, SQL-запросы, транзакции и обработку ошибок.
💬 О чём поговорим
- Как подключиться к СУБД с помощью DriverManager и работать с Connection.
- Как выполнять SQL-запросы через Statement и PreparedStatement и получать результаты через ResultSet.
- Как управлять транзакциями: autocommit, commit и rollback.
- Как использовать SQLException, чтобы разобраться в причинах ошибки при выполнении запроса.
🎯 Результат урока:
- Вы разберётесь, как подключать Java-приложение к СУБД, выполнять SQL-запросы и работать с результатами.
- Узнаете, как управлять транзакциями и обрабатывать ошибки при обращении к базе данных.
👉 Для участия зарегистрируйтесь: https://vk.cc/d33JSz
Вебинар проходит в рамках старта курса «Java-разработчик», который помогает освоить современную Java-разработку: от основ и первых программ до серверных приложений, баз данных, Spring, контейнеров и очередей сообщений. Программа регулярно обновляется под требования рынка. 🚀
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
🧠 10 правил безопасного Java-приложения:
1️⃣ Валидация на всех уровнях.
📌 Всегда проверяй входные данные (API, формы, запросы к БД). Используй Bean Validation (@Valid, @NotNull).
2️⃣ Используй PreparedStatement.
⚠️ Никогда не конкатенируй SQL-запросы напрямую, чтобы избежать SQL-инъекций.
3️⃣ Не раскрывай детали исключений.
📌 Отправляй клиенту общий код ошибки, а детали логируй.
4️⃣ Скрывай конфигурацию.
💡 Используй application.yml с переменными окружения для чувствительных данных (пароли, ключи API).
5️⃣ Ограничивай доступ.
📌 Spring Security — твой друг. Используй @PreAuthorize и грамотно настраивай роли и права доступа.
6️⃣ Безопасная сериализация.
⚠️ Избегай Java-стандартной сериализации. Предпочитай JSON (Jackson) с явными DTO.
7️⃣ Используй актуальные версии библиотек.
📌 Регулярно проверяй зависимости (dependency-check), чтобы избежать известных уязвимостей.
8️⃣ Грамотно логируй.
💡 Не логируй пароли, токены и персональные данные. Используй SLF4J с Logback, настрой уровень логов.
9️⃣ Безопасные куки и заголовки.
📌 Используй атрибуты куки: Secure, HttpOnly, SameSite. Spring Security поможет тебе настроить это быстро.
🔟 Настрой Security Headers.
📌 Используй заголовки:
* X-Frame-Options: DENY
* X-Content-Type-Options: nosniff
* Content-Security-Policy (CSP)
Безопасность — это не разовая задача, а процесс 💡
📲 Мы в MAX
👉@BookJava
🚀 Подборка полезных IT каналов в Max
Системное администрирование, DevOps 📌
https://max.ru/i_odmin Все для системного администратора
https://max.ru/bash_srv Bash Советы
https://max.ru/sysadminof Книги для админов, полезные материалы
https://max.ru/i_odmin_book Библиотека Системного Администратора
https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др.
https://max.ru/tipsysdmin Типичный Сисадмин
https://max.ru/channel_win_sysadmin Системный Администратор Windows
https://max.ru/channel_linux_admin Linux: Системный администратор
https://max.ru/channel_linuxmod Linux
https://max.ru/channel_i_linux Системный администратор
https://max.ru/channel_devopslib DevOps, SRE, Sysadmin
https://max.ru/channel_devops_star DevOps Star (Звезда Девопса)
Excel лайфхак 📌
/channel/Excel_lifehack Excel лайфхак
Английский с нуля 🇬🇧
https://max.ru/UchuEnglish
1C разработка 📌
https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://max.ru/channel_DevLab1C 1С:Предприятие 8
Программирование C++📌
https://max.ru/cpp_lib Библиотека C/C++ разработчика
https://max.ru/channel_cpp_geek C++ geek
Программирование Go📌
https://max.ru/golang_lib Библиотека Go (Golang) разработчика
Программирование React📌
https://max.ru/react_lib React
Программирование Rust📌
https://max.ru/channel_rust_lib
Программирование Python 📌
https://max.ru/python_of Python академия.
https://max.ru/BookPython Библиотека Python разработчика
Java разработка 📌
https://max.ru/bookjava Библиотека Java разработчика
https://max.ru/channel_java_geek Java Geek
GitHub Сообщество 📌
https://max.ru/githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://max.ru/database_info Все про базы данных
Фронтенд разработка 📌
https://max.ru/frontend_1 Подборки для frontend разработчиков
Библиотеки 📌
https://max.ru/programmist_of Книги по программированию
https://max.ru/proglb Библиотека программиста
https://max.ru/bfbook Книги для программистов
Программирование 📌
https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций
https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT
https://max.ru/php_lib Библиотека PHP программиста 👨🏼💻👩💻
Шутки программистов 📌
https://max.ru/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://max.ru/thehaking Канал о кибербезопасности
https://max.ru/xakkep_1 Хакер Free
Книги, статьи для дизайнеров 📌
https://max.ru/odesigners Статьи, книги для дизайнеров
Математика 📌
https://max.ru/Pomatematike Канал по математике
https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике
Вакансии в IT📌
https://max.ru/progjob
https://max.ru/channel_rabotait
Мир технологий 📌
https://max.ru/mir_teh Канал для любознательных
Городские📌
https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга
https://max.ru/mockva_life Свежие новости Москвы
https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
https://max.ru/channel_krasnodar_novosty Краснодар Новости
https://max.ru/channel_novosibirsk_novosti Новосибирск
https://max.ru/channel_samara_novosti Новости Самары
https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга
https://max.ru/channel_kazan_novosti Новости Казани
https://max.ru/channel_omsk_novosti Новости Омска
https://max.ru/channel_moskva_24 Москва 24
📌 Stream API: забудьте про peek()
Метод peek() в Java Stream API выглядит удобным для отладки, но его использование в реальном коде часто приводит к проблемам.
⚠️ Почему не стоит полагаться на peek()?
* peek() — промежуточная операция, которая не гарантирует вызов функции для каждого элемента стрима.
* Поведение зависит от терминальной операции: например, при некоторых оптимизациях JDK (особенно в параллельных стримах) вызов peek() может быть пропущен или работать непредсказуемо.
💡 Пример опасного кода:
List<String> names = Stream.of("Java", "Spring", "Hibernate")
.peek(System.out::println) // 👈 анти-паттерн!
.collect(Collectors.toList());
peek() исключительно для дебага, но никогда — для изменения состояния или важных операций.
List<String> names = Stream.of("Java", "Spring", "Hibernate")
.map(name -> {
log.info("Processing: {}", name); // или другая логика
return name;
})
.collect(Collectors.toList());
peek().
Три похожих слова в Java — final, finally, finalize — но смысл у них совершенно разный. Разберёмся 🧠
🔒 final
Ключевое слово. Используется для ограничений:
* final class — нельзя наследовать.
* final method — нельзя переопределить.
* final variable — нельзя изменить значение (один раз присвоил — всё).
📌 Особенно важно для immutability и thread-safety.
final int x = 10;
x = 20; // ошибка компиляции
finallytry-catch-finally. Выполняется всегда, даже если был return или exception.
try {
// что-то может выбросить исключение
} catch (Exception e) {
// обработка ошибки
} finally {
// всегда выполнится
}
finalize()Object, вызывался перед удалением объекта сборщиком мусора.AutoCloseable и try-with-resources.
@Override
protected void finalize() throws Throwable {
System.out.println("До свидания...");
}
final — про нельзя менятьfinally — про всегда выполнитсяfinalize — про устаревший и бесполезный метод
Что такое механизм try-with-resources?
Механизм try-with-resources в Java — это конструкция, которая упрощает работу с ресурсами, требующими закрытия (например, файлы, сокеты, соединения с БД и т.д.). Он автоматически закрывает ресурсы после завершения блока try, избавляя от необходимости писать finally вручную.
📌 Поддерживается с Java 7
📌 Ресурсы должны реализовывать интерфейс AutoCloseable
💡 Пример:
try (BufferedReader reader = new BufferedReader(new FileReader("file.txt"))) {
String line = reader.readLine();
System.out.println(line);
} catch (IOException e) {
e.printStackTrace();
}
// reader будет закрыт автоматически, даже если произойдёт исключение
BufferedReader reader = new BufferedReader(new FileReader("file.txt"));
try (reader) {
System.out.println(reader.readLine());
}
Double-brace инициализация в Java — это идиома, которая используется для инициализации коллекций (и иногда других объектов) в краткой форме. Она выглядит как две открывающие фигурные скобки подряд {{ и имеет специфическое поведение. Пример:
import java.util.*;
List<String> list = new ArrayList<String>() {{
add("one");
add("two");
add("three");
}};
new ArrayList<String>() { ... }
ArrayList.
{{ ... }}
add()).final, например:
private static final Set<String> set = new HashSet<>() {{
add("A");
add("B");
}};
Stream и Collectors):
List<String> list = Stream.of("one", "two", "three")
.collect(Collectors.toList());
public static List<String> createList() {
List<String> list = new ArrayList<>();
list.add("one");
list.add("two");
return list;
}
List<String> list = List.of("one", "two", "three");
Set<String> set = Set.of("A", "B");
🧠 Трюк с @EventListener в Spring — убираем лишний @TransactionalEventListener
Когда тебе нужно обрабатывать события в рамках транзакции, мы часто пишем:
@TransactionalEventListener
public void handleEvent(MyEvent event) {
// ...
}
@TransactionalEventListener по умолчанию срабатывает после коммита. Иногда это не очевидно и вызывает баги, особенно если ожидаешь, что событие обработается внутри транзакции.@EventListener, но вместе с TransactionSynchronizationManager.
@Component
public class MyEventHandler {
@EventListener
public void handle(MyEvent event) {
if (TransactionSynchronizationManager.isActualTransactionActive()) {
TransactionSynchronizationManager.registerSynchronization(
new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
// обработка события после коммита
}
}
);
} else {
// fallback: нет активной транзакции — выполняем сразу
}
}
}
🧠 Как не словить LazyInitializationException в Spring Boot + Hibernate
Одна из самых частых ошибок при работе с JPA:
org.hibernate.LazyInitializationException: failed to lazily initialize a collection
LAZY) обращается к БД вне транзакции — например, в слое контроллера или после закрытия Session.@Transactional в сервисе@Transactional:
@Transactional
public UserDto getUser(Long id) {
User user = userRepository.findById(id)
.orElseThrow();
// OK: коллекция friends будет инициализирована в транзакции
return new UserDto(user.getName(), user.getFriends());
}
@Transactional в контроллерах - это плохая практика.JOIN FETCH:
@Query("SELECT u FROM User u LEFT JOIN FETCH u.friends WHERE u.id = :id")
Optional<User> findByIdWithFriends(@Param("id") Long id);
@Query("""
SELECT new com.example.UserDto(u.name, f.name)
FROM User u
LEFT JOIN u.friends f
WHERE u.id = :id
""")
List<UserDto> findUserWithFriendNames(@Param("id") Long id);
fetch join - ваши лучшие друзья, если нужен контроль и производительность.
🧠 Spring Boot: ленивые зависимости через ObjectProvider
Иногда сервису не нужно всегда инжектить другую зависимость при старте — только иногда по ходу работы. Но @Autowired всё равно тянет её сразу, даже если она вам пока не нужна. Это бьёт по времени старта и может вызвать циклические зависимости.
💡 Решение: использовать ObjectProvider<T>.
Пример:
@Service
public class NotificationService {
private final ObjectProvider<EmailSender> emailSenderProvider;
public NotificationService(ObjectProvider<EmailSender> emailSenderProvider) {
this.emailSenderProvider = emailSenderProvider;
}
public void sendEmailIfEnabled(String to, String body) {
if (featureEnabled()) {
EmailSender sender = emailSenderProvider.getIfAvailable();
if (sender != null) {
sender.send(to, body);
}
}
}
}
ObjectProvider:getIfAvailable() / ifAvailable(...));stream() — для коллекций бинов.
🤯 Java-хардкор: найди неочевидную ошибку!
Сегодня задачка со звездочкой. На первый взгляд, код абсолютно рабочий и логичный. Мы создаем класс-наследник, переопределяем метод и вызываем его.
Что выведет этот код при запуске?
public class Main {
static class Parent {
public Parent() {
init();
}
void init() {
System.out.println("Инициализация родителя");
}
}
static class Child extends Parent {
private String name = "Java";
@Override
void init() {
System.out.println("Длина имени: " + name.length());
}
}
public static void main(String[] args) {
new Child();
}
}
Длина имени: 4Инициализация родителяNullPointerException во время выполненияmain мы вызываем конструктор new Child().Child неявно вызывает конструктор суперкласса - super() (то есть конструктор Parent).Parent вызывается метод init().init() из класса Child!Child.init() пытается вычислить name.length().Child (и присвоение им значений, таких как "Java") инициализируются только после того, как отработает конструктор родителя Parent!init() поле name еще равно null. Вызов .length() у null приводит к NullPointerException.
👨🏻🎓Хотите сменить профессию, но не знаете, с чего начать?
Кибербезопасность можно освоить с нуля!
На ней расскажут, как устроено обучение, какие направления есть в профессии (пентест, защита, SOC-аналитика) и с чего лучше стартовать именно вам.
🧠 Сейчас расскажу о распределённых транзакциях в Java и почему их стоит использовать с осторожностью.
Когда твое приложение работает с несколькими источниками данных (например, двумя базами или базой + очередью), часто появляется соблазн обернуть всё в одну большую транзакцию с помощью JTA (Java Transaction API) и XA-ресурсов. Но на практике это почти всегда антипаттерн.
📌 Почему?
* XA-транзакции медленные и сложно отлаживаются.
* Они ломают горизонтальное масштабирование: один сбой — откат по всем участникам.
* Могут приводить к блокировкам и deadlock-ам, если инфраструктура нестабильна.
💡 Современные альтернативы:
1. Transaction outbox pattern — сначала пишем событие/задачу в outbox-таблицу в той же БД, где меняем данные, и только потом публикуем во внешний сервис.
2. Event sourcing — строим архитектуру так, чтобы любые изменения происходили через событийную модель (и проще компенсировать сбои).
3. Idempotency & retries — делаем операции идемпотентными и безопасными к повтору.
⚠️ Не используешь JTA без реальной необходимости. Spring Boot 3+ по умолчанию уже не настраивает JTA — и правильно делает.
Если всё же нужен XA:
* Используй Atomikos, Narayana или Bitronix — это современные провайдеры.
* Но всегда сначала подумай: "Могу ли я упростить архитектуру и уйти от XA?"
Пример из кода на Spring Boot:
// НЕ рекомендуется:
@EnableTransactionManagement
public class Config {
@Bean
public JtaTransactionManager transactionManager() {
return new JtaTransactionManager();
}
}
// Лучше outbox + отдельный publisher
Чем абстрактный класс отличается от интерфейса? В каких случаях следует использовать абстрактный класс, а в каких интерфейс?
• В Java класс может одновременно реализовать несколько интерфейсов, но наследоваться только от одного класса.
Абстрактные классы используются только тогда, когда присутствует тип отношений «is a» (является). Интерфейсы могут реализоваться классами, которые не связаны друг с другом.
• Абстрактный класс - средство, позволяющее избежать написания повторяющегося кода, инструмент для частичной реализации поведения. Интерфейс - это средство выражения семантики класса, контракт, описывающий возможности. Все методы интерфейса неявно объявляются как public abstract или (начиная с Java 8 default - методами с реализацией по-умолчанию, а поля - public static final.
• Интерфейсы позволяют создавать структуры типов без иерархии.
• Наследуясь от абстрактного, класс «растворяет» собственную индивидуальность. Реализуя интерфейс, он расширяет собственную функциональность.
Абстрактные классы содержат частичную реализацию, которая дополняется или расширяется в подклассах. При этом все подклассы схожи между собой в части реализации, унаследованной от абстрактного класса, и отличаются лишь в части собственной реализации абстрактных методов родителя. Поэтому абстрактные классы применяются в случае построения иерархии однотипных, очень похожих друг на друга классов. В этом случае наследование от абстрактного класса, реализующего поведение объекта по умолчанию может быть полезно, так как позволяет избежать написания повторяющегося кода. Во всех остальных случаях лучше использовать интерфейсы.
📲 Мы в MAX
👉@BookJava
Сегодня покажу вам интересный костыль, который до сих пор живёт в JDK и влияет на сортировку списков.
🧠 Если ты когда-нибудь пробовал сортировать LinkedList через Collections.sort(), знай — под капотом происходит скрытая магия.
📌 Collections.sort(list) сначала проверяет, какой это список. Если это RandomAccess-list (например, ArrayList) — используется быстрый сортировщик (TimSort) прямо по массиву.
⚠️ Но если это LinkedList (или любой не-рандом-доступ список), внутри происходит... преобразование списка в массив! Сначала все элементы копируются в массив, потом сортируются, а затем результат обратно заливается в твой список.
// Да, это реально работает так:
List<Integer> list = new LinkedList<>();
// ...заполняем...
Collections.sort(list);
Что такое тернарный оператор выбора?
Тернарный условный оператор ?: - оператор, которым можно заменить некоторые конструкции операторов if-then-else.
Выражение записывается в следующей форме:условие ? выражение1 : выражение2
Если условие выполняется, то вычисляется выражение1 и его результат становится результатом выполнения всего оператора. Если же условие равно false, то вычисляется выражение2 и его значение становится результатом работы оператора. Оба операнда выражение1 и выражение2 должны возвращать значение одинакового (или совместимого) типа.
📲 Мы в MAX
👉@BookJava
🧠 Проверяешь аргументы вручную? Используй мощь системы типов Java!
📌 Ситуация: часто в методах видишь явные проверки вроде:
public void process(User user) {
if (user == null || user.getName() == null) {
throw new IllegalArgumentException("User или его имя не могут быть null");
}
// код обработки...
}
import java.util.Objects;
public void process(User user) {
Objects.requireNonNull(user, "User не должен быть null");
Objects.requireNonNull(user.getName(), "Имя пользователя не должно быть null");
// код обработки...
}
import lombok.NonNull;
public void process(@NonNull User user) {
// Lombok автоматически вставит проверку на null
}
📌 Обход коллекций в Java: делаем правильно!
Часто вижу, как разработчики по привычке используют старый подход с циклом for. Сегодня напомню оптимальные способы перебора коллекций в Java.
🧠 1. Foreach (Java 5+)
Коротко, ясно, подходит для большинства задач:
for (String item : collection) {
// обработка элемента
}
collection.forEach(item -> {
// обработка элемента
});
collection.stream()
.filter(Objects::nonNull)
.map(String::toUpperCase)
.forEach(System.out::println);
collection.forEach().
🧠 Dependency Inversion Principle (D в SOLID)
Зависимости должны идти от высокоуровневой политики к низкоуровневым деталям, а не наоборот. Абстракции — хозяева, реализации — обслуживающий персонал.
📌 Коротко о сути
* Модули верхнего уровня (бизнес-логика) зависят только от интерфейсов/абстракций.
* Модули нижнего уровня (база, сеть, файлы) также зависят от тех же абстракций.
* Сами абстракции не знают ничего о деталях, тем самым разрывая «бетонную» сцепку между слоями.
💡 Мини-пример (Java 17+, Spring Boot 3+)
// 1️⃣ Абстракция — контракт
public interface NotificationSender {
void send(Message msg);
}
// 2️⃣ Верхний уровень — бизнес-служба
@Service
public class BillingService {
private final NotificationSender sender;
public BillingService(NotificationSender sender) {
this.sender = sender; // зависим от контракта
}
public void bill(Client c) {
// ...
sender.send(new Message("Invoice #42"));
}
}
// 3️⃣ Низкий уровень — деталь
@Component
public class EmailSender implements NotificationSender {
public void send(Message msg) {
// SMTP-магия
}
}
final = явная зависимость.TransferPort, а не JdbcTransferRepository).class. Если появится второй вариант — быстро вынесешь интерфейс (IDE поможет).
🧠 Ленивая инициализация через Supplier — элегантная альтернатива double-checked locking
Когда нужно отложить создание тяжёлого объекта до первого обращения, многие вспоминают double-checked locking:
private volatile SomeHeavyObject obj;
public SomeHeavyObject getObj() {
if (obj == null) {
synchronized (this) {
if (obj == null) {
obj = new SomeHeavyObject();
}
}
}
return obj;
}
Supplier с ленивой инициализацией:
private final Supplier<SomeHeavyObject> lazyObj = Suppliers.memoize(SomeHeavyObject::new);
public SomeHeavyObject getObj() {
return lazyObj.get();
}
Suppliers.memoize — из Guava. Он гарантирует потокобезопасную инициализацию один раз при первом вызове get().AtomicReference и updateAndGet, но это уже длиннее и менее выразительно.@Lazy. Но вне Spring, в обычных Java-приложениях или утилитах — Supplier с memoize() идеален.
📌 picocli — это современная библиотека для создания CLI-приложений на Java. Она упрощает разработку командных интерфейсов, обеспечивая:
* Автоматическую генерацию --help и --version
* Поддержку подкоманд (как в git commit, git push)
* Аргументы, параметры, опции с короткими и длинными флагами (-v, --verbose)
* Интеграцию с GraalVM (подходит для нативной компиляции)
* Поддержку аннотаций (аннотируй POJO — и готово!)
* Автоматическую валидацию аргументов
* Цветной вывод и гибкое форматирование
* Интерактивный режим и автодополнение
Проект активно развивается, полностью документирован и используется в сотнях продакшн-проектов. Если ты ищешь мощную и простую в использовании CLI-библиотеку на Java — picocli отличный выбор.
https://github.com/remkop/picocli
📲 Мы в MAX
👉@BookJava
🧠@Value vs @ConfigurationProperties — не выбирай наобум
Оба способа хороши для конфигурации, но используют их по-разному. И если ты всё ещё везде пихаешь @Value, держи краткий гайд, когда лучше что:
📌 @Value — просто, но не гибко:
@Value("${my.prop}")
private String value;
TestPropertySource) @ConfigurationProperties — сила и масштаб:
@ConfigurationProperties(prefix = "app.feature")
public class FeatureProperties {
private boolean enabled;
private List<String> items;
}
@EnableConfigurationProperties или аннотируй как @Component@Validated)/actuator/configprops)@Value внутрь @ConfigurationProperties — это антипаттерн.@Value норм. Но как только появляется структура, коллекции, логика — всегда используй @ConfigurationProperties.
👩💻 HTTP-сервер на чистой Java за 30 минут
Приглашаем на открытый урок.
🗓 21 сентября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «Java разработчик. Продвинутый уровень».
Разберем, как браузер общается с сервером, и создадим работающий HTTP-сервис без Spring и сторонних библиотек.
О чем поговорим:
✔️ Как устроен HTTP-запрос
✔️ Создадим сервер на Java
✔️ Добавим несколько адресов
✔️ Откроем результат в браузере
✔️ Разберём, что скрывает Spring
🔗 Ссылка на регистрацию: https://vk.cc/d1sLwn
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
📌 Java Collections
📲 Мы в MAX
👉@BookJava
💡 Чем опасен @Scheduled(fixedRate) без @Transactional?
Расписание в Spring через @Scheduled — удобный способ запускать задачи по таймеру. Но часто разработчики забывают про транзакции, особенно с fixedRate, и попадают в ловушку.
📌 Пример проблемы:
@Scheduled(fixedRate = 10_000)
public void cleanUp() {
List<Job> jobs = jobRepository.findAllByStatus(PENDING);
jobs.forEach(job -> {
job.setStatus(PROCESSING);
jobRepository.save(job);
});
}
PENDING -записи.
@Transactional
@Scheduled(fixedRate = 10_000)
public void cleanUp() {
List<Job> jobs = jobRepository.findAllByStatusForUpdate(PENDING); // SELECT ... FOR UPDATE
jobs.forEach(job -> {
job.setStatus(PROCESSING);
jobRepository.save(job);
});
}
@Scheduled(fixedDelay) — он ждёт завершения предыдущего запуска. Это безопаснее по умолчанию.@Scheduled на: