Evgeny Suleimanov — The Anatomy of a Hang: When the Thread Pool Is Full and the CPU Is Almost Empty

Подробнее о Java-конференциях: — весной — JPoint: https://jrg.su/gTrwHx — осенью — Joker: https://jrg.su/h7yvG4 — — Скачать презентацию с сайта — https://jrg.su/wn9wWQ Почему сервис «умирает», когда по CPU все спокойно, в логах почти нет ошибок, а память в порядке? Разберем типовой Spring MVC-сервис в универсальной трехзвенной архитектуре (Transport → Business → Data/Integration) и пройдем путь стандартного запроса «под капотом»: Tomcat выдает рабочий поток, Hikari — соединение к БД, затем выполняется исходящий HTTP-вызов, где поток продолжает заниматься ожиданием. На живом сценарии покажем, как рост latency у внешней зависимости превращается в рост конкурентности, как копится очередь в пулах и почему именно поэтому CPU часто не растет, хотя пользователю уже плохо. Затем построим минимальный, но достаточный набор наблюдаемости по методологиям RED и USE и научимся отличать «симптомы» (p95/p99/RPS) от причины (saturation/queueing в потоках, коннектах или HTTP-клиенте). Дадим практичный плейбук диагностики: куда смотреть первым, вторым, третьим — вместо «пересобрать и перезапустить». После этого разберем исправления, которые работают в стандартном Spring MVC: корректные таймауты (connect/read/connection-request), ограничение параллелизма на внешние вызовы (bulkhead), выравнивание лимитов между Tomcat/Hikari/HTTP-клиентом, fail-fast и graceful деградация. Отдельно обсудим алерты: почему важно ловить saturation и рост очередей раньше, чем пользователи начнут жаловаться, и какие пороги ставить. В конце вы получите чек-лист «чтобы больше не повторилось» и понимание, как объяснить команде, почему «CPU свободен, но сервис не живой».