🧩 Разница между параллельными и распределёнными вычислениями

Ускорение работы приложения можно получить двумя способами: распараллелить работу между ядрами одного компьютера или разнести ее по нескольким машинам.

Параллельные вычисления живут внутри одного узла: части задачи выполняются одновременно на CPU-ядрах, нескольких процессорах или ускорителях GPU/TPU.

Параллелизм бывает по задачам и по данным (одна операция над разными блоками), а также на уровне инструкций (конвейеризация, суперскалярность) и битов. Обмен данными чаще происходит через общую память и локальный IPC, поэтому задержки ниже.

Распределенные вычисления делят в свою очередь работу между автономными узлами по сети. Данные передают сообщениями или через RPC, координация сложнее, зато масштабирование обычно проще: добавил узлы - выросли вычисления и хранилище. Часто закладывают отказоустойчивость: репликация, резервирование, обнаружение ошибок.

🔗 Подробности в нашей статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1008990/

Для JetBrains IDE вообще есть нормальный AI без проблем в РФ?

Периодически в @spring_aio_chat и на Хабре прилетают вопросы про то, какие сейчас есть варианты использования ИИ внутри IDE.

Один из вариантов – Kodacode.

Работает:
— в OpenIDE и JetBrains IDE
— в VS Code
— и даже в CLI

Что кажется наиболее полезным:
— агентный режим: без него от ИИ-помощника смысла не так много
— доступ к разным моделям: GLM, Gemini, DeepSeek, и другие
— работает без танцев с VPN и оплатами: у многих это сейчас главный стоп-фактор для AI-инструментов
— есть бесплатная модель: хватает для повседневных задач

📚 Подробнее про Koda для JetBrains IDE читайте на Хабр: https://habr.com/ru/companies/koda/articles/986976/

👩‍💻 JEP 524 в JDK 26 — второй preview PEM API.

Наконец-то работа с PEM в Java становится похожа на API, а не на набор ручного парсинга, Base64 и странных телодвижений.

Справка: PEM или Privacy-Enhanced Mail - это текстовый контейнер для криптографических данных. Проще говоря – это способ хранить или передавать ключ, сертификат или другой crypto-объект не в бинарном виде, а в текстовом.

Раньше с PEM работали так:

String pem = "-----BEGIN PUBLIC KEY-----\n"
        + Base64.getMimeEncoder(64, "\n".getBytes())
                .encodeToString(publicKey.getEncoded())
        + "\n-----END PUBLIC KEY-----";

А в обратную сторону, но уже с ручной нормализацией PEM, Base64-декодированием и KeyFactory:

String normalized = pem
        .replace("-----BEGIN PUBLIC KEY-----", "")
        .replace("-----END PUBLIC KEY-----", "")
        .replaceAll("\\s", "");

byte[] der = Base64.getDecoder().decode(normalized);

PublicKey key = KeyFactory.getInstance("EC")
        .generatePublic(new X509EncodedKeySpec(der));

По факту PEM в Java долгое время был не отдельным API, а набором низкоуровневых шагов, которые разработчик собирал руками.

А теперь это выглядит так:

var encoder = PEMEncoder.of();
String pem = encoder.encodeToString(keyPair);

var decoder = PEMDecoder.of();
KeyPair decoded = decoder.decode(pem, KeyPair.class);

То есть ключевую пару можно закодировать в PEM и декодировать обратно буквально в несколько строк.

Во втором preview:
— PEMRecord переименовали в PEM
— добавили decode()
— расширили поддержку KeyPair и PKCS8EncodedKeySpec
— упростили шифрование через EncryptedPrivateKeyInfo

А так, как все это дело еще в preview, не забываем использовать --enable-preview.

❓ Минус еще один кусок криптографической копипасты из Java-кода. PEM в Java постепенно перестает быть унылым?

#видеозаписи

Открываем новую видеозапись доклада:
Михаил Поливаха — Spring AOT: кодогенерация на стероидах

😉 YouTube | 📺 VK Видео

🗑️ Изменения в G1/Parallel/Serial GC в JDK 26

JDK 26 выходит уже совсем скоро. Тем временем в GC закрыли около 380 задач (почти в 2 раза больше, чем в прошлом релизе), но в этот раз акцент сместился с больших фич в пользу практичных доработок.

