Как сделать так, чтобы Spring-приложение динамически включало или отключало фичи без изменения Java-кода? Подсказка: условные бины — ключ к решению 👀

Условные бины позволяют управлять созданием и загрузкой бина в Spring по определённому условию. Это как if для компонентов. Так можно сделать приложение гибким -> включать и отключать фичи или менять поведение через конфиг или зависимости проекта, не меняя Java-код.

Для этого используют аннотации, начинающиеся с @Conditional, которые ставят на методы с @Bean или на классы с @Component. Если условие выполнено, Spring создаёт бин. Если нет, то бин игнорируется.

Примеры часто используемых аннотаций:

@ConditionalOnProperty проверяет, есть ли у свойства в application.properties заданное значение. Это основной способ для feature toggling.

@ConditionalOnClass проверяет, есть ли определённый класс в classpath. Удобно, если нужно создавать бин только при наличии библиотеки.

@ConditionalOnMissingBean создаёт бин, только если нет другого бина такого же типа. Подходит для дефолтных или fallback-компонентов.

@ConditionalOnWebApplication создаёт бин только если приложение работает как веб-приложение, например под Tomcat.

👉 Java Portal

А что если Java-приложение могло бы запускаться за миллисекунды и потреблять совсем немного памяти, как программы на Go или C++

GraalVM решает эту задачу. Он компилирует Java и Spring Boot напрямую в нативный исполняемый файл. Это происходит заранее на этапе сборки в отличие от стандартной JVM, которая компилирует код во время выполнения. В результате получается бинарь, который запускается без JVM

Преимущества заметные, почти мгновенный старт, сокращенное потребление памяти, меньший размер пакета. Такой подход особенно удобен для микросервисов и облачных приложений

Есть и минусы, время сборки увеличивается, а итоговый бинарь зависит от платформы. Для Linux и Windows нужны отдельные файлы в отличие от переносимого JAR

По производительности GraalVM нативные образы близки к C++. Старт сопоставим по скорости. При тяжелых вычислительных задачах преимущество может быть у C++ благодаря управлению памятью на низком уровне. Но для большинства сценариев GraalVM выводит Java в ту же лигу, что и C++, сохраняя при этом безопасность и удобство разработки

👉 Java Portal

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

• Задержки + глобальная аудитория → CDN. Доставляем данные с edge-серверов, чтобы уменьшить latency.
• Чтение + узкое место → кэш. Часто читаемые данные кладём в кэш, разгружая базу.
• Запись + всплеск трафика → очередь. Пишем асинхронно, сглаживая пики нагрузки.
• Распределённая транзакция → Saga. Координируем шаги с компенсациями между сервисами.
• ACID + реляционка → SQL. Строгая консистентность и транзакции.
• Гибкость + масштаб → NoSQL. Подходит для схемы без фиксированной структуры и горизонтального масштабирования.
• SQL + рост → шардинг. Делим базу на шарды, чтобы тянуть нагрузку.
• Нагрузка + рост → scale out. Добавляем сервера, а не апгрейдим один.
• Трафик + надёжность → балансировка. Распределяем запросы для стабильности.
• Критичные сервисы + отказ → резервирование. Дублируем, чтобы не было single point of failure.
• Долговечность + сбои → репликация. Держим копии данных для доступности и восстановления.
• Запросы + всплески → троттлинг. Ограничиваем лишние запросы.
• Нагрузка + пики → автоскейлинг. Автоматически подгоняем мощность под трафик.
• Реалтайм + обновления → WebSockets. Двунаправленное живое соединение.
• Повтор + безопасность → идемпотентность. Повторяем операции без побочных эффектов.

👉 Java Portal

Не знаешь, как написать Dockerfile?

Не переживай, Spring Boot сделает это за тебя. 😁

Вот как это работает.

В Spring Boot есть встроенный механизм для сборки Docker-образов без Dockerfile. Начиная с версии 2.3, он использует buildpacks, чтобы упаковать твоё приложение вместе с JDK в стандартный OCI-образ. Образ собирается слоями: зависимости, ресурсы и твой код разделяются, что ускоряет пересборку. После этого образ можно запускать как обычный Docker-контейнер.

👉 Java Portal

Скучаешь? Попробуй собрать что-нибудь своё:

• 3D игру
• 3D-рендерер
• Свой язык для JVM
• свой первый блокчейн на Java
• Android-приложение для Reddit

И это только начало, вот целая подборка ✌️

👉 Java Portal

Когда ты создаешь бин в Spring, его scope определяет, сколько времени он будет жить и как именно шариться между разными частями приложения.

По умолчанию все бины работают как singleton. Это значит, что Spring поднимает один экземпляр при старте и потом везде отдает именно его. Такой вариант подходит для сервисов и репозиториев, где не нужно хранить состояние.

