JUG.EKB #9

Существует масса способов найти причину медленной работы приложения, сданного в эксплуатацию. Например, можно аккуратно добавить логирование времени выполнения потенциально медленных методов. Или можно попробовать получить тред-дампы продакшена, проанализировать их и понять, на что программа тратит большую часть времени исполнения. Но есть ли какой-то более простой и доступный способ? На помощь нам могут прийти специализированные решения класса Application Performance Monitoring (APM). Как обещают вендоры, APM могут показать, что происходит внутри приложения, и помочь в поиске узких мест. Только попробовав, можно узнать, насколько эти заявления соответствуют действительности. На примере опыта использования решений APM в реальных проектах мы разберемся в их полезности и сравним с классическими инструментами — такими, как логи и тред-дампы.

В JDK 9 появится новый класс Flow. Настолько ли это нужно, если с версии 8 уже есть CompletableFuture? Разберёмся, почему не хватает уже доступных моделей многопоточности, и как похожие подходы реализованы за пределами стандартной библиотеки. Оказывается, реактивным может быть не только двигатель, но и Java-приложение в маленькой коробочке. 

И немного о самом Дмитрие: работает в компании BellSoft. Более 4 лет работал в Oracle в команде Java SE Performance. В настоящее время занимается оптимизацией Java для процессоров семейства ARMv8. Предыдущий многолетний опыт с Java продемонстрировал, что в проблемы производительности упираются приложения любых масштабов и на любом оборудовании.​