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

ForkJoinPool, ExecutorService и Virtual Threads: что выбирать в Java? Всё зависит от нагрузки: задачи в основном вычисляют или ждут ответа базы и внешних сервисов? При этом сравниваются разные уровни: ExecutorService — интерфейс управления задачами, ForkJoinPool — одна из его реализаций, а виртуальные потоки — тип потоков. Их можно использовать вместе. 🔹 ForkJoinPool — для параллельных вычислений Хорошо подходит для задач, которые можно разбить на независимые части: рекурсивных алгоритмов, обработки массивов и других CPU-intensive вычислений. Использует work-stealing: свободный рабочий поток забирает задачи из очередей других потоков. Но не любая тяжёлая операция требует ForkJoinPool. Для независимых вычислительных задач может быть достаточно обычного фиксированного пула. 🔹 ExecutorService — для запуска и управления задачами Позволяет отправлять задачи на выполнение, получать результаты через Future и управлять завершением исполнителя. Конкретная реализация определяет, как выполняются задачи.

ExecutorService executor =
    Executors.newFixedThreadPool(10);

Здесь одновременно работают не более 10 потоков. Однако очередь задач у такого исполнителя не ограничена: при постоянной перегрузке она может расти. Для выполнения по расписанию используется ScheduledExecutorService. 🔹 Virtual Threads — для большого количества ожидающих задач Виртуальные потоки стали стандартной возможностью в Java 21. Они особенно полезны, когда задачи много времени проводят в блокирующих вызовах к БД или HTTP-сервисам. Их тоже можно использовать через ExecutorService:

try (var executor =
         Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> callExternalApi());
}

Каждая задача получает отдельный виртуальный поток. Создавать пул для переиспользования виртуальных потоков не нужно. Что важно в продакшене • Виртуальные потоки не добавляют процессорных ядер и сами по себе не ускоряют вычисления. • Тысячи виртуальных потоков не означают, что база выдержит тысячи одновременных запросов. Нужны отдельные ограничения, например пул соединений или Semaphore. • Ограничение числа рабочих потоков не равно ограничению очереди задач. ForkJoinPool помогает распараллеливать вычисления. ExecutorService управляет выполнением задач. Virtual Threads позволяют эффективно организовать множество задач, ожидающих I/O. 👉 Java Portal

Connection Pool, Thread Pool и Object Pool: в чём разница? Общая идея одна: повторно использовать дорогие ресурсы вместо постоянного создания новых. Но каждый пул управляет своим типом ресурсов. • Connection Pool — пул соединений. Хранит соединения, например с базой данных. Приложение берёт свободное соединение, выполняет запросы и возвращает его в пул. • Thread Pool — пул потоков. Повторно использует рабочие потоки для выполнения задач. Не нужно создавать отдельный поток под каждую новую задачу. • Object Pool — пул объектов. Позволяет брать готовые объекты, использовать их, сбрасывать состояние и возвращать для следующего вызова. Пример: Spring Boot с обычной блокирующей обработкой запросов. Рабочий поток обрабатывает HTTP-запрос и выполняет бизнес-логику. Когда требуется доступ к БД, приложение получает соединение из пула. После завершения работы с БД соединение возвращается в пул. После обработки запроса рабочий поток освобождается для следующей задачи. Это два отдельных ресурса с разным временем использования. А стоит ли переиспользовать обычные Java-объекты? Не всегда. JVM эффективно выделяет память под короткоживущие объекты и собирает их сборщиком мусора. Пул имеет смысл прежде всего для объектов с дорогим созданием или ресурсов с ограниченным количеством. Больше ресурсов не означает быстрее: • Слишком много соединений может перегрузить базу. • Слишком много платформенных потоков увеличивает расход памяти и затраты на переключение контекста. • Неудачный пул объектов удерживает память и создаёт конкуренцию за доступ. Поэтому важен не только сам пул, но и его размер. Переиспользование полезно, когда оно действительно дешевле повторного создания. 👉 Java Portal

Многопоточность в Java: volatile, Atomic и synchronized Все три механизма применяются при работе с общими данными из нескольких потоков, но дают разные гарантии. Неправильный выбор может привести к багам, которые сложно воспроизвести. Коротко: • volatile — видимость изменений и гарантии порядка. • Atomic — атомарные операции над отдельной переменной. • synchronized — взаимное исключение и видимость изменений. volatile: когда важна видимость Подходит, например, для флага остановки:

private volatile boolean running = true;

// Один поток:
running = false;

// Другой поток:
while (running) {
    // Работа
}

Изменение флага будет видно при последующих чтениях из другого потока. Но volatile не делает составные операции атомарными:

