Java Portal | Программирование

⭐️ Road to Highload: видеопроект о проектировании архитектуры высоконагруженных систем Инженеры Яндекс 360 накопили значительный опыт в проектировании и разработке систем, которыми ежедневно пользуются больше 95 миллионов человек ежемесячно. В этом видеопроекте разработчики на практических примерах рассказывают, как создают архитектуру систем, которые держат 1 000 000 RPS и хранят петабайты мета-данных. В выпусках обсуждаем:

🎙 Серия 1. Функциональные и нефункциональные требования. Как сбор требований помогает создавать надёжные и масштабируемые решения 🎙 Серия 2. Надёжный API. Принципы проектирования API, которые помогут сделать его консистентным, предсказуемым и поддерживаемым 🎙 Серия 3. Крупноблочная архитектура: карта вашей системы. Как выглядит модель на примере Яндекс Календаря и как ребята применяют её для эффективной коммуникации с различными командами разработки 🎙Серия 4. Практика: Рост баз данных: от единиц запросов к тысячам. Как правильно организовать работу с БД, чтобы система оставалась стабильной и эффективной 🎙 Серия 5. Практика. Взаимодействие со смежными системами. Типичные сложности, с которыми сталкиваются команды при интеграции с внешними сервисами, и как их предотвратить или минимизировать

Смотрите проект, чтобы узнать, как создаются одни из крупнейших облачных сервисов в России: ⭐️ Наш сайт ⭐️ VK Видео ⭐️ Ютуб

Сценарный вопрос с реального интервью по Java/Spring Boot: В контроллере вызывается метод сервиса, помеченный аннотацией @Transactional. Этот метод не только сохраняет сущность, но и отправляет два письма: одно администратору, другое — пользователю, который сделал запрос. Класс, отвечающий за отправку почты, помечен аннотацией @Async, но Spring всё равно выполняет его синхронно. В итоге API обрабатывает запрос целых 12 секунд — очевидно, это неприемлемо. Вопрос: почему так происходит и как это исправить? Реальная причина: Когда используется @Transactional, Spring создаёт прокси для транзакции. Если внутри этого же контекста вызывается @Async-метод, то Spring не создаёт новый поток — потому что вызов происходит внутри того же прокси. Иными словами, асинхронный код оказывается «заперт» внутри транзакции. В результате, коммит в базу ждёт, пока оба письма не будут отправлены. Как исправить: Заменить прямой вызов отправки писем на event-publisher подход. После сохранения запроса просто опубликовать событие, например DemoRequestCreatedEvent. Асинхронные слушатели (@EventListener + @Async) будут обрабатывать отправку писем вне основной транзакции. Что получаем: Транзакция завершается за ~100 мс вместо 12 секунд. API реагирует почти мгновенно. Письма всё так же надёжно уходят в фоне. Использование событий и асинхронных слушателей — не просто красивая архитектурная штука, а реальный способ сделать систему быстрой, масштабируемой и профессиональной. Дополнительный вопрос: Кроме событий, какие подходы ты используешь, чтобы отделить транзакционную логику (например, коммит в БД) от побочных эффектов вроде отправки писем или уведомлений? @Java_Iibrary

Топ-20 вопросов по микросервисам для Java-разработчиков На Java67 вышла подборка самых частых вопросов по микросервисной архитектуре — от отличий монолита до тем вроде Docker, Kubernetes, API Gateway, CQRS и Saga-паттернов. 👉 Java Portal

Что такое String Pool String Pool → это специальная область памяти внутри heap, где Java хранит строковые литералы. Главная идея → повторное использование строк и экономия памяти. Как это работает:

String s1 = "Java";
String s2 = "Java";
System.out.println(s1 == s2); // true

s1 и s2 указывают на один и тот же объект в String Pool → дубликаты не создаются. Но если сделать так:

String s3 = new String("Java");
System.out.println(s1 == s3); // false

