一种使用字节码增强技术检测线程阻塞的实现方式

在过去处理过的服务故障中，有一类比较典型的场景是业务线程被阻塞（造成阻塞的原因也是多种多样），慢慢导致业务线程池中的全部线程被阻塞，最终造成无法对外提供服务（现象则是CPU、Load、内存等指标都比较低，请求接口后响应超时或者没有响应）。,响应时间是接口监控的黄金指标之一：假设接口接收请求的时间是t1，接口处理完请求，响应的时间是t2，则接口响应时间是：t2-t1，将响应时间指标接入监控报警系统，当响应时间大于阈值的时候则进行报警；但是在线程被阻塞的情况下，由于接口一直没有返回，响应时间也就无法监控到。
阻塞的线程往往是业务线程，这些业务线程可能是：,如果我们能够在这些业务线程执行的必经路径上进行拦截，那么就能记录下线程开始执行的时间，同时启动定时器不断检查线程已执行的时间，当已执行时间大于设定的阈值则打印出线程栈进行报警；当线程正常返回则删除该线程记录，所以需要解决的主要是两个问题：,通过问题分析，可以确定主要需要解决以下两个问题,该模块主要做三件事:,服务中几种常见业务线程：,该方案实现简单，但是对于业务侵入性比较强，侵入性强意味着业务在意识不到问题的时候，没有改变的动力。,基于jvm-sandbox实现自定义module，实现思路如下：,通过在应用启动参数中增加javaagent=jvm-sandbox agent的方式来使用，相比较方案一业务应用不需要改动任何代码，也不需要对已有封装的框架进行修改，缺点是jvm-sandbox需要提前部署到每个应用的机器上，会给运维带来工作量，个人认为这种方案是最稳定的。,为了避免方案二中运维工作，一种思路是以jar包的形式提供给业务方使用，业务方引入jar包就可以了
，主要面临两个问题需要解决。,一种方式是通过spring boot starter的方式，比如
arthas-spring-boot-starter；
一种是根据spring容器初始化流程，选择某个切入点，比如通过实现ApplicationListener接口，监听spring初始化完成的ApplicationEvent来实现。,初始化的核心逻辑如下：,上面代码总体逻辑是没有问题的，需要考虑的细节是上面代码在不同类加载器体系下的兼容问题。,,,pandora类加载器关系,,idea应用类加载器关系,从目前的三种方案来说，个人比较倾向方案二。,bytebuddy
jvm-sandbox
arthas