Главное для всех сборщиков: нормальный учет CPU GC. Теперь считают не только stop-the-world паузы, но и конкурентную работу и дедупликацию строк. Можно посмотреть через лог cpu=info при завершении VM, обновили Hsperf-счетчики, есть доступ из кода. Плюс новый JFR-ивент с деталями по string dedup.

JEP 516: Aot Cache стал независим от выбранного GC и опций VM. Включение через опцию -XX:+AOTStreamableObjects.

G1 получил самые заметные улучшения: JEP 522 уменьшает синхронизацию между GC и приложением (цель - увеличить throughput). Еще: целевое использование CPU G1 по умолчанию снижено с 8% до 4%, добавили важнейший флаг UseGCOverheadLimit.

Комментарий от Михаила Поливаха:

Важно и то, что HotSpot GC команда в Oracle смотрит в сторону Automatic Heap Sizing. На эту темы было много шума на Redit и не зря. Поговорим об этом на подкасте.

📎 Подробнее в статье: https://habr.com/ru/companies/spring_aio/articles/1010904/

👩‍💻 Привет, Java 26!

Встречаем 26 версию нашего любимого языка программирования.

Что самое заметное:

☑️ HTTP/3 в HttpClient (JEP-517)
Теперь java.net.http.HttpClient умеет HTTP/3. Для client-side кода это хороший апгрейд: меньше магии, ближе к современному вебу из коробки.

☑️ G1 стал быстрее по throughput (JEP-522)
В Java 26 уменьшили синхронизацию между application threads и GC threads. Для тех, кто сидит на G1 по умолчанию, это может дать вполне практичный прирост без смены GC и без шаманства с флагами.

☑️ Structured Concurrency все еще с нами (JEP-525)
Уже шестой preview, но направление давно понятно: многопоточность в Java все сильнее движется к более внятной модели управления связанными задачами, отменой и ошибками. Для сервисного кода — очень правильный вектор.

☑️ Pattern Matching расширили на примитивы (JEP-530)
instanceof, switch, patterns — теперь и для примитивных типов. Пока preview, но курс очевиден: язык становится ровнее и выразительнее.

☑️ Vector API продолжает дозревать (JEP-529)
Уже 11-й incubator. Для high-performance сценариев, аналитики и местами AI/inference должно быть полезным.

☑️ Leyden-путь продолжается (JEP-516)
AOT object caching теперь работает с любым GC, включая ZGC. То есть разговор про быстрый startup/warmup Java-приложений становится еще менее "на словах".

☑️ final начинают защищать всерьез (JEP-500)
Добавляются предупреждения на deep reflection, который мутирует final-поля. Java продолжает двигаться к integrity by default. Если у вас есть старые хаки через reflection, то самое время проверить, не пора ли их вычищать.

☑️ Applet API удалили окончательно (JEP-504)
Да, в 2026 это уже скорее символический жест. Но хороший, так платформа продолжает избавляться от давно мертвого наследия.

А ещё:

🔘Process теперь AutoCloseable
🔘появился UUIDv7 через UUID.ofEpochMillis(...)
🔘Javadoc получил dark theme
🔘Thread.stop() удален окончательно
🔘виртуальные потоки стали аккуратнее вести себя в одном неприятном сценарии с class initialization

Итог

Пожалуй, нас не порадовали “кричащими” фичами уровня смены эпохи, но есть много сильных улучшений в том, что реально влияет на повседневную разработку: сеть, GC, concurrency, безопасность, startup и чистка платформы от старого балласта.

📎Полный список изменений тут: https://jdk.java.net/26/release-notes

❓Кто уже успел посмотреть JDK 26 — что зацепило больше всего?

🌎 О размерах пула соединений

Есть такой момент, что большой пул часто ухудшает отклик: БД упирается в ограниченные ресурсы (CPU, диск, сеть), начинается лишняя конкуренция и накладные расходы, latency растет.

Действительно, ребята из Oracle в своей демке обычным уменьшением пула снизили время ответа примерно со 100 мс до 2 мс.

Сама практика такая: пул держат небольшим. Потоки приложения запрашивают свободное соединение в пуле, либо ждут его появления там. Это нормальная очередь, которая защищает БД от перегруза.

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

📎 Подробнее в статье на Хабр: https://habr.com/ru/companies/spring_aio/articles/1011770/