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

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

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

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

👉 Java Portal

Spring Boot с одной БД работает гладко. Но как только подключаешь вторую, то всё ломается. Почему и как это правильно настроить?

С одной базой Spring Boot сам автоконфигурит нужные компоненты: DataSource, JdbcTemplate, EntityManagerFactory и т.д.

Когда баз становится две, фреймворк не понимает, какую взять за основную. Автоконфигурация перестаёт работать, и нужно явно объявить бины для каждой, одну пометить как @Primary. А дальше подключать их через @Qualifier там, где требуется. ✏️

У кого так было? 👍

👉 Java Portal

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

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

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

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

👉 Java Portal

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

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

👉 Java Portal

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

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

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

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

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

👉 Java Portal

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

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

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

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

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

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

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

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

👉 Java Portal

Что такое ETL

ETL расшифровывается как Extract, Transform, Load и означает процесс интеграции данных. Сначала данные извлекаются из разных источников, например из баз данных, файлов или API. Затем они преобразуются в удобный для аналитики или отчетности формат.

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

После этого данные загружаются в целевую систему. Чаще всего это хранилище или витрина данных, где они используются для отчетности, BI и аналитики.

ETL применяют в разных задачах. Он лежит в основе построения хранилищ, помогает при миграции данных между системами, используется для интеграции данных из разных источников, обеспечивает корректность данных для BI и отчетов, а также загружает структурированные и неструктурированные данные в data lake.

Среди распространенных ETL-инструментов можно назвать Microsoft SSIS, Azure Data Factory, Talend, Oracle Data Integrator, Apache NiFi и AWS Glue.

Сегодня также популярен подход ELT, при котором данные сначала извлекаются и загружаются в хранилище или big data-платформу, а все трансформации выполняются уже внутри целевой системы.

👉 Java Portal

Вот классический вопрос для собеседования по Java, на котором спотыкается много разработчиков.

Нам всем говорили, что блок finally выполняется всегда, при любых обстоятельствах. Но так ли это на самом деле?

Можешь назвать ситуацию, когда он не сработает?

Ответ — нет, но с важной оговоркой.

Фатальный краш JVM (например, StackOverflowError) это стопроцентный «нет» для finally.

А вот с System.exit() всё интереснее. Если вызов проходит успешно, JVM завершается сразу, и finally пропускается. Если же SecurityManager блокирует вызов, выбрасывается SecurityException, и блок finally выполняется в рамках обычной обработки ошибки.

То есть поведение реально зависит от прав, заданных в рантайме.

👉 Java Portal

10 принципов проектирования микросервисов, которые стоит изучить Java-разработчикам

- CQRS
- SAGA
- База данных на каждый сервис
- Circuit-breaker
- API Gateway
- Event Sourcing
- Strangler
- Внешняя конфигурация

👉 Java Portal

Вот суть работы HashMap:

Сначала вызывается hashCode(), чтобы определить, в какой бакет попадёт ключ.

Внутри бакета вызывается equals(), чтобы проверить, есть ли уже такой ключ.

Если переопределить только equals(), но оставить дефолтный hashCode() (по адресу в памяти), получится проблема. Два объекта, которые равны по equals(), могут иметь разные хэши. Тогда они попадут в разные бакеты, и HashMap воспримет их как разные ключи.

Итог: поиск по ключу может “ломаться”, значения будут “теряться”, а одинаковые по смыслу ключи могут храниться дублирующимися.

Поэтому существует контракт: если объекты равны по equals(), они обязаны возвращать одинаковый hashCode(). В противном случае любые коллекции на основе хэшей (HashMap, HashSet, Hashtable) будут вести себя неправильно.

👉 Вывод прост. Всегда переопределяй equals() и hashCode() вместе.

👉 Java Portal

Дорожная карта по Spring Framework

🔸Prerequisites