new String() обходит пул и создаёт новый объект в heap. Зачем это нужно: → Экономит память за счёт переиспользования неизменяемых строк. → Повышает производительность при повторных строковых значениях. → Безопасно для потоков, потому что строки immutable. Как заставить строку из heap использовать пул? Ответ:

s3 = s3.intern();

Метод intern() → добавляет строку в пул и возвращает ссылку на объект из пула. 👉 Java Portal

Gitvizz превращает код в интерактивный граф Терялся в собственном коде? Встречай Gitvizz — инструмент, который мгновенно превращает кодовую базу в интерактивные графы, чтобы наглядно увидеть, как всё связано. Посмотреть можно на gitvizz.com 👉 Java Portal

Java повсюду 🥺 👉 Java Portal

Ты правильно используешь коллекции в Java? Не все коллекции одинаково полезны, и неправильный выбор может увеличить нагрузку на CPU или память в 10 раз, даже не замечая этого. Если работаешь с большими коллекциями, это важно: 1. ArrayList Идеально, когда: Читаешь много, а пишешь мало. Доступ к элементам по позиции (get(i)). Почему? Внутри — массив. Чтение очень быстрое, но вставка или удаление в середине медленные, потому что нужно сдвигать элементы. Используй для: каталогов, списков, которые почти не меняются, или результатов, которые создаются один раз и потом только читаются. 2. LinkedList Идеально, когда: Постоянно добавляешь или удаляешь элементы. Не нужен прямой доступ к элементу по индексу. Каждый элемент знает, кто перед ним и кто после, поэтому вставка/удаление быстрые, но поиск конкретного элемента медленный, так как нужно проходить список поэлементно. Используй для: очередей, буферов или структур, где важен порядок, а не скорость доступа. 3. HashMap Идеально, когда: Нужно хранить пары ключ/значение. Требуется быстрый доступ по ключу (как словарь). Использует функцию хеширования для быстрого поиска. Если hashCode() реализован плохо, может работать медленно и потреблять больше памяти. Используй для: хранения пользователей, продуктов, настроек или любых данных, к которым нужен быстрый доступ по ключу. Перед оптимизацией спроси себя: Много читаю и мало пишу? → ArrayList Часто вставляю/удаляю? → LinkedList Ищу по ключу? → HashMap Нет универсально «лучшей» структуры. Есть та, которая подходит под твой способ доступа к данным. 👉 Java Portal

Как правильно обрабатывать ошибки в Spring Boot REST Если ты делаешь REST-API на Spring Boot, важно не просто ловить исключения, а возвращать понятные ответы клиенту. Корректные HTTP-коды и осмысленные сообщения помогают быстрее понять, что пошло не так — будь то дубликаты записей, ошибки валидации или проблемы с аутентификацией. В статье объясняется, как организовать централизованную обработку ошибок, какие статусы стоит использовать (400, 401, 404, 409, 500 и т.д.), и почему логирование играет ключевую роль в поддержке и быстром устранении проблем в проде. Подробнее тут 👉 Java Portal