Есть вариант prototype. В этом случае при каждом запросе Spring возвращает новый экземпляр. Но если прототип внедрен внутрь singleton, то на деле получится один и тот же объект, потому что сам singleton создается один раз и сохраняет то, что ему подкинули при инициализации.

В веб-приложениях добавляются дополнительные варианты.

Request создает новый бин на каждый HTTP-запрос.

Session закрепляет бин за конкретной пользовательской сессией, так что один и тот же объект сохраняется для одного пользователя между запросами.

Application делает бин общим для всего приложения, по сути работает как singleton, но привязан к контексту сервлета.

Websocket создает бин, живущий столько, сколько длится одно websocket-соединение.

Если свести все в одно короткое объяснение, singleton глобален, prototype всегда создает новый объект, а веб-скоупы зависят от времени жизни запроса или сессии. 🍺

👉 Java Portal

Уровни изоляции в базах данных за 5 минут

ACID описывает свойства, гарантирующие надежность транзакций. Но даже если СУБД заявляет поддержку ACID, по умолчанию она может использовать более слабый уровень изоляции.

Разным приложениям нужно разное, где-то важна скорость и можно потерпеть небольшие несостыковки, а где-то критична строгая целостность данных. Проблема в том, что параллельное выполнение транзакций без контроля ведет к аномалиям: dirty read, non-repeatable read, phantom read

Уровни изоляции определяют, насколько одна транзакция защищена от последствий других, выполняющихся одновременно.

• Read Uncommitted (минимальный уровень)

Транзакции вообще не изолированы. Видно изменения других транзакций даже до их коммита. Это может привести к dirty reads.

• Read Committed

Транзакция видит только закоммиченные данные. Dirty reads исключены, но non-repeatable reads остаются возможны.

• Repeatable Read

Транзакция работает с "замороженным снимком" базы на момент старта. Изменения других транзакций ей не видны. Реализация бывает через блокировки (shared locks) или MVCC (мультиверсии строк). Это убирает non-repeatable reads.

• Serializable

Максимальная строгость. Всё выглядит так, будто транзакции идут последовательно одна за другой. Для этого применяются жесткие блокировки вроде range/predicate locks.

Чем выше уровень изоляции, тем больше гарантий целостности, но тем сильнее удар по производительности. Нужно выбирать баланс под конкретную задачу. 😣

👉 Java Portal

Задумывался, почему случайные числа в Java на самом деле не совсем случайные? 😏

В Java они генерируются с помощью так называемого псевдослучайного генератора чисел. Ключевое слово тут «псевдо» - числа выглядят случайными, но на самом деле вычисляются на основе исходного значения - seed (зерна).

Seed задаёт начальное состояние генератора. Если создать два генератора с одинаковым seed, они будут возвращать абсолютно одинаковую последовательность чисел. Это делает случайные числа воспроизводимыми, что удобно для тестов или симуляций.

Если seed явно не указывать, Java использует текущее системное время для инициализации. Поэтому при каждом запуске результат будет разным.

👉 Java Portal

JEP 519: Compact Object Headers готов к релизу вместе с Java25

А ещё подъехали Compact Source Files

👉 Java Portal

В работе с API на Spring Boot часто встречаются три термина: DTO, ModelMapper, Jackson. Разберём, что это и зачем нужно.

1. DTO

DTO это простой Java-класс, который используется для передачи данных между слоями (Controller <-> Service <-> Client).

Почему не использовать Entity напрямую?

- В Entity часто есть лишние поля (ID из БД, служебные поля аудита), которые клиенту видеть не нужно.
- Можно случайно засветить чувствительные данные.
- DTO позволяет держать API-контракты стабильными, даже если структура базы поменялась.

Пример DTO:

class UserDTO {
    private String name;
    private String email;
}

2. ModelMapper

ModelMapper это библиотека для автоматического маппинга DTO <-> Entity.

Без него пришлось бы вручную писать:

dto.setName(entity.getName());
dto.setEmail(entity.getEmail());

С ModelMapper это превращается в:

UserDTO dto = modelMapper.map(userEntity, UserDTO.class);

Плюсы: меньше шаблонного кода.
Минусы: для сложных кейсов нужна настройка, а ещё можно легко пропустить баг в маппинге, если полагаться только на автоматику.

3. Jackson

Jackson это библиотека, которую Spring Boot использует для (де)сериализации JSON.

Что делает:

- Превращает Java-объекты в JSON (ответ API).
- Превращает JSON в Java-объекты (тело запроса).

Пример:

{ "name": "Sumit", "email": "sumit@email.com" }