volatile int count;
count++;

Инкремент состоит из чтения, увеличения и записи. Между этими шагами другой поток может изменить значение — и одно из обновлений потеряется. Atomic: когда нужна атомарная операция В Java есть AtomicInteger, AtomicLong, AtomicBoolean, AtomicReference и другие классы:

private final AtomicInteger counter =
        new AtomicInteger();

counter.incrementAndGet();

Здесь увеличение счётчика выполняется атомарно, без явного блока synchronized. Типичные задачи: счётчики, последовательные номера, условное обновление флагов и ссылок. При этом несколько отдельных вызовов Atomic не становятся одной атомарной операцией автоматически. synchronized: когда нужно защитить несколько действий

public synchronized void updateState() {
    checkState();
    changeState();
    updateCounter();
}

Только один поток может выполнять код, защищённый одним и тем же монитором, в конкретный момент. Для согласованности все обращения к защищаемому состоянию должны соблюдать ту же схему синхронизации. synchronized обеспечивает взаимное исключение и видимость изменений. При этом он не откатывает уже выполненные действия при исключении и не заменяет транзакцию базы данных. Конкуренция за блокировку может приводить к ожиданию, а неправильный порядок захвата нескольких блокировок — к deadlock. Вопрос с собеседования: достаточно ли volatile для count++? Нет. При конкурентном увеличении счётчика нужны AtomicInteger.incrementAndGet() или защита всей операции одной блокировкой. Atomic всегда быстрее synchronized? Тоже нет. При высокой конкуренции операции на основе CAS могут многократно повторять попытки обновления. Выбор зависит от нагрузки, размера критической секции и количества связанных переменных. Выбирайте по нужной гарантии: → volatile — другие потоки должны видеть изменение. → Atomic — нужна атомарная операция над переменной. → synchronized — нужно согласованно выполнить несколько действий с общим состоянием 👉 Java Portal

💡 Spring Boot 4: DevTools больше не запускает сервер LiveReload по умолчанию ✅ Автоматический перезапуск приложения при изменениях в classpath работает как раньше. ✅ Для включения LiveReload задайте spring.devtools.livereload.enabled=true. ✅ Порт 35729 больше не занимается автоматически — удобно, когда на одной машине запущено несколько приложений. 👉 Java Portal

Виртуальные потоки в Java 21+ хорошо подходят для задач, которые большую часть времени проводят в ожидании. Общий Semaphore ограничивает число одновременных обращений к зависимому сервису: каждая задача получает собственный виртуальный поток, но одновременно выполнять вызов API могут не более 10 задач. 👉 Java Portal

💡 Измеряйте покрытие кода тестами, но не гонитесь за 100%. ✅ Покрытие показывает, какие строки выполнились, а не то, что они работают правильно. ✅ Даже при полном покрытии реальные баги могут остаться незамеченными. ✅ Содержательные проверки наиболее рискованных сценариев важнее идеального показателя. 👉 Java Portal

Prompt Engineering и Context Engineering Prompt Engineering — проектирование инструкций для LLM, чтобы получать более качественные ответы. Главная задача — понять, как инструкции влияют на поведение модели. 1. Структура промпта: Роль + Контекст + Ограничения + Формат ответа. Пример: «Ты опытный Java-архитектор. Объясни JWT-аутентификацию простым языком для начинающих. Оформи ответ списком». 2. Типы промптов: • Zero-shot — задача без примеров. • Few-shot — задача с примерами. • Chain-of-thought — побуждение модели решать задачу пошагово. • Structured prompting — запрос ответа в заданном формате, например JSON по определённой схеме. 3. Context Engineering: Качество работы AI зависит не только от формулировки запроса, но и от того, какую информацию и возможности получает модель: • Поиск и извлечение релевантных данных — retrieval. • Память. • Организация рабочего процесса — workflows. • Инструменты. • Системные инструкции. Что важно для реальных проектов: Одних удачных промптов недостаточно для масштабирования AI-систем. В продакшене нужны продуманная архитектура, качественный retrieval, управление памятью и проверка результатов. 👉 Java Portal

🚀 Spring Boot 4: EnvironmentPostProcessor сменил пакет ✅ Новый: org.springframework.boot.EnvironmentPostProcessor ✅ Старый пакет временно сохранён, но помечен как устаревший. ✅ Обновите импорты в коде и регистрацию в spring.factories. 👉 Java Portal

