При подготовке к недавно анонсированному подкасту набрёл на любопытный инструмент javaperf — MCP-сервер, предоставляющий ИИ-агентам средства диагностики производительности JVM, например, возможность управлять JDK Flight Recorder'ом и анализировать его записи 🔍

Всего в его арсенале на сегодня 15 тулов ⚒️

Сам я ещё не игрался, поэтому рекомендовать не готов, но выглядит, как минимум, интересно. Если кто-то уже пощупал, поделитесь, пожалуйста, впечатлениями 👇🏼

#инструменты

В Spring Айо вышла запись подкаста со мной и Алексеем Рагозиным, где мы говорили о современных подходах и инструментах для анализа и оптимизации производительности приложений на JVM, попутно раздавая спойлеры из наших курсов 🤭

Любопытно, что запись подкаста почти совпала с запуском курсов у самих ребят из Spring Айо — сейчас они набирают желающих на первый курс "Продвинутый Hibernate". Там можно будет глубоко погрузиться в реальные enterprise-кейсы и научиться их правильно "готовить" 🍳

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

Хорошо, что на JPoint для этого есть State of Java — отдельное выступление, полностью посвященное состоянию IT-ландшафта в релевантной нам части — в Java. Там можно как увидеть общий расклад, так и почерпнуть несколько интересных (порой забавных) инсайтов по узким темам 😉

Но чтобы представленные там результаты были адекватными, нужно охватить как можно больше респондентов, то есть, в том числе, нас с вами 👀

Для этого призываю вас пройти этот опрос от JUG.Ru, если вы причастны к разработке на Java: https://survey.jugru.org/soj2026 📋

Он не маленький (у меня ушло минут 20), но ради общего дела стоит это время потратить ✊

И даже если вы не собираетесь на ближайшую JPoint, всё равно имеет смысл заполнить, так как после конференции подробные результаты опроса будут разосланы всем его участникам 📩

На просторах нижнего интернета появились якобы материалы наших курсов с Алексеем Рагозиным, которые можно приобрести по весьма скромной цене, в том числе вскладчину 🧱

Пожалуйста, не ведитесь на эту дичь 🦆

Дело в том, что многие материалы давно прошедших тренингов можно получить и бесплатно; достаточно попросить их у нас напрямую. А материалы новейших занятий (например, по мониторингу и метрикам JVM) всё ещё находятся у нас в проработке, поэтому не были и не могли быть слиты ни в каком адекватном виде 💎

Будьте бдительны и помните про сыр 🪤


P.S. Но если там что-то годное, скиньте мне тоже позырить 🤭👀

Вопрос к знатокам #Java ❔

Что обозначает буква D, используемая в качестве префикса кастомных JVM-опций?
(типа -Dcom.myapp.someFlag=true)

Я нередко прошу наших инженеров (пользователей разрабатываемой платформы) добавить в файл vmoptions ту или иную кастомную опцию, поддерживаемую бизнес-логикой. Они добавляют и тут же приходят жаловаться, что приложение теперь вообще не стартует, потому что unrecognized VM option... 😵‍💫

Приходится объяснять, порой извиняясь, что все такие опции нужно предварять не только дефисом, но и префиксом D, так как они кастомные. Они добавляют, всё начинает работать, но потом в догонку всё же спрашивают, а что означает эта дурацкая неочевидная буква? 🧐

Тут я включаю режим JVM-эксперта и такой:

Эээ... Ммм.. Нуу... Это от слова... "Dopolnitelno" 🤓

Что есть в Java для работы с графами? 🕸

В предыдущем посте упоминался некий движок вычислений на основе графа ячеек (для электронных таблиц). По следам его создания хочу поделиться с вами списком отсмотренных мною opensource-библиотек на #Java для построения и обработки графов в памяти одной машины (т.е. графовые СУБД вне обзора) — вдруг кому пригодится 👀

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

Apache Commons Graphs — формально вроде как вариант, но надпись "Last Published: 17 June 2011" на главной странице говорит сама за себя 💀

JUNG (не путать с JUG) — тоже весьма пожилой проект, который едва ли стоит рассматривать всерьёз, однако жизнь там всё-таки теплется за счёт того, что на этом проекте обкатываются всякие экспериментальные алгоритмы и фичи, которые, если приживаются, могут переехать в... 👇🏼

Guava Graphs — компонент одной из самых популярных Java-библиотек в дикой природе. Имеет немало общего с JUNG за счёт одного и того же разработчика. Предоставляет базовый API для работы с графами и минимальный набор готовых алгоритмов; например, умеет детектировать циклы в направленных графах, но не умеет строить их пути. Содержит немало фишек для оптимизации потребляемых ресурсов, например, учёт связей ячейки с самой собой 🪺

FastGraph — не Java, а Kotlin, но какая разница? А разница в скорости обхода — по словам автора, эта библиотечка при обходе в глубину уделывает Guava в 68 раз и JGraphT в 44 раза. Проект очень молодой (меньше года) и пока без большой аудитории, но, как видите, весьма амбициозный 🚀

