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

Приглашаем на ЮMoneyDay — бесплатную онлайн-конференцию про финтех и IT 🔥 На протяжении двух дней будем общаться с разработчиками, инженерами, тестировщиками, продактами, дизайнерами и другими специалистами из ЮMoney. Они расскажут про свой опыт работы в большом финансовом продукте, поделятся лайфхаками и секретами. Будут доклады по 16 направлениям: 🟣 Будущее финтеха 🟣 Бэкенд 🟣 Фронтенд 🟣 Тестирование 🟣 Python 🟣 Менеджмент проектов 🟣 Менеджмент продуктов 🟣 Системный анализ 🟣 SQL 🟣 UX 🟣 ИИ 🟣 Архитектура IT-решений 🟣 Внутренние системы 🟣 Мобильная разработка 🟣 Инфраструктура 🟣 О компании Встречаемся онлайн 5 и 6 декабря в 11:00 мск. Чтобы участвовать, зарегистрируйтесь на сайте конференции ✅

Одна ключевая идея в Spring Boot, которая в 2025 отличает синьоров от staff/principal инженеров: Большинство разработчиков думают, что Spring Boot это просто @RestController + JPA. Инженеры уровня staff и выше понимают, что настоящий переломный момент это относиться к потокам как к детали реализации, а не к ресурсу. Virtual Threads (Project Loom) + Spring Boot 3 позволяют блокирующему коду масштабироваться лучше, чем это когда-либо делал реактивный стек. Теперь не нужно выбирать упрощение или производительность. Можно иметь оба варианта сразу. Один такой сдвиг в мышлении может поднять пропускную способность системы в 10 раз и вдвое снизить сложность.

@RestController
@RequestMapping("/api/orders")
class OrderController {

    @Autowired JdbcTemplate jdbc;     // Оставляй свой старый добрый блокирующий JDBC
    @Autowired RestTemplate rest;      // Оставляй привычный блокирующий RestTemplate
    @Autowired EntityManager em;       // Оставляй JPA/Hibernate в том виде, как привык

    @GetMapping("/{id}")
    public Order get(@PathVariable Long id) {
        // 100% блокирующий код — читает БД, вызывает 3 downstream HTTP-сервиса
        // Но благодаря виртуальным потокам один этот endpoint
        // спокойно выдерживает 50k+ RPS на 2 vCPU при < 50 ms p99

        var order   = jdbc.queryForObject("SELECT * FROM orders WHERE id=?", Order.class, id);
        var payment = rest.getForObject("http://payment/{id}", Payment.class, id);
        var shipping = rest.getForObject("http://shipping/{id}", Shipping.class, id);

        return order.withPayment(payment).withShipping(shipping);
    }
}

👉 Java Portal

Уменьшаем время выборки из БД с 2–3 секунд до ~100 мс:

SELECT * FROM transactions
WHERE user_id = 40
ORDER BY created_at DESC
LIMIT 20 OFFSET 10000;

На первый взгляд запрос нормальный? ДА, вроде ок. Но: - это OFFSET-пагинация - и это прям ПЛОХО - БД вытягивает 10020 строк и выкидывает 10000, чтобы показать 20, лол - чем больше OFFSET, тем больше нагрузка на БД - со временем запрос начинает занимать больше 2 секунд, пока растет объем данных Решение: KEYSET (seek) пагинация: добавляем условие вида created_at < last_seen_timestamp

SELECT * FROM transactions
WHERE user_id = 40
  AND created_at < '2024-05-01 10:00:00'
ORDER BY created_at DESC
LIMIT 20;

- так БД может сразу прыгнуть по индексу - по сути это "дай следующие 20 записей после этого timestamp", где timestamp используется как ключ - время реально падает с секунд до примерно 100–200 мс Что если timestamp не уникален, есть дубли: Добавляем tie-breaker: (created_at, id) и в WHERE, и в ORDER BY:

WHERE (created_at, id) < ('2024-05-01 10:00:00', 98765)
ORDER BY created_at DESC, id DESC

Так пагинация остается быстрой и детерминированной, даже при одинаковых created_at. 👉 Java Portal