• Java Fundamentals. ООП, коллекции, обработка исключений
• Maven и Gradle. Сборка и управление зависимостями
• XML и Annotations. Форматы конфигурации
• Basic SQL.
• JDBC. Драйверы и соединения
• HTTP и Web Basics. REST, JSON, базовые протоколы

🔸Spring Core

• Inversion of Control. Базовый принцип Spring
• Dependency Injection. Конструктор, сеттер, field injection
• Application Context. Контейнер и управление бинами
• Bean Lifecycle. Инициализация и уничтожение
• Bean Scopes. Singleton, prototype, request, session
• Configuration. XML, Java-config, аннотации

🔸Core Annotations

• @Component. Базовый компонент
• @Service. Слой бизнес-логики
• @Repository. Доступ к данным
• @Controller. Обработка запросов
• @Autowired. Внедрение зависимостей
• @Configuration. Классы конфигурации
• @Bean. Определение бина

🔸Spring Boot Basics

• Auto-Configuration. Автонастройка на зависимостях
• Spring Boot Starters. Преднастроенные наборы
• Application Properties. properties и YAML
• @SpringBootApplication. Точка входа
• Embedded Servers. Tomcat, Jetty, Undertow
• Spring Boot CLI. Инструмент командной строки

🔸Spring Web MVC

• DispatcherServlet. Фронт-контроллер
• @RequestMapping. Маршруты
• @GetMapping и @PostMapping. HTTP-хендлеры
• @RequestParam. Параметры запроса
• @PathVariable. Параметры пути
• Model and View. Шаблоны MVC

🔸REST APIs

• @RestController. Контроллер REST
• @ResponseBody. Тело ответа
• HTTP Status Codes.
• Content Negotiation. Форматы JSON и XML
• Exception Handling. @ControllerAdvice и обработчики
• CORS. Политика совместного использования

🔸Spring Data JPA

• JPA Entities. @Entity, @Table, @Id, аннотации
• Repository Pattern. Интерфейсы доступа к данным
• JpaRepository. CRUD-операции
• Query Methods. Методы-запросы по имени
• @Query Annotation. JPQL и нативные запросы
• Relationships. @OneToMany, @ManyToOne, @ManyToMany
• Pagination и Sorting. Параметры страниц и сортировки

🔸Spring Security

• Authentication. Проверка пользователя
• Authorization. Контроль доступа по ролям
• Security Configuration. Фильтры и цепочка безопасности
• Password Encoding. Энкодеры паролей
• JWT Tokens. Статлес-аутентификация
• OAuth2. Внешние провайдеры
• Method Security. @PreAuthorize, @Secured

🔸Aspect-Oriented Programming

• Cross-cutting Concerns. Логирование, безопасность, транзакции
• @Aspect. Определение аспектов
• Pointcuts. Точки среза
• Advice Types. @Before, @After, @Around
• JoinPoints. Места, куда вплетается аспект

🔸Testing

• @SpringBootTest. Интеграционные тесты
• @WebMvcTest. Тестирование веб-слоя
• @DataJpaTest. Тестирование JPA
• MockMvc. Тесты контроллеров без сервера
• @MockBean. Заглушки в контексте Spring
• TestRestTemplate. Тестирование REST

🔸Spring Actuator

• Health Endpoints. Мониторинг состояния
• Metrics. Метрики приложения
• Custom Endpoints. Пользовательские эндпоинты
• Info Endpoint. Информация о сборке
• Environment Properties. Просмотр конфигурации

🔸Microservices

• Spring Cloud. Набор для микросервисов
• Service Discovery. Eureka и Consul
• API Gateway. Spring Cloud Gateway
• Circuit Breaker. Resilience4j и Hystrix
• Configuration Server. Централизованная конфигурация
• Distributed Tracing. Sleuth и Zipkin

🔸Advanced Topics

• Reactive Programming. Project Reactor
• Spring Native. Компиляция в native-image
• Custom Auto-Configuration. Свои автоконфигурации
• Event-Driven Architecture. Событийная модель
• Caching. Абстракция кэширования
• Profiles. Профили конфигураций