Вопросы по Java + Spring Boot на собеседованиях (сценарии из реальной практики) Ниже приведены несколько типичных сценариев с короткими ответами (TL;DR — можно сохранить для повторения перед интервью): 🔸Типы Spring-бинов и стереотипы Сценарий: Представь, что ты проектируешь сложную e-commerce платформу. Где ты используешь интерфейс с аннотацией @Repository, а где — с аннотацией @Service? Приведи конкретный пример, какую роль каждая из этих аннотаций играет в процессе оформления заказа пользователем. → @Component — универсальный бин, @Service — бизнес-логика, @Repository — DAO + перевод исключений в DataAccessException, @Controller — контроллер уровня MVC. 🔸Циклические зависимости Сценарий: Коллега добавил новую фичу, и теперь твое Spring-приложение не стартует, выдавая BeanCurrentlyInCreationException из-за циклической зависимости между ServiceA и ServiceB. Предположим, что быстро переработать бизнес-логику невозможно. Какое минимальное изменение кода ты бы предложил, чтобы приложение хотя бы запустилось, и почему это считается временным решением? → Spring по умолчанию может использовать проксирование и конструкторную/сеттерную инъекцию. Лучшее решение — перепроектировать зависимости или использовать @Lazy. 🔸Распространение транзакций Сценарий: У тебя есть OrderService с методом createOrder(), помеченным @Transactional. Внутри он вызывает updateInventory() (тоже в OrderService и тоже с @Transactional). Если updateInventory() выбрасывает runtime-исключение, что произойдет с транзакцией, начатой в createOrder()? Как изменить дизайн, если нужно, чтобы оба метода выполнялись в отдельных, независимых транзакциях? → Транзакция не будет распространяться (прокси не сработает при внутреннем вызове). Решение — self-injection (внедрение самого себя как зависимости) или использование AOP. 🔸Скоупы бинов Сценарий: Нужно хранить товары пользователя в корзине и управлять временным списком поисковых фильтров, который очищается после каждого HTTP-запроса. Какой скоуп ты выберешь для ShoppingCart и какой — для SearchFilter, и почему? → @SessionScope — для корзины (привязано к пользовательской сессии), @RequestScope — для поискового фильтра (новый бин на каждый HTTP-запрос). 🔸Controller Advice Сценарий: В приложении есть и традиционные веб-эндпоинты с Thymeleaf, и REST API. Нужно централизовать обработку ошибок (например, перехват ResourceNotFoundException): Как вернуть страницу 404 для обычных web-эндпоинтов? Как вернуть JSON с ошибкой 404 для REST API? → @ControllerAdvice — используется с @Controller, возвращает view. @RestControllerAdvice — сочетает @ControllerAdvice + @ResponseBody (для REST API). 🔸Автоконфигурация Сценарий: Ты добавил в проект стороннюю библиотеку (например, кастомный логгер) и просто положил её JAR в classpath. Без написания конфигурационных классов Spring автоматически подхватывает нужные бины. Объясни, как Spring Boot определяет и подключает их при старте. → Использует SpringFactoriesLoader, который читает META-INF/spring.factories и конфигурирует бины в зависимости от содержимого classpath. 🔸Ограничение частоты запросов Сценарий: Твой публичный API перегружен — один клиент шлет слишком много запросов, мешая остальным. Какой практичный, независимый от технологий подход можно применить для ограничения, например, 100 запросов в минуту на клиента, и где обычно реализуется такая логика? → Bucket4j / Resilience4j, счетчики в Redis, лимитирование на уровне API Gateway. 🔸Распределённые транзакции Сценарий: В микросервисной архитектуре оформление заказа включает два шага — списание товара в Inventory Service и списание денег через Payment Service. Если списание товара прошло успешно, а оплата — нет, какой шаблон проектирования поможет откатить изменения в Inventory и обеспечить согласованность данных? → Шаблон Saga (хореография или оркестрация), либо двухфазный коммит (2PC, но редко используется на практике). 👉 Java Portal

Терминальный интерфейс для Docker на Rust Приложение позволяет просматривать и управлять контейнерами, образами, томами и сетями прямо из терминала, вдохновлено K9s и делает работу с Docker быстрее и удобнее. Репозиторий на GitHub 👉 Java Portal