Совет по Java: используй WeakHashMap для кеширования, если ключи без ссылок должны автоматически очищаться сборщиком мусора. В HashMap, пока объект карты существует, ключи и связанные с ними значения не будут собраны сборщиком мусора. В WeakHashMap ключи хранятся через слабые ссылки, и если на ключ больше нет сильных ссылок в других частях программы, GC может освободить его, и он будет автоматически удалён из карты. Пример:

Map<User, String> map = new WeakHashMap<>();

User u1 = new User("Mick");
map.put(u1, "Cached data");
...
u1 = null;

// Теперь ключ u1 может быть собран сборщиком мусора.

👉 Java Portal

Это расширение для Chrome прям находка для тех, кто активно сидит на GitHub Называется SimRepo и показывает похожие репозитории для любого открытого проекта. Просто устанавливаешь и забываешь — расширение автоматически срабатывает каждый раз, когда открываешь репозиторий. Полезно, если хочешь найти что-то лучше, посмотреть альтернативы или просто открыть для себя новые проекты во время поиска ☺️ 👉 Java Portal

Подсказка по Java: начиная с Java 11 можно использовать String.strip() вместо trim(), потому что strip() корректно обрабатывает пробелы в Unicode. Так как trim() не обрабатывает некоторые типы пробелов, определенные в Unicode, он может оставлять неожиданные символы. String.strip() использует Character.isWhitespace(int codePoint) для определения пробельных символов, учитывая полный стандарт Unicode, а не только ASCII, и удаляет все виды пробелов. Пример:

String text = "\u2003Hello World\u2003";
System.out.println("trim(): [" + text.trim() + "]");
System.out.println("strip(): [" + text.strip() + "]");

👉 Java Portal

Быстрый Kafka consumer на виртуальных потоках. Каждое новое сообщение, которое получает listener, обрабатывается в отдельном виртуальном потоке. Естественно, при таком подходе теряется порядок сообщений внутри одного partition. Выбирай, что для тебя важнее. 👉 Java Portal

🔥 Чёрная пятница на Stepik: забери -25% на курс: "Грокаем паттерны SQL-собеседований" Преподаватели берут то, с чем сами сталкиваются в повседневной работе Data Scientist, AI/ML Engineer, Data Engineer и Data Analyst, и превращают это в понятные практические упражнения. Задачи в духе LeetCode, разбор живых кейсов, приёмы оптимизации. Всё, что позволяет уверенно чувствовать себя на собеседовании и дальше уже в команде. После прохождения вы получите сертификат, который можно добавить в резюме. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «BLACKFRIDAY25»: открыть курс на Stepik

Какой Java Map быстрее для 1 млн обращений? Производительность (в среднем):

HashMap get(): ~0.8 ms (O(1)) TreeMap get(): ~15 ms (O(log n)) HashMap put(): ~1.2 ms TreeMap put(): ~18 ms

HashMap выигрывает по сырым скоростям примерно в 15–20 раз. TreeMap жертвует производительностью ради отсортированного порядка ключей. HashMap использует хеширование с операциями за амортизированное константное время. TreeMap использует красно-черное дерево, гарантируя O(log n), но за счет скорости. Используй HashMap, когда важна скорость, и TreeMap, когда нужны отсортированные ключи или диапазонные запросы. 👉 Java Portal

Java-команды часто ищут прорывы не там. Spring + JVM получает больше профита от Kotlin, чем от попыток перезабрести фреймворк. Kotlin прокачивает базу. А именно база решает, движется ли команда быстро или нет 1. Код становится проще. Меньше шаблонного мусора. Более безопасные дефолты. Четче выраженные намерения. Команда делает те же фичи быстрее и с меньшим количеством багов. 2. Работа с конкурентностью становится чище. Коррутины стабильнее и удобнее, чем вечная возня с потоками. Та же JVM. Тот же Spring. Но асинхронный код наконец становится предсказуемым 3. Миграция с низкими рисками. Никаких переписанных с нуля сервисов. Никаких параллельных стеков. Никакого большого взрыва. Kotlin можно внедрять точечно - новые модули, новые сервисы, тесты, внутренние тулзы. Эффект накапливается довольно быстро. Так выглядит распространенный сценарий в успешных командах: Один инженер пробует -> остальные замечают разницу -> adoption летит вверх. 4. Бизнес тоже ощущает разницу. Меньше дефектов. Быстрее онбординг. Выше скорость разработки. Лучше асинхронное поведение. И все это без замены стека. Kotlin не переписывает ваш проект. Он исправляет мелочи, которые тормозят бекенд-команду годами. Если ты уже на Spring + JVM, это самый выгодный апгрейд, который можно выкатить хоть завтра 🍌 👉 Java Portal

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