автоматически маппится в UserDTO в контроллере.

Как они работают вместе:

- Jackson: JSON <-> DTO
- ModelMapper: DTO <-> Entity
- DTO: слой-контракт между внешними клиентами и внутренними моделями

DTO защищает доменную модель, Jackson работает с JSON, а ModelMapper убирает рутину маппинга.

👉 Java Portal

Ты на собеседовании на бэкенд-разработчика. Интервьюер спрашивает:

В чем разница между Future и CompletableFuture в Java?

Обычно на это отвечают размыто. Давай разложим по полочкам.

Что такое Future

• Появился в Java 5 вместе с Executor framework.
• Представляет результат асинхронного вычисления.
• Обычно ты отдаешь Callable в ExecutorService, который возвращает Future<T>.

С ним можно:

• вызвать get() → блокирует поток, пока задача не завершится
• вызвать isDone() → проверить, закончилась ли задача
• вызвать cancel() → попытаться отменить выполнение

И на этом все. Future дает контроль над ожиданием, но никак не управляет тем, что делать, когда результат готов.

Что добавляет CompletableFuture

• Появился в Java 8, реализует Future и CompletionStage.
• Все еще является Future (можно блокироваться, если хочется), но гораздо функциональнее.
• Поддерживает неблокирующие коллбеки (thenApply, thenAccept, thenRun).
• Позволяет комбинировать задачи (thenCombine, allOf, anyOf).
• Умеет завершаться вручную через complete(), чего у Future нет.
• Даёт более гибкую обработку ошибок (exceptionally, handle).

Главная разница

С Future ты просто ждешь результат. С CompletableFuture ты описываешь, что должно произойти, когда результат появится.

👉 Java Portal

Полезная находка для разработчиков и студентов - - Wokwi, онлайн-симулятор Arduino и других микроконтроллеров.

Платформа позволяет собирать и запускать проекты прямо в браузере с использованием виртуальных компонентов и встроенных инструментов отладки. Поддерживаются Arduino, ESP32, STM32 и Raspberry Pi Pico.

Wokwi уже набирает популярность в сообществе, так что можно протестировать идеи без физического железа 💪

Попробовать можно тут: wokwi.com

👉 Java Portal

Аннотация @Transactional не работает, когда ты вызываешь метод из другого метода в том же классе?

Это не баг, а классическая особенность Spring AOP по дизайну.

Знаешь, почему транзакция вообще не стартует?

Проблема в том, как Spring AOP создаёт прокси. Когда ты ставишь @Transactional на метод, Spring не правит байткод класса. Вместо этого он создаёт прокси-объект, который оборачивает твой бин.

Этот прокси перехватывает внешние вызовы метода, запускает транзакцию и потом делегирует вызов реальному методу бина.

Это отлично работает, когда внешний бин вызывает твой публичный транзакционный метод, потому что вызов проходит через прокси.

Но при самовызове внутри класса (например, this.someTransactionalMethod()) ты вызываешь метод напрямую на целевом объекте (this), а не через прокси. Транзакционный advice прокси полностью обходится, поэтому транзакция не стартует. Это фундаментальное следствие прокси-based AOP.

Чтобы исправить, самое чистое и продакшен-готовое решение это вынести транзакционный метод в отдельный Spring-бин и инжектить его. Тогда вызов всегда будет внешним и пройдёт через прокси, корректно поднимая транзакцию каждый раз. 🙈

👉 Java Portal

Stateful vs Stateless дизайн

Stateless-дизайн сделал возможным простые, но при этом масштабируемые и быстрые приложения. Вместо хранения состояния в памяти сервера, каждый запрос несет все данные для своей обработки. Это убрало лишние накладные расходы и позволило легко масштабировать системы.

Stateful-приложения работают иначе. Они хранят данные вроде user ID, сессий и настроек, что дает персонализацию и избавляет от передачи повторяющейся информации. Но из-за этого тяжело масштабироваться горизонтально.

Stateless-подход стал основой для микросервисов, serverless и REST API. Он ускоряет работу CDN и повышает эффективность сервисов. Но у него есть минусы - - большие размеры запросов, избыточная передача данных и сложности в сценариях, где состояние критично.

На практике чаще выбирают гибрид — сочетание stateful и stateless. Баланс позволяет сделать систему масштабируемой, простой и быстрой, не жертвуя функциональностью 💪

👉 Java Portal

Твой запрос не попадает напрямую в контроллер. Он проходит через цепочку фильтров — Filter Chain. Это основа Spring Security.

Когда HTTP-запрос попадает в Java-приложение, он никогда не идет напрямую в контроллер. Сначала он проходит через Filter Chain — упорядоченную последовательность фильтров, которые могут проверить, изменить или заблокировать запрос до того, как выполнится твой код.

