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

Java/Backend. Интервью. Сценарный вопрос про распределенный лок: У тебя есть критичный сервис, допустим обработка заказов, который крутится на нескольких инстансах в Kubernetes. Чтобы избежать гонки, когда два инстанса одновременно берут один и тот же заказ, ты ставишь распределенный лок через Redis setnx с TTL 10 секунд. Какой критичный кейс все равно возможен, если один из инстансов словит Full GC паузу длиной 15 секунд сразу после получения лока? Опиши ситуацию split-brain и к чему она приведет по данным. Как это разруливать на интервью: → сначала важно отметить, что простой Redis-лок с TTL помогает, если сервис просто упал, но создает новую, куда более опасную проблему → баг в том, что длинная пауза, например Full GC, может быть дольше, чем TTL лока → и вот что ломается (Split-Brain): Service A берет лок, и тут же уходит в GC на 15 секунд Через 10 секунд Redis удаляет лок по TTL Service B спокойно берет тот же лок, и начинает обрабатывать заказ Через 15 секунд Service A просыпается все еще уверенный, что лок у него и тоже обрабатывает этот же заказ → итог: два сервиса одновременно трогают один и тот же заказ. Данные ломаются. Например клиенту списывают деньги дважды. → реальное решение (меняем дизайн): вообще избавиться от лока Кладем заказы в очередь сообщений, например Kafka или RabbitMQ Consumer group с несколькими инстансами читает этот топик Брокер гарантирует, что каждое сообщение (заказ) уходит только одному инстансу из группы 👉 Java Portal

Совет по Docker Как понять, что раздувает образ Любой Docker-образ состоит из слоев. Каждая строка в Dockerfile добавляет новый слой. По этим слоям можно понять, почему образ получается большим, долго собирается или плохо кешируется. Вот как посмотреть слои и узнать, что именно менялось в каждом из них. Используй утилиту dive. Она показывает наглядно: - какие слои созданы - какие файлы добавлены или изменены - сколько места занимает каждый слой Когда начинаешь изучать слои образа, можно быстро выяснить: • какая команда в Dockerfile добавляет лишний вес • как оптимизировать сборку, чтобы образ был меньше и собирался быстрее Dive также дает оценку «эффективности» образа. Она показывает, насколько много данных дублируется или просто впустую занимает место в слоях. 👉 Java Portal

🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Москве и поборись за призовой фонд 1 200 000 рублей! Когда: 25–28 ноября Формат: онлайн + финал на площадке Участвуй, если ты: 🔹обучаешься на технической или ИТ-специальности 🔹развиваешься в направлении разработки, системной администрации, AI/ML или DevOps 🔹сможешь быть в Москве 28 ноября. Выбери свой кейс:

✴️VibeCode Jam: собеседование будущего. Создай ИИ-платформу для прохождения технических собеседований с виртуальным интервьюером. ✴️Self-Deploy: CI/CD без DevOps. Автоматизируй генерацию CI/CD пайплайнов по анализу структуры Git-репозитория.

Почему стоит участвовать: 🔘Кейс в портфолио и полезная обратная связь от менторов Т1 🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний 🔘Реальный опыт командной работы 🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси. Регистрация открыта! ➡️ Успей до 23 ноября по ссылке. Реклама. О рекламодателе.

Совет по Java: начиная с Java 8 можно легко убирать null значения с помощью list.removeIf(Objects::isNull) 👉 Java Portal

Не все данные обрабатываются одинаково. Понимание, когда подходит batch, а когда stream, решает, получится ли у тебя нормальная архитектура или скрытый тормоз внутри. Batch Processing собирает данные и обрабатывает их пачками. Подходит, когда нет требований к моментальной реакции: ежедневные отчеты, бухзакрытия, историческая аналитика. Он проще, нормально тянет большие объемы и дешевле по деньгам, но появляется задержка. Событие уже случилось, а ты обрабатываешь его потом. Stream Processing работает с данными прямо в потоке. Отлично для мониторинга, антифрода, рекомендаций в реальном времени. Скорость выше, но инфраструктура сложнее и поддержка дороже. Часто косячат: ставят stream там, где батча за глаза, или наоборот, лепят batch туда, где важна минимальная задержка. Фишка не в том, чтобы выбрать самое модное, а в том, чтобы попасть в реальный ритм бизнеса и решить конкретную задачу. А если ресурсы сильно ограничены, скорее всего, batch уже закрывает потребности. 👉 Java Portal