🔸Deployment

• Docker Containerization. Образы и контейнеры
• Kubernetes Deployment. Манифесты и Helm
• Cloud Platforms. AWS, GCP, Azure
• CI/CD Pipelines. Стратегии релизов
• Production Monitoring. APM и наблюдаемость

🔸Best Practices

• Project Structure. Слои и модульность
• Configuration Management. Внешние конфиги
• Error Handling. Глобальные обработчики
• Logging. SLF4J и структурированные логи
• Performance Optimization. Кэш, пул соединений, lazy-loading
• Security Hardening. Настройки для продакшена

👉 Java Portal

У тебя несколько потоков-продюсеров, которые кладут элементы в очередь, и несколько потоков-консьюмеров, которые их оттуда забирают.
Если очередь полная, продюсеры ждут.
Если очередь пустая, консьюмеры ждут.

Как реализовать такую потокобезопасную ограниченную очередь?

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

Ответ

Мы держим фиксированного размера буфер (Deque).

Продюсеры при вызове put ждут, если буфер заполнен.

Консьюмеры при вызове take ждут, если буфер пуст.

Когда продюсер кладёт элемент, он сигналит ожидающему консьюмеру.

Когда консьюмер забирает элемент, он сигналит ожидающему продюсеру.

Ожидание всегда делается внутри while, чтобы поток после пробуждения перепроверил условие.

Флаг close запрещает новые вставки и будит всех, чтобы они завершились корректно.

Предпочтительный способ это использовать ReentrantLock. Это как synchronized, только с большим контролем. Один и тот же поток может захватить его несколько раз без дедлока. Он позволяет создавать Condition-объекты — это очереди ожидания, привязанные к замку. Здесь удобно завести две: notFull и notEmpty, чтобы продюсеры и консьюмеры ждали и сигналили точно по ситуации.

👉 Java Portal

Что такое Domain-Driven Design

Domain-Driven Design, или DDD, это подход к разработке ПО, который помогает переводить сложные предметные области в выразительное, живое и эволюционирующее программное обеспечение. Он нужен, когда требования пользователей сложные.

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

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

Сущности это доменные объекты, для которых важна идентичность. Примеры: User, Job, Vinyl, Post, Comment. Сравнение сущностей идет по уникальному идентификатору, обычно это UUID или первичный ключ.

Объекты-значения не имеют идентичности. Это атрибуты сущностей. Например, Name как объект-значение у User.

Агрегат это набор сущностей, объединенный корнем агрегата. Корень агрегата это то, к чему обращаются при поиске и через что проходят все операции. Внешний код не должен ссылаться на объекты внутри границ агрегата. Так сохраняется согласованность.

Модель предметной области в DDD опирается на смыслы терминов domain и model. Домен это детали задачи, которую вы решаете. Это знание о бизнесе, операциях, терминологии, правилах, целях и ограничениях. Понимание этого определяет саму проблему и рамки решения.

Доменные сервисы это место для доменной логики, которая не принадлежит ни одному конкретному объекту.

Ограниченный контекст это ключевой паттерн DDD, который помогает держать сложность под контролем. Он масштабирует большие модели и команды. Код реализуется внутри конкретного контекста после того, как определены домен и поддомены. Ограниченные контексты задают границы, внутри которых определен и применим конкретный поддомен.

Репозиторий используется для получения доменных объектов из слоя хранения. С опорой на принцип подстановки Лисков и многослойную архитектуру можно спроектировать доступ так, чтобы, например, переключаться на in-memory репозиторий для тестов.

Фабрика нужна, потому что доменные объекты создаются разными способами. Объекты домена можно собирать фабрикой из сырых строк SQL, сырого JSON или из Active Record, который вернул ваш ORM инструмент вроде Sequelize или TypeORM.

👉 Java Portal

Задумывались, почему оператор == в Java работает для одних значений Integer, а для других — нет?

Дело в механизме, который называется Integer Caching.