План изучения Java за 6–12 месяцев в эпоху ИИ Этап 1. Java и основы программирования • Что такое Java и где она применяется. • Установка JDK и настройка IDE. • Синтаксис и структура программы. • Переменные, типы данных и операторы. • Условия, switch и циклы. • Использование ИИ для объяснения концепций Java и ошибок. Этап 2. Объектно-ориентированное программирование • Классы и объекты. • Инкапсуляция. • Наследование. • Полиморфизм. • Абстракция. • Интерфейсы. • Визуализация связей между классами с помощью ИИ. Этап 3. Основные возможности Java • Массивы и коллекции: List, Set, Map. • Дженерики. • Обработка исключений. • Работа с файлами и вводом-выводом. • API даты и времени. • Лямбда-выражения и Stream API. • Рефакторинг с помощью ИИ. Этап 4. Память и основы производительности • Архитектура JVM. • Heap и stack. • Основы сборки мусора. • Утечки памяти. • Основы профилирования. • Анализ проблем производительности с помощью ИИ. Этап 5. Многопоточность и конкурентность • Потоки и Runnable. • Executor Framework. • Синхронизация. • Блокировки и конкурентные коллекции. • CompletableFuture. • Предотвращение гонок данных и взаимных блокировок. Этап 6. Базы данных и хранение данных • Основы JDBC и SQL. • Hibernate и JPA. • Связи между сущностями. • Транзакции. • Основы кеширования. • Оптимизация запросов с помощью ИИ. Этап 7. Бэкенд-разработка на Java • Основы Spring Boot. • Разработка REST API. • Контроллеры и сервисы. • Внедрение зависимостей. • Валидация. • Управление конфигурацией. • Документирование API: Swagger/OpenAPI. • Генерация API с помощью ИИ. Этап 8. Безопасность и аутентификация • Основы Spring Security. • Аутентификация с JWT. • Концепции OAuth 2.0. • Управление доступом на основе ролей. • Хеширование паролей. • Безопасная работа с конфигурацией. Этап 9. Тестирование, DevOps и развёртывание • Unit-тесты: JUnit и Mockito. • Интеграционные тесты. • Maven и Gradle. • Контейнеризация Java-приложений с Docker. • CI/CD. • Основы развёртывания в облаке. • Генерация тестов с помощью ИИ. Этап 10. Продвинутая Java и архитектура • Микросервисная архитектура. • Взаимодействие сервисов. • Кеширование с Redis. • Брокеры сообщений: Kafka и RabbitMQ. • Событийно-ориентированные системы. • Мониторинг приложений. • Настройка производительности. Этап 11. Практические проекты • Бэкенд с REST API. • Система аутентификации. • Бэкенд интернет-магазина. • Система на микросервисах. • Java-приложение, развёрнутое в облаке. • Настройка логирования и мониторинга. Этап 12. Подготовка к работе • Подготовка к Java-собеседованиям. • Основы алгоритмов и структур данных. • Основы проектирования систем. • Практики чистого кода. • Умение объяснять, как вы используете ИИ в разработке. • Привычка постоянно учиться. 👉 Java Portal

💡 Тестируйте крайние случаи: null, пустые значения и границы часто скрывают баги ✅ Проверки только успешного сценария могут пропустить NullPointerException. ✅ Пустые списки и списки из одного элемента могут выявить ошибки, незаметные на обычных данных. ✅ Тесты крайних случаев также документируют ожидаемое поведение кода. 👉 Java Portal

😂 👉 Java Portal

💡 Предпочитайте делегирование наследованию: отношение «является» тесно связывает ваш класс с суперклассом. ✅ Подкласс наследует весь доступный API родителя, поэтому изменения в родительском классе могут сломать ваш код. 👉 Java Portal

🚀 Spring Boot 4: переименовано свойство преобразования исключений ✅ Было: spring.dao.exceptiontranslation.enabled ✅ Стало: spring.persistence.exceptiontranslation.enabled ✅ Используйте spring-boot-properties-migrator, чтобы обнаружить устаревшее свойство при миграции. 👉 Java Portal