Java-подсказка: начиная с Java 11, если нужно повторить строку n раз, можно использовать метод repeat(n) у String. 👉 Java Portal

⚡️Чёрная пятница на Stepik: забери -25% на курс по Linux! Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой). Материал подаётся понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами. После прохождения вы получите сертификат, который можно добавить в резюме. Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 20% по промокоду «BLACKFRIDAY25»: открыть курс на Stepik

Совет по Spring Boot RestTestClient для тестирования API RestTestClient это единый инструмент для тестирования REST API, который можно использовать вместо WebTestClient, TestRestTemplate (удалён) или MockMVC. 1. Определи объект RestTestClient в тесте 2. Привяжи его к конкретному компоненту. Это может быть controller, MockMVC, server или Spring context 3. Потом используй RestTestClient в тесте

@SpringBootTest
public class PersonControllerWithHeadersTests {

    private WebApplicationContext context;
    private RestTestClient restTestClient;

    @BeforeEach
    public void setup(WebApplicationContext context) {
        restTestClient = RestTestClient
                .bindToApplicationContext(context)
                .build();
    }

    @Test
    void addPersonTest() {
        restTestClient.post()
                .uri("/persons")
                .body(Instancio.create(Person.class))
                .exchange()
                .expectStatus().is2xxSuccessful()
                .expectBody(Person.class)
                .value(p -> assertNotNull(p.getId()));
    }
}

👉 Java Portal

Всегда есть шанс, что один и тот же запрос прилетит в ваш API или сервер несколько раз. Даже если вы отключаете кнопку после первого клика, вероятность уменьшается, но не исчезает. Это решается идемпотентностью. Идемпотентность — это когда одна и та же операция, выполненная несколько раз, даёт строго один и тот же результат. Не похожий. Не почти такой же. А точно такой же. Например, в платежных системах это обязательное свойство. Это разница между стабильной системой и системой, которая может уронить бизнес. Представим эндпоинт /payment/charge. Если пользователь дважды жмёт кнопку оплатить, приложение не должно интерпретировать это как две транзакции. По сути решение простое: клиент отправляет idempotency-key, а сервер гарантирует, что операция будет выполнена только один раз. Но правильная реализация важна. Недостаточно просто игнорировать дубликаты. Нужно сохранять результат первой операции и возвращать его при повторных запросах, даже если второй запрос пришёл раньше, чем завершилась первая обработка. Это значит, что потребуется хранить состояния, промежуточные результаты и думать об операции как о той, которую можно повторить без нарушения согласованности. Без идемпотентности API ведет себя непредсказуемо. С идемпотентностью можно пережить сетевые сбои, таймауты, повторные подключения и слишком быстрых юзеров, не ломая систему. 👉 Java Portal

Java 21. Виртуальные потоки + структурированная конкуренция в 15 строках: Запускай 100000+ конкурентных задач почти без оверхеда с виртуальными потоками. Структурированная конкуренция делает async-код читаемым как синхронный, без утечек и callback-адского. В реальных проектах даёт 10-кратный рост пропускной способности при гораздо более простом коде. 👉 Java Portal

Spring Boot: Spring Data JPA имеет встроенную поддержку пагинации через Pageable. Лучше использовать пагинацию в репозиториях вместо того, чтобы вытягивать все данные разом. Вместо такого репозитория:

public interface BookRepository extends JpaRepository<Book, Long> {
    List<Book> findAll();
}

Лучше так:

public interface BookRepository extends JpaRepository<Book, Long> {
    Page<Book> findAll(Pageable pageable);
}

