Какой у вас есть опыт профилирования Java-приложений?

Да ты посмотри, какие у нас тут инструменты для разборок с кодом! Прямо как в арсенале у слесаря-сантехника, только вместо разводных ключей — профилировщики, чтобы твоё приложение не текло и не тормозило, как старый кран.

Чем будем вооружаться и для каких косяков:

1. VisualVM / JDK Mission Control: Это как базовый мультиметр. Включил — и сразу видно, не пожирает ли твоя куча (heap) всю память, не грузит ли какой-то поток процессор на 150%, и вообще, что там творится под капотом.

   • Например: Смотришь на график Old Gen — если он растёт, как на дрожжах, и не падает после GC, значит, где-то классическая утечка, блядь. Кто-то забыл ссылки почистить.

2. YourKit / JProfiler: А это уже продвинутая диагностика, почти томограф для кода. Тут можно копнуть глубоко.

   • Смотрим, кто мусорит: Можно найти метод, который плодит объекты, как сумасшедший. Вот смотри, может выявить такую хрень:

     // Профилировщик тебе тыкнет пальцем: "Смотри, уёбок, этот метод каждый раз новую строку из кусков лепит!"
     public String createLogLine(User user, Action action) {
     return new String("User: " + user.getId() + " did: " + action.getName()); // Да тут же сплошной new String, ёпта!
     }

   • Ловим долгие запросы: Может показать, что твой Hibernate вместо одного умного запроса делает двадцать тупых (это та самая проблема N+1, которая всех бесит).
   • Замеряем, кто тормозит: Покажет, какие методы проводят в процессоре больше всего времени.

3. Async-Profiler: А это, сука, мастхэв для прода! Он такой легковесный, что его можно на живом сервере запустить, и он нарисует тебе Flame Graph (огненный граф). Выглядит, как цветной кампекс, но по нему сразу видно — вот эта толстая полоска в самом низу и есть твой "горячий" метод, который CPU и жрёт. Красота, в рот меня чих-пых!

Как обычно эту магию проводят, по шагам:

1. Когда приложение жрёт память и не отдаёт — снимаешь дамп кучи (heap dump), как улику с места преступления.
2. Открываешь этот дамп и смотришь гистограмму объектов. Ищешь, каких дохуя больше всего: char[], String, или твоих собственных VeryImportantDataDTO — вот они, главные подозреваемые.
3. Читаешь логи сборщика мусора (GC log). Если там паузы по 5 секунд — это пиздец, пользователи уже разбежались.
4. Запускаешь CPU-профилирование и ищешь не того, кто вызывается чаще всего, а того, кто суммарно работает дольше всех. Часто это оказывается какая-нибудь невинная с виду функция сравнения строк в глубине алгоритма.
5. Находишь причину — чинишь код (добавляешь кэш, переписываешь ебанутый цикл, закрываешь наконец-то соединения с базой). А потом обязательно проверяешь, что стало лучше. А то бывает — одно починил, другое сломал, ёперный театр!