Процесс ≠ Поток ≠ Виртуальный поток. Эти понятия часто путают, хотя они решают разные задачи. Процесс — экземпляр запущенной программы с собственным адресным пространством. Поток — единица выполнения внутри процесса. Потоки одного процесса разделяют память. Виртуальный поток — легковесный поток под управлением JVM, который позволяет обрабатывать множество конкурентных задач с небольшими накладными расходами. Когда что использовать? Процесс: • Нужна строгая изоляция. • Требуется отдельное адресное пространство. • Подходит для запуска независимых приложений. Поток: • Разделяет память с другими потоками процесса. • Подходит для параллельной работы внутри приложения. • Используется в традиционных многопоточных программах. Виртуальный поток — Java 21+: • Создаётся и управляется JVM. • Требует мало ресурсов при создании. • Хорошо подходит для задач с ожиданием ввода-вывода: запросов к БД, HTTP-вызовов и обработки сетевых соединений. • Позволяет выполнять тысячи и даже миллионы конкурентных задач без отдельного потока ОС для каждой. Примеры из практики • Запущенные Chrome и VS Code → несколько процессов. • Обработка запросов в Spring Boot → работа потоков внутри приложения. • Java-сервис с большим количеством блокирующих обращений к БД или HTTP API → сценарий для виртуальных потоков. Важно: виртуальные потоки полезны для задач с ожиданием ввода-вывода. Вычисления, интенсивно использующие CPU, сами по себе быстрее от них не станут. 👉 Java Portal

Когда Java-стектрейс оказался длиннее контекста ИИ 👀 👉 Java Portal

Spring Boot 4: приближение срока истечения SSL-сертификатов больше не меняет статус health-проверки на специальный. ✅ Статус WILL_EXPIRE_SOON удалён. ✅ Статус остаётся UP; проверяйте details.expiringChains. ✅ Порог предупреждения настраивается параметром:

management.health.ssl.certificate-validity-warning-threshold

👉 Java Portal

Почему один и тот же Java-файл .class запускается на Windows, Linux и macOS без перекомпиляции? Секрет не в самом языке Java, а в JVM. Вот какой путь проходит программа: Hello.java → javac → Hello.class (байткод) → JVM → машинный код → выполнение программы Именно этот дополнительный уровень абстракции даёт Java её знаменитую возможность: «Написал один раз — запускай где угодно». Когда понимаешь эту цепочку, разобраться в JIT-компиляции, сборке мусора и настройке JVM становится гораздо проще. Как думаете, почему Java использует промежуточный байткод, а не компилируется сразу в машинный код? 👉 Java Portal

Docker прост, пока всё работает. Но что делать, если контейнер постоянно перезапускается, логи пропали, а приложение теряет данные после перезапуска? Тут уже недостаточно одного docker run. Команды Docker, которые стоит знать каждому разработчику: • docker logs -f → следить за логами приложения. • docker exec -it → выполнять команды внутри работающего контейнера для диагностики. • docker inspect → изучать конфигурацию контейнера. • docker stats → проверять потребление CPU и памяти. • docker network → управлять сетями и разбираться с соединениями между сервисами. • docker volume → управлять томами для хранения данных вне жизненного цикла контейнера. • docker compose → запускать несколько сервисов вместе. • docker system df → проверять, сколько места на диске занимает Docker. В продакшене не забывайте: • Использовать небольшие базовые образы из доверенных источников. • Запускать приложение от пользователя без прав root. • Настраивать проверки работоспособности и ограничения ресурсов. • Не хранить секреты в Docker-образах. • Использовать тома для постоянного хранения данных. Подготовили шпаргалку по Docker для продакшена: архитектура, команды, примеры, сети, тома, Compose и советы по диагностике проблем. 👉 Java Portal

Эволюция языков программирования 1940-е → Машинный код ⬇️ 1950-е → Ассемблер ⬇️ 1960-е → FORTRAN • COBOL • BASIC ⬇️ 1970-е → C • Pascal ⬇️ 1980-е → C++ • Objective-C ⬇️ 1990-е → Java • JavaScript • PHP ⬇️ 2000-е → C# • Ruby • Scala ⬇️ 2010-е → Go • Rust • Kotlin • Swift ⬇️ 2020-е → Программирование с помощью ИИ Каждое поколение решало свои задачи: • Машинный код → прямое управление оборудованием. • Ассемблер → инструкции, понятные человеку. • C и Pascal → переносимость программ и структурное программирование. • Java и JavaScript → корпоративное ПО и современный веб. • C#, Ruby и Scala → продуктивность разработчиков и масштабируемые приложения. • Go, Rust, Kotlin и Swift → облачные системы, безопасность памяти и современные платформы. • Программирование с помощью ИИ → ускорение разработки, при котором архитектурные решения по-прежнему принимают люди. Что самое интересное? Языки развивались не потому, что старые становились бесполезными. Каждое новое поколение ПО приносило новые задачи. И вот подтверждение: • На C по-прежнему пишут операционные системы. • На Java работают миллионы корпоративных приложений. • JavaScript по-прежнему доминирует в вебе. • Python остаётся ведущим языком в ИИ и анализе данных. Новое не заменяет старое. Оно расширяет возможности. На каком языке вы написали свой первый Hello, World!? 👉 Java Portal