И дальше в сервисном слое:

public Page<Book> getBooks(int page, int size) {
    Pageable pageable = PageRequest.of(page, size, Sort.by("createdAt").descending());
    return bookRepository.findAll(pageable);
}

👉 Java Portal

Есть забавная вещь, которая происходит со многими Java-разработчиками. Oни пишут современный код с мышлением старой Java. И, если честно, их сложно за это винить. Java менялась куда быстрее, чем комьюнити успевало к этим изменениям адаптироваться. Годами Java ассоциировалась с огромными классами, кучей геттеров и сеттеров, громоздкими фабриками, бесконечными try/catch блоками. Со стороны казалось, что язык боится любого изменения. Java была про структуры и правила. Это был язык принципа = делай явно или не делай вообще. Но потом подъехали серьезные обновления: лямбды, records, pattern matching, sealed-классы, streams, более выразительный switch, выведение типов, более декларативные API, и стиль, который стал ближе к функциональному. У всего этого есть плюсы и минусы, понятно. И внезапно Java перестала ощущаться языком начала двухтысячных и стала языком под 2025 год (ну или под 2020, кому как). Хотя многие до сих пор пишут так, будто на календаре 2010. Но важно понимать! часто дело не в техническом выборе. Это может быть привычка, вкусы или просто невозможность перейти на новую версию. И главный момент тут в том, что современная Java не заменяет классическую = они существуют параллельно. Хотя со временем, конечно, и "новая Java" тоже станет предметом споров и хейта, как старая. Язык изменился, но команды, компании, легаси-фреймворки и технические решения десятилетней давности никуда не делись. Они тянут в обратную сторону и фактически продолжают поддерживать устаревшее представление о Java. Java сегодня это умение жить сразу в двух эпохах. Если ты понимаешь эту двойственность, тогда можешь использовать язык по максимуму. Если нет, то просто будешь сражаться с прошлым, которого уже нет, и игнорировать настоящее, которое уже здесь и точно никуда не денется. 👉 Java Portal

Очень в тему перечитать этот классический материал от Майка Бостока. Отлично ложится как продолжение поста. https://bost.ocks.org/mike/algorithms/ 👉 Java Portal

В начале карьеры я удалил 5GB лог-файл на продовом сервере, который уже почти забился. Я запустил df -h, ожидая, что использование диска упадёт. Не упало. Всё ещё показывало 100% занято. Ни ошибок, ни предупреждений. Просто те же цифры, будто я вообще ничего не удалял. И вот тогда я понял, что удаление файла не всегда сразу освобождает место. В Linux то, что мы называем "файлом", на самом деле состоит из двух частей: имени файла (по сути указателя) и inode (где лежат данные и метаданные). Когда ты удаляешь имя файла, ты просто убираешь указатель. Но inode с данными остаётся на диске, пока какой-то процесс держит файл открытым. В моём случае веб-сервер всё ещё писал в тот самый лог. И хотя я удалил имя файла, процесс продолжал держать открытый файловый дескриптор. Inode оставался живым — его не видно обычными командами, но место он продолжал занимать. Место освободилось только после перезапуска веб-сервера, когда все дескрипторы закрылись. Поэтому нужны разные команды, чтобы увидеть реальную картину: Проверить использование файловой системы:

df -h

Посмотреть реальные размеры директорий:

du -sh /var/log/*

Найти удалённые файлы, которые всё ещё держатся процессами:

lsof +L1

du показывает, что в директориях реально занимает место, а df сколько занято на уровне файловой системы. Если они не совпадают, почти всегда причина = удалённые файлы, которые всё ещё открыты процессами. По этой же причине нормальный log rotation не просто удаляет файлы. Такие инструменты, как logrotate, сначала переименовывают файл и отправляют сигнал процессу, чтобы он корректно закрыл старый дескриптор и открыл новый. Три важных вывода:

Имя файла это всего лишь указатель на inode Удаление происходит только тогда, когда inode больше никем не используется При разборе проблем с диском всегда проверяй и df, и du

Мелочь, но понимание этого может спасти от очень странных и неприятных инцидентов в проде. 👉 Java Portal