前言
不好啦❗ 天塌了❗ 系统崩了❗ 服务又又又又掉线了❗ 有人要倒霉了❗
快看啊，一个上线3年的业务，突然就崩了
生产问题群爆炸了
我的心里活动一："这个服务现在是交给我负责，我得快点排查清楚，最好汇报，最好能把责任推出去"
我的心里活动二："太好了😀太好了😀终于给我碰上了，这个问题可很少发生啊，又积累血琳琳的生产一个问题"
不想看废话的直接看【解决过程和方案】 吧
排查过程
先看pinponint监控 一年看出tomcat线程耗尽 直接百分百锁定服务掉线原因
进一步看这个爬坡过程，发现持续爬坡接近1个小时，是什么样的接口导致他爬坡1小时呢！！！
再看掉线前几分钟日志，发现tomcat只有几个线程在处理web请求，其他线程未曾在日志中发现，
这样一来进一步确认了上一步监控看到的现象。
所以 我们是不是找到某个线程最后处理请求是那个接口是不是就可以确认，是那个接口出的问题呢。
看这个211线程 最后处理请求是在这个时间，处理这个接口，之后这个线程就再也未曾出来过，
接着又看了几个线程 最后一次请求也是这个接口
所以基本已经定位出那个接口出的问题
上代码 结合日志加代码， 发现finally块代码始终未执行
那么 直接定位出 阻塞在了红框内