Гибкие тела конструкторов в Java 25 → Одна из самых заметных фич, введённых в Java 25. → Основная идея: ослабить строгие правила, согласно которым super(...) или this(...) обязательны как первая инструкция в конструкторе. → А что, если нужно что-то сделать с аргументами перед передачей их суперклассу? Допустим, мы хотим проверить число перед вызовом super(). Раньше это было невозможно, так как Java строго требовала, чтобы первой строкой любого конструктора был вызов другого конструктора в том же классе (this(...)) или конструктора суперкласса (super(...)). В приведённом примере: → До Java 25, если конструктору PositiveNumber нужно было передать val в его суперкласс BaseNumber (который требует val в конструкторе), super(val) должен был быть первой строкой. Любой код перед super() приводил к ошибке: "super() должен быть первой инструкцией". → Отложенная проверка: В примере мы не могли проверить val до его использования для инициализации BaseNumber, что нарушало принцип "fail-fast". Если val = -1, BaseNumber всё равно инициализировался с -1, прежде чем PositiveNumber мог бы выбросить ошибку. → Неуклюжие обходные пути: Чтобы проверить аргумент заранее, приходилось использовать менее читаемые схемы (например, super(staticMethodForValidation(val))) или сложную делегацию конструкторов. ⇒ С Java 25 → Теперь Java 25 понимает, что подготовительная работа, такая как проверка аргументов, логически относится к обязанностям конструктора и может (и должна) выполняться до инициализации состояния суперкласса. → Настоящая проверка "fail-fast": Если val = -1, IllegalArgumentException выбрасывается до вызова super(val), конструктор BaseNumber не выполняется с некорректным значением, и создание объекта прерывается на раннем этапе. → Более безопасное создание объектов: Суперкласс инициализируется только с корректными, предварительно обработанными аргументами, что делает объекты более надёжными и безопасными. 👉 Java Portal

В статье разбираем, почему graceful shutdown важен и как настроить плавное завершение работы Spring Boot приложения, которое работает с Kafka. Ты узнаешь, как корректно завершать обработку сообщений, чтобы не потерять данные и избежать ошибок при остановке сервиса. Практичные советы и примеры кода помогут сделать твое приложение более стабильным и надежным. 👉 Java Portal

Полный Roadmap для Spring Boot разработчика Много разработчиков ищут структурированный путь от новичка до продвинутого уровня в Spring Boot. Ниже представлен 3-фазный roadmap, который поможет освоить все ключевые концепции и инструменты. PHASE 1 - Создание Spring Boot проекта через Spring Initializer - Maven и Gradle - Основные аннотации - Профили и конфигурации для разных окружений - @GetMapping, @PostMapping, @PutMapping, @DeleteMapping - Path variables и request parameters - Настройка баз данных (H2, MySQL, PostgreSQL) - Использование JpaRepository и CrudRepository - Spring Boot DevTools и hot reloading - Spring Batch, Scheduling и Cron выражения PHASE 2 - @ControllerAdvice и @ExceptionHandler - Кастомные ошибки и глобальная обработка исключений - Базовая аутентификация и настройка безопасности API - JWT для stateless аутентификации - HATEOAS и версионирование REST API (URI, параметры, headers) - Unit-тесты с JUnit и Mockito - Интеграционные тесты с Spring Boot Test и MockMvc - Actuator endpoints и кастомные health indicators PHASE 3 - @Profile и настройка бинов для разных окружений - Spring Cloud: Eureka Server, Service Discovery, API Gateway - Spring Cloud Config Server для централизованного управления конфигурациями - Настройка Spring Boot приложений для работы с Config Server Чтобы полностью усвоить материал, постройте свои проекты на каждом этапе. Практика поможет закрепить знания и сделает их долговечными. 👉 Java Portal

Распространённые Алгоритмы Балансировки Нагрузки Статические алгоритмы

1. Круговой Алгоритм Клиентские запросы отправляются в различные экземпляры сервисов в последовательном порядке. Сервисы обычно должны быть без сохранения состояния. Недостаток: - Эта простейшая версия алгоритма будет эффективно работать только в сферической среде в вакууме, где все серверы обладают почти одинаковой конфигурацией, а все входящие запросы (задачи, процессы) имеют одинаковые приоритет и продолжительность. 2. Закреплённый Круговой Алгоритм Усовершенствование кругового алгоритма. Если первый запрос Алисы отправляется в сервис A, следующие запросы также отправляются в сервис A. 3. Взвешенный Круговой Алгоритм Администратор может указать вес для каждого сервиса. Сервисы с более высоким весом обрабатывают больше запросов, чем другие. 4. Хэш IP/URL Применяет хеш-функцию к IP или URL входящих запросов. Запросы направляются в соответствующие экземпляры на основе результата хеш-функции. Преимущества: - Постоянство сессии – алгоритм гарантирует, что запросы от одного клиента всегда попадают на один и тот же сервер. - Облегчает кеширование данных на стороне сервера для конкретных клиентов. Недостатки: - Если много пользователей приходят из одного диапазона IP, один сервер может быть перегружен. - Неэффективен в средах, где IP клиентов часто меняются (мобильные сети). - Может привести к неравномерной нагрузке, если некоторые клиенты генерируют больше трафика.