🔍Тестовое собеседование с ТехЛидом из МТС уже завтра 5 ноября(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика. Как это будет: 📂 Илья Аров, старший разработчик в МТС, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Илья будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Илье Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

Видишь разницу между этими двумя кусками кода? 👀 На первый взгляд делают одно и то же, но… В первом варианте все классы вынуждены реализовывать методы, которые им вообще не нужны. Во втором интерфейсы разделены: каждый класс берет только то, что реально использует. Принцип разделения интерфейсов (ISP) 👉 Java Portal

Недавно в регионе US-EAST-1 у AWS были сбои. Как бы ты спроектировал деплой микросервиса и инфраструктуру вокруг, чтобы пережить падение одной инстансы, сбой базы данных или даже отказ целого дата-центра ?

Когда делаем систему с высокой доступностью, нужно сразу исходить из того, что все рано или поздно ломается. Поэтому закладываем автоматическое восстановление на каждом уровне. Держим несколько одинаковых инстансов сервиса за нагрузочным балансировщиком. Деплоим их в разные зоны. Если одна инстанса упала, балансировщик просто перестает слать ей трафик и направляет запросы на оставшиеся живые экземпляры. Для базы данных используем репликацию. Есть primary и хотя бы одна hot-standby реплика в другой физической зоне. Все записи в primary сразу копируются на standby. Практикуем Chaos Engineering: намеренно ломаем часть продовой инфраструктуры, например, убиваем сервисы или добавляем сетевые задержки. Смотрим, что автоматический failover реально срабатывает как задумано, а не только на бумаге. 👉 Java Portal

Подсказка по Spring Boot 4: коллекции с nullable-элементами (List<Nullable String>) помогают ловить NullPointerException на этапе компиляции вместо рантайма. Больше никаких сюрпризов при обработке API-ответов, где могут прилетать null. 👉 Java Portal

Исправляем ту самую ошибку на миллиарды долларов? 👀 Улучшения поддержки null-безопасности в Spring Boot 4 могут оказаться самым недооцененным нововведением предстоящего релиза. Аннотации NonNull и Nullable теперь полноценные граждане во всем фреймворке. Spring постепенно переводит весь код на единый и последовательный подход. Хватит гадать, вернет ли сервис null. IDE поймает потенциальный NPE уже на этапе компиляции, а не в рантайме. То ли поправка, о которой мечтал Тони Хоар? Не полностью. Но это важный шаг к более безопасному Java-коду. Самое приятное? Не нужно мигрировать за один заход. Можно двигаться постепенно, делая код надежнее и уверенно продвигаясь вперед. Null-безопасность в Spring Boot 4 даст нам ту же уверенность в кодовой базе, что и тесты. 👍 👉 Java Portal

Айтишники не рассказывают где учатся бесплатно и эффективно Никому не говори об этом канале!!! В сфере онлайн образования появился новый гигант «TERMINAL» — который разрушит индустрию платных IT-курсов Бесплатный доступ:

🔄Практические курсы и задания 🔄Книги и статьи от профи 🔄Полезные инструменты и ресурсы 🔄IT-новости и инсайды

Обучение по всем направлениям: SQL, Python, Frontend, PHP, C++, Golang, GIT, Linux, Java, кибербезопасность и др. Если ценишь знания — подпишись: @Terminal_tg

Spring Boot совет: если хочешь, чтобы DTO спокойно переживали лишние поля в JSON от клиента и не роняли API, добавляй аннотацию @JsonIgnoreProperties(ignoreUnknown = true) Jackson тогда просто проигнорит поля, которых нет в твоем классе, вместо того чтобы кидать UnrecognizedPropertyException. Удобно, когда фронты любят прислать что-нибудь от себя. Допустим, есть DTO:

public class UserDTO {
    private String name;
    private int age;

    // getters/setters
}

Клиент шлёт такой JSON:

{
  "name": "Alice",
  "age": 25,
  "extraField": "not expected"
}

Jackson скажет что-то вроде:

UnrecognizedPropertyException: Unrecognized field "extraField"

Исправить просто: добавляем @JsonIgnoreProperties

@JsonIgnoreProperties(ignoreUnknown = true)
public class UserDTO {
    private String name;
    private int age;

    // getters/setters
}

И всё. Лишние поля тихонько проигнорятся, API не падает. 👉 Java Portal

Spring Boot 4 показывает нормальную работу null-safety в деле Главная беда в том, что в Java null всегда был вещью по умолчанию и нигде явно не указан. Видишь метод типа: User findUserByEmail(String email) Вернет null? Кто его знает Spring Boot 4 меняет правила игры с NullMarked (на базе JSpecify + NullAway). Одна аннотация на уровне пакета делает работу с null явной. IDE сразу подсвечивает потенциальные NPE еще на этапе компиляции. Больше никаких угадай-ок и сюрпризов на проде. Инструменты подталкивают обрабатывать null там, где это действительно важно. Типы наконец начинают говорить правду. Вот такая developer experience, которой давно ждали. 👉 Java Portal

⚡️ Запускаем крупный розыгрыш призов, где можно выиграть iPhone 17, игровые наушники, клавиатуру и мышь! Без лишних слов, условия: 1. Подписка на: — бизнестрендс — Технотренды — Блумберг 2. Нажать кнопку «Участвовать» снизу Итоги будут опубликованы 15 ноября в 18:00 на наших каналах, желаем удачи!

В Java строки после создания не меняются. Вообще. Совсем. Пишешь:

String saludo = "Hola";
saludo += " mundo";

Кажется, что ты просто дописал кусочек. Но на деле появился новый объект, а старый остался как был. Зачем так заморачиваться? Строки одна из самых используемых штук в JVM: названия классов, SQL-запросы, адреса, токены безопасности, всё подряд. И этими строками спокойно шарятся между потоками. Если бы любой поток мог внезапно изменить текст, который использует другой поток, то был полный бардак: баги из разряда «иногда, где-то, когда-то» и куча дыр в безопасности. Поэтому неизменяемость даёт: • Потоки не мешают друг другу. Никаких локов и синхронизации. • Можно безопасно кешировать строки. Тот же String Pool — из этой оперы. • JVM может оптимизировать работу с ними как ей вздумается, без риска сломать логику программы. Если же нужно много править текст во время выполнения (например, большая сборка строки в цикле) то бери StringBuilder или, если сильно нужна потокобезопасность, StringBuffer. Иммутабельность строки это не чудачество создателей языка. Это фундамент стабильности и безопасности Java. 👉 Java Portal

Нашёл минималистичный инструмент, который берет любую shell-команду и в реальном времени рисует по ней графики. Да, прямо у тебя в консоли. Красиво и без плясок с бубном. Что может: • Выполняет любые команды и сразу строит графики по их выводу • Следит за базами, CPU, сетью, очередями, деплоем и чем угодно ещё • Бьет в колокола, если метрика вылетела за пределы • Настраивается через обычный YAML. Пара строк и ты уже смотришь, как машина дышит • Работает локально, без облаков и лишних зависимостей 👉 Java Portal

Самый прямолинейный способ вынести секреты во внешнее хранилище в Spring Boot приложении это использовать Spring Cloud Config Server. Spring Cloud Config Server позволяет хранить конфигурацию приложения в централизованном репозитории (обычно Git). В случае с Git репозиторием при старте приложение подтягивает конфигурационные файлы с Config Server, а не локально, а сам Config Server берет их из Git репозитория. Ниже пример конфигурации, чтобы сервер подключался к Git репо:

cloud:
  config:
    server:
      git:
        uri: https://github.com/username/spring-cloud-config-git-server-repo.git
        username: ${github.username}
        password: ${github.password}

Конфигурация клиента может выглядеть примерно так:

config:
  import: "optional:configserver:"

Можно шифровать чувствительные данные в конфигурационных файлах в Git репо. Ниже пример с паролем для key-store, который используется для защищенного SSL соединения (обрати внимание на префикс {cipher}, он обязателен)

server:
  port: ${PORT:8092}
  ssl:
    enabled: true
    key-store: classpath:books.p12
    key-store-password: '{cipher}AAQAB0P8AKMImyLncL3WUbLsn2J0DlHBeMbmylb0e5RMqr7QWrPhDwJ8xVMw...'
    key-store-type: PKCS12:

Альтернатива это использовать HashiCorp Vault 👉 Java Portal

Векторные базы данных простыми словами Представь, у тебя есть 10 000 описаний товаров. Пользователь ищет "удобная уличная мебель". Обычная база данных: Ищет точные совпадения слов Находит товары с "удобная" ИЛИ "уличная" ИЛИ "мебель" Пропускает "уютные кресла для террасы", хотя это то же самое Ключевые слова — тупой способ поиска Векторная база данных: Превращает запрос в набор чисел, отражающих смысл: [0.2, 0.8, 0.1, 0.9, ...] Каждое описание товара тоже превращается в такие числа Сравнивает эти "векторы" и ищет похожие по смыслу Находит "уютные кресла для террасы", потому что векторы похожи Смысловой поиск — умный поиск Как это работает Шаг 1. Превращаем текст в векторы (массивы чисел) "comfortable chair" → [0.2, 0.7, 0.1, 0.4, ...] "cozy seat" → [0.3, 0.8, 0.2, 0.5, ...] Похожие фразы → похожие числа Это делает AI-модель, например OpenAI embeddings Шаг 2. Храним векторы В обычной БД хранят текст В векторной — массив чисел для каждого объекта Индексируют их, чтобы быстро искать по схожести Оптимизировано под "найди похожие", а не "найди точное" Шаг 3. Ищем по схожести Запрос: "outdoor furniture" Превращается в [0.3, 0.6, 0.2, 0.8, ...] Система ищет ближайшие векторы (через cosine similarity) Результаты сортируются по степени похожести Где это используется: - Поиск товаров, который понимает смысл, а не только слова - Поиск по документации, который находит релевантные ответы - Рекомендательные системы - Чатботы, ищущие похожие вопросы - Обнаружение аномалий Популярные векторные базы Pinecone = управляемая, простая, но дорогая Weaviate = опенсорс, с кучей функций Milvus = быстрая и масштабируемая, но сложная pgvector = расширение для Postgres, простое и удобное Qdrant = быстрая, написана на Rust Спорная, но практичная мысль В большинстве проектов тебе не нужна отдельная векторная база. Начни с Postgres + pgvector = этого хватает, пока у тебя меньше 1 миллиона векторов. Когда масштаб вырастет, тогда уже смотри в сторону специализированных решений. 👉 Java Portal

❤️ Приходите на Backend Talks от Яндекс 360 Санкт-Петербург, 13 ноября в 19:00 Разберём архитектуру облачной записи встреч, наведём порядок в API и покажем, как простые решения спасают сервисы. В программе: 📌 Как не упустить важное: архитектура облачной записи и конспектирования видеовстреч в Телемосте — Илья Григорьев, разработчик бэкенда Телемоста. 📌 Укрощение API: процессы и инструменты, которые действительно работают — Никита Ломакин, разработчик в команде Техплатформы. 📌 Как мы закапывали звездолёт: почему важно отстаивать простоту на архревью — Артемий Коцюбенко, разработчик протокольных сервисов Почты. Команда Яндекс 360 работает с нагрузками >1.000.000+ RPS и создает продукты которыми пользуются 95+ млн человек каждый месяц — Диск, Почта, Телемост, Мессенджер и другие. 🍻А после докладов вас будут ждать афтепати и нетворкинг! Регистрируйтесь по ссылке

Java совет: начиная с Java 8 лучше использовать java.time вместо Date и Calendar. 👉 Java Portal