(самоделка) — в целом, тоже вариант, если чётко понимать, в чём плюсы и минусы такого решения. За основу можно взять готовые наброски из Интернета или, конечно же, попросить ИИ 🤖

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

Что из этого списка (и в каком виде) пригодилось мне в том проекте расскажу в следующем посте 📻

Обещанный следующий пост выйдет чуть позже, а пока — минутка техники безопасности ⛑

На тренинге по анализу дампов памяти я упоминаю про обфускацию конфиденциальных данных, которые могли попасть в дамп, если он снят с боевого приложения. В подробностях я этот момент не освещаю, хотя он весьма важен и может предотвратить серьёзные проблемы 🚫

Тем, для кого эта тема актуальна, теперь можно погрузиться в неё глубже — на Хабре вышла моя новая статья в блоге у ребят из Spring АйО 👇🏼

In-memory графы на Java — от теории к практике ⚒️

Готовые инструменты, да ещё open-source, — это, конечно, здорово. Но реальность обычно такова, что ни один из них не подходит на 100%. Так было и у меня на недавнем проекте. Поэтому пришлось собирать Франкенштейна:
1️⃣ Основная часть — на Guava Graphs
2️⃣ Отдельные упоротые специфичные кейсы — на JGraphT
3️⃣ Часто востребованные алгоритмы — (полу)самописные

Поясню такой выбор.

1️⃣ Guava Graphs оказалась хороша по трём причинам:
— максимально человеческий API: интуитивно понятный, почти без неожиданностей, хорошо документирован;
— гибкость построения графов: можно указать что надо, а что нет, и не "переплачивать" за ненужные фичи;
— стандартный набор прелестей: большое сообщество, много примеров, регулярные обновления.

2️⃣ Без JGraphT не удалось обойтись из-за того, что:
— нужно уметь экспортировать граф в другие форматы (GraphVizDot, GEXF) для отладки и верификации (см. приложенный скринкаст);
— нужно исполнять нетривиальные алгоритмы, которых нет в Guava, например, выявлять путь образования циклов.

В принципе, JGraphT покрывает и функционал Guava, поэтому можно было обойтись только им. Но помимо всяких полусубъективных факторов (типа удобства API и полноты документации) я не стал так делать потому, что JGraphT расценивает ребра графа как полноценные его сущности и потому создаёт в памяти объект под каждое ребро. А в Guava есть возможность этого не делать и выражать ребра атрибутами вершин 🔖

В нашем случае рёбра отражают однотипные отношения между ячейками таблиц, поэтому не нуждаются ни в лейблах, ни в других свойствах, а значит, не обязаны быть объектами, и это здорово экономит память. Судите сами — сейчас на одном из серверов заказчика расклад по графу такой:
• 516К вершин (ячеек)
• 1,1М рёбер (связей между ячейками)
• 500 Мб занимает граф в памяти 🪙

Согласитесь, это уже не мало. А если бы мы взяли JGraphT, и на каждое ребро создавали бы по объекту в куче, цифры были бы куда более жуткими... 🙈

3️⃣ Собственные алгоритмы потребовались в тех местах, где Guava ничего не предлагает, а конвертировать граф в формат JGraphT неоправданно дорого. Пример такого места — топологическая сортировка, которая нужна при каждом вычислении зависимых ячеек или при полном пересчёте всей таблицы 🔗

Изначально я взял для этого готовый алгоритм с GitHub. Он работал чётко, но выдаваемый им результат можно было исполнять только в один поток, а в наших масштабах этого оказалось недостаточно: таблица на 16,5К ячеек с формулами обсчитывалась 51 секунду. Тогда пришлось менять его на самописный алгоритм, пригодный для исполнения на множестве ядер 🪵

Конечно, слово самописный тут требует кавычек, ибо в 2026 году вряд ли имеет смысл писать такие вещи с нуля. Вместо этого основа реализации создавалась в обнимку с ИИ, а потом дорабатывалась напильником под (порой суровые) реалии целевого проекта 🪚

Заодно с этой доработкой открылись глаза пути оптимизации, позволяющие избегать многих вычислений, исход которых известен заранее. Благодаря этому, обсчёт той же массивной таблицы сократился с 51 сек. до 2 сек. 📉

—
Не скажу, что строение этого Франкенштейна меня полностью устраивает и не подлежит пересмотру. Вопросики к нему есть. В частности, одна строчка в build.gradle.kts, добавившая зависимость от JGraphT, увеличила размер финального артефакта приложения на 5+ Мб. Стоило ли оно того — вопрос ещё открытый... 🤔


P.S. Приложенный видосик — скринкаст из программы Gephi, о которой я рассказывал в Полке около года назад. На нём запечатлён "игрушечный" граф на 11К ячеек, полученный экспортом (через JGraphT) из нашего приложения не под нагрузкой. Он вам что-нибудь напоминает? 😉


P.P.S. Если вам интересно подробнее почитать про реализацию топологической сортировки, поставьте под этим постом "🤓".