Динамические алгоритмы

5. Наименьшее Количество Соединений Новый запрос отправляется в экземпляр сервиса с наименьшим количеством одновременных подключений. Преимущества: - Более мощные серверы естественным образом будут обрабатывать больше запросов и, следовательно, иметь больше соединений. И напротив, менее мощные серверы будут получать меньше запросов, что предотвращает их перегрузку. - Гибкость – если один сервер начинает работать медленнее, он будет получать меньше новых запросов. Недостатки: - Алгоритм считает все соединения одинаковыми, не учитывая, что некоторые запросы могут быть более ресурсоёмкими. - Вновь добавленный сервер может получить слишком много запросов, т.к. изначально у него 0 соединений. 6. Наименьшее Время Ответа Новый запрос отправляется в экземпляр сервиса с самым быстрым временем ответа. Аналогичный алгоритм - Наименьший объем трафика Преимущества: - Учёт текущей производительности серверов и динамическая адаптация обеспечивают оптимальный баланс и наилучший пользовательский опыт. - Хорошо работает с серверами разной мощности и приложениями с разными характеристиками. Недостаток: - Сложность реализации – требует постоянного мониторинга и анализа производительности серверов, отсюда повышенная нагрузка на балансировщик.

👉 Java Portal

Одна из самых частых тем на собеседованиях Java/backend-разработчиков ⇒ Проблема N+1 в JPA → 1 первичный запрос: получение N родительских сущностей. → Затем N дополнительных запросов: для каждой из этих N сущностей выполняется отдельный запрос, чтобы загрузить связанные дочерние данные. → В итоге выполняется 1 + N запросов к БД, что приводит к снижению производительности и замедлению отклика. Пример: Получаем 100 авторов (1 запрос), а затем в цикле вызываем author.getBooks() для каждого (N=100) — в итоге 101 запрос. ⇒ Как решить проблему N+1 в JPA ⇆ Цель — загрузить связанные данные за меньшее количество запросов, желательно за один проход к базе. 1. JPQL/HQL JOIN FETCH (рекомендуется для конкретных связей) Позволяет явно указать JPA, что ассоциации нужно подгружать через JOIN в запросе. Пример:

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

Плюсы: один эффективный запрос. Важно: при джойне нескольких коллекций можно получить декартово произведение. 2. Batch Fetching (@BatchSize или hibernate.default_batch_fetch_size) Вместо одного запроса на каждого родителя, связанные коллекции загружаются пакетами — по нескольким ID за один запрос. Пример:

@BatchSize(size = 10)
@OneToMany(...)
private List<Book> books;

Плюсы: уменьшает количество запросов с 1 + N до 1 + (N / batch_size), избегая проблемы декартовых произведений. 3. Entity Graphs (@EntityGraph — Spring Data JPA / JPA 2.1+) Позволяет декларативно определить, какие связи нужно подгружать eagerly для конкретного метода репозитория. Пример:

@EntityGraph(attributePaths = "books")
List<Author> findAll();

Плюсы: гибкая и переиспользуемая стратегия загрузки без явных JPQL JOIN’ов. Всегда используйте явные стратегии загрузки (такие как JOIN FETCH, @BatchSize или @EntityGraph), чтобы избежать проблемы N+1 и обеспечить эффективное взаимодействие с базой данных. 👉 Java Portal

JEP 511 в Java добавляет возможность краткого импорта всех пакетов, экспортируемых модулем. Это облегчает повторное использование модульных библиотек без необходимости помещать импортирующий код в модуль. Подробнее: https://openjdk.org/jeps/511 👉 Java Portal