Эта идея пришла из Servlet API. Фильтр реализует метод doFilter(request, response, chain). Внутри можно сделать предобработку (например, логирование или проверку заголовков), вызвать chain.doFilter(request, response), чтобы передать запрос дальше, или прервать выполнение, фактически заблокировав запрос (например, вернув 403 Forbidden).

Spring Security расширяет это через FilterChainProxy, который управляет одним или несколькими SecurityFilterChains. Каждая цепочка применяется к своим URL-паттернам и содержит строго упорядоченный набор фильтров.

Примеры:

• Аутентификационные фильтры (например, UsernamePasswordAuthenticationFilter или кастомный JWT-фильтр) определяют личность пользователя.
• Фильтр авторизации проверяет права и роли.
• Фильтр управления сессией отвечает за логин-сессии.
• CSRF-фильтр защищает от подделки запросов.
• Фильтр перевода исключений гарантирует, что ошибки безопасности вернут правильный ответ.

Порядок имеет значение: аутентификация должна происходить раньше авторизации, CSRF-проверка — до обработки запроса, а обработка исключений должна оборачивать всю цепочку. Поэтому Spring предоставляет методы addFilterBefore и addFilterAfter для кастомизации.

Только после прохождения всех нужных проверок запрос попадает в контроллер.

Простой поток:
Request → Filter Chain → Controller → Response → Filter Chain → Client

👉 Java Portal

Ты тоже путаешься в этих двух терминах Reverse Proxy и Load Balancer, давай разберёмся

Reverse proxy ставится перед твоими серверными приложениями и проксирует к ним клиентские запросы, его задачи не ограничиваются распределением трафика, он также может делать SSL termination и обрабатывать HTTPS, выполнять аутентификацию и авторизацию, кэшировать ответы, скрывать внутренние детали инфраструктуры, трансформировать запросы и ответы. Примеры NGINX, Apache, HAProxy

Load balancer это частный случай reverse proxy, но с более узкой задачей, распределять входящий трафик между несколькими серверами, он сфокусирован на производительности и доступности, балансировщик следит чтобы ни один сервер не был перегружен и берёт на себя фейловер если один из них отваливается. Примеры HAProxy, AWS ELB, F5

Разница в том что reverse proxy умеет много всего, безопасность, кэширование, роутинг, а load balancer в основном занимается только распределением трафика между серверами. Коротко, все load balancer являются reverse proxy, но не все reverse proxy это load balancer

👉 Java Portal

Самые ходовые аннотации в Spring Boot

Если ты работал со Spring Boot, то наверняка встречал эти теги на каждом шагу. Вот топ-10:

I) @SpringBootApplication
II) @RestController
III) @RequestMapping / @GetMapping / @PostMapping
IV) @Autowired
V) @Component
VI) @Service
VII) @Repository
VIII) @Configuration
IX) @Bean
X) @Value

❓ Сколько из них ты реально использовал в продакшн-коде?

👉 Java Portal

«Что такое CAP-теорема и почему она важна в распределённых системах?»

CAP-теорема утверждает, что в распределённой базе данных одновременно можно гарантировать только два свойства из трёх - Consistency, Availability и Partition Tolerance. Так как сетевые разделения неизбежны, приходится выбирать между консистентностью и доступностью.

Consistency означает, что каждое чтение возвращает самую последнюю запись, независимо от того, на какой реплике выполняется запрос. Для сильной консистентности обычно требуется координация между узлами перед тем, как подтвердить ответ.

Availability означает, что каждый запрос получает ответ, даже если это не самые свежие данные. Система остаётся доступной и отвечает на запросы, несмотря на сбои отдельных узлов.

Partition Tolerance означает, что система продолжает работать даже при сетевых разрывах или потере сообщений. В реальности разделения всегда происходят, поэтому это свойство нельзя исключить.

Так как P всегда должно выполняться, в реальных системах приходится выбирать между CP и AP.

CP-системы отдают приоритет консистентности и устойчивости к разделению, жертвуя доступностью во время сбоев. Примеры — ZooKeeper, Google Spanner, CockroachDB.

AP-системы делают ставку на доступность и устойчивость к разделению, во время проблем могут отдавать устаревшие или несовпадающие данные, но со временем данные приходят к единому состоянию. Примеры — Cassandra, Riak, DynamoDB.

CP имеет смысл для финансовых и критически важных приложений, где важна корректность данных. AP лучше подходит для масштабных систем, где приоритет — чтобы сервис всегда отвечал, даже ценой временной рассогласованности. Многие современные базы позволяют настраивать уровень консистентности под конкретные задачи.

👉 Java Portal