JVM кэширует объекты Integer в диапазоне от -128 до 127. Когда вы присваиваете значение в этом диапазоне, Java переиспользует один и тот же объект из кэша. Поэтому две переменные с одинаковым числом в этом диапазоне указывают на одну и ту же ссылку, и == возвращает true

Но за пределами диапазона, например для 128 или 1000, каждый раз создается новый объект. Ссылки разные, поэтому == вернет false, даже если значения совпадают.

Главное, что стоит запомнить: == сравнивает ссылки на объекты, а не сами значения. Чтобы сравнить числа, всегда используйте .equals()

Этот трюк с кэшированием также работает для Byte, Short, Character (до 127) и Long (от -128 до 127)

👉 Java Portal

В этой статье рассказывается, как внутри работает новый профайлер по CPU-времени в Java, включая обработку сигналов, устройство очередей и асинхронное сэмплирование. Подробный разбор основных компонентов, скрытых за кулисами.

Подробнее читайте здесь

После узнайте о том, как в новом CPU-тайм профайлере Java 25 устроена очередь для запросов на сэмплинг: зачем она нужна, почему её размер критичен для баланса между потерей сэмплов и расходом памяти, и по каким правилам JVM выбирает этот размер в зависимости от интервала сэмплинга.

Подробнее: читать

👉 Java Portal

Вот задача для собеседования по Java

У вас есть два потока.
Поток 1 печатает нечётные числа.
Поток 2 печатает чётные числа.

Как их синхронизировать так, чтобы вывод всегда шёл по порядку:
1 2 3 4 5…

Звучит просто, но заставляет внимательно подумать о координации потоков.

Ответ

Самый аккуратный способ это использовать семафоры.

Семафор управляет набором разрешений (токенов). Поток, вызывающий acquire, забирает разрешение, и если его нет — ждёт. Поток, вызывающий release, возвращает разрешение, чем будит ожидающий поток.

Мы создаём два семафора: один для нечётных, другой для чётных.
Семафор для нечётных изначально имеет 1 разрешение, чтобы первый поток мог стартовать, а для чётных — 0, чтобы он ждал. После того как нечётный поток печатает число, он делает release для чётного. Чётный поток делает acquire, печатает, и отдаёт разрешение обратно нечётному.

Такое чередование гарантирует точную последовательность 1 2 3 4 … без активного ожидания, без sleep и без гонок.

👉 Java Portal

Вышла неплохая статья про Big O

Big O помогает разобраться, как ведут себя алгоритмы, и показывает, где можно выжать кратный прирост производительности даже с мелкими правками в коде.

В статье есть наглядные визуализации, интерактив и простые объяснения.

👉 Java Portal

Большинство Java-разработчиков форматируют числа вручную. Но в Java есть форматтеры с поддержкой локали, которые подстраиваются автоматически.

Одно и то же значение будет выглядеть по-разному в зависимости от региона.

В США это будет 12,000.75.
Во Франции — 12 000,75.
В Индии используется группировка по лакхам и крор.
В России — 12 000,75.
А в компактном формате то же самое число станет 12K на английском или 12 हज़ार на хинди.

И всё это доступно из коробки. Вместо того чтобы изобретать велосипед, можно просто использовать стандартные API Java.

👉 Java Portal

Как вам эта джавовская мудрость:

- Используй enum, а не строковые константы - - компилятор сам поймает ошибки.
- Не создавай потоки вручную - - используй executors.
- Всегда закрывай JDBC-ресурсы - - иначе база останется без коннекшенов.
- Не глотай checked-исключения - - хотя бы логируй их.
- Не игнорируй InterruptedException - - это ломает координацию потоков.
- Не используй SimpleDateFormat в многопоточном коде - - он не потокобезопасен.
- Кэшируй prepared statements - - парсить SQL каждый раз слишком дорого.
- Дженерики защищают тебя на этапе компиляции - - не убивай их, приводя к Object

👉 Java Portal