Программисты из Telegram создали сильнейшие IT- каналы 🐍 Ghostly Python - автоматизируй всё, что можешь. Боты, скрипты, парсеры, утилиты - делаем Python простым и полезным. Уверенный старт для новичков и не только. ☕️ Easy Java - Java без боли. От основ до фреймворков. Просто, понятно и по делу. Если хочешь реально понять язык - тебе сюда. 😎 IT Syndicate - главный хаб для тех, кто живёт IT. GameDev, InfoSec, Frontend, DevOps, AI и многое другое. Готовь мозг, тут будет жарко. 🧡 Ghostly Frontend - фронтенд без лишнего шума. HTML, CSS, JavaScript, React, Vue — всё, что нужно, чтобы создавать быстрые и красивые интерфейсы.

Генерация тестовых данных Чтобы написать хороший тест, нужны хорошие тестовые данные, приближенные к production. Плохо подготовленные данные = плохо написанный тест. Поэтому практически все тесты должны состоять из трех основных частей: - given (подготовка данных и стабов для mock/spy) - when (вызов тестируемого API) - then (проверка результата) Сложно написать хороший тест, полагаясь на данные, которые уже существуют в базе в момент запуска теста (за исключением справочных данных или тех, что были накатаны на production с помощью миграционных фреймворков вроде liquibase и flyway). Обычно на эти данные полагаются другие тесты, а потому часто меняются, что ломает наши тесты или делает их даже flaky. Поэтому каждый тест должен в идеале готовить данные только для себя, на которых он планирует проверить API:

@Test
void findAll() {
    // given
    // Все компактно, содержит только необходимую информацию для программиста
    User user1 = userDao.save(getUser("test1@gmail.com"));
    User user2 = userDao.save(getUser("test2@gmail.com"));
    User user3 = userDao.save(getUser("test3@gmail.com"));

    // when
    List<User> actualResult = userDao.findAll();

    // then
    // Легко получить доступ к id объектов, т.к. накатывание данных было в самом тесте
    assertThat(actualResult).hasSize(3);
    List<Integer> userIds = actualResult.stream()
            .map(User::getId)
            .toList();
    assertThat(userIds).contains(user1.getId(), user2.getId(), user3.getId());
}

А чтобы не испортить состояние базы во время проверки, то: - открываем транзакцию ПЕРЕД выполнением теста (@BeforeEach) - накатываем данные, вызываем API и проверяем результат (@Test) - откатываем транзакцию в конце (@AfterEach) 👉 Java Portal

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

В Spring Boot ProductController нужно обработать два разных случая: 1. Вернуть простой 404 Not Found, если продукт не найден. 2. Вернуть 201 Created с динамическим заголовком Location при успешном создании. Какие механизмы Spring вы бы использовали для реализации каждого из этих требований и почему? Два основных способа управлять HTTP-ответом, отправляемым клиенту: → @ResponseStatus: простой статический вариант - Можно навесить на исключение или метод контроллера. - Всегда возвращает один и тот же HTTP-статус. - Подход "fire-and-forget": быстро и лаконично в случаях, когда ответ всегда одинаковый. - Лучше всего подходит для простой обработки ошибок. Например, ResourceNotFoundException, аннотированный @ResponseStatus(HttpStatus.NOT_FOUND), всегда будет возвращать 404. - Нельзя добавить кастомные заголовки или динамическое тело ответа. → ResponseEntity: кастомный инструмент - Даёт полный программный контроль над формированием HTTP-ответа во время выполнения. - Можно выставить статус, добавить заголовки и собрать тело ответа так, как требуется по логике. - Лучше всего подходит для сложных ответов. Например, когда нужно добавить заголовок Location после создания ресурса (201 Created) или вернуть детализированный JSON-объект с информацией об ошибке. - Это основной инструмент, когда ответ должен зависеть от ситуации. Комбинация подходов: Используя @RestControllerAdvice для глобальной обработки исключений, можно применять @ResponseStatus для типовых ошибок, а ResponseEntity — для более специфичных и динамичных ответов. Такой подход даёт одновременно и эффективность, и гибкость. 👉 Java Portal