1.前言背景线上代码经常会出现CPU占用过高的情况，按以往经验我会使用top指令，进一步借助于jstack去查看具体信息从而进行问题排查，但基本上都逃不过需要重新发包的局面，即使是一个增量包，应用也需要短暂停启。后来运维大兄弟让我试一下Arthas，说是可以进行代码的热更新操作，正好来试一下。关于Arthas的安装与基础使用可以参考我这两篇：Arthas安装与监听SpringBoot应用Arthas基础指令使用说明环境JDK1.8 SPringBoot 2.2.2Arthas Linux 测试代码：
思路2.thread -b 查看是否有阻塞线程thread -b, 找出当前阻塞其他线程的线程，执行完之后并未发现，说明该线程并非一直阻塞，一直执行的3.thread 查看占用最高的线程 当thread之后不跟参数时，显示当前全部线程信息，我觉得 thread -n 10，展示前10应该就够用，可根据实际需要自己决定。下图可以很直观的看出，我们的应用瞬间占用了77%的CPU(这里我是发起请求瞬间，通过thread查看的，所以比较直观，生产环境应该只有阻塞，死锁这种状态才会比较直观)4.thread id 查看具体信息在上一步基础上，我们进一步查看，thread 15（因为上面的ID=15）他的大致意思就是：线程在等待一个条件从而继续执行，可以看到方法是在执行LinkedBlockingQueue.take方法时候，查看这个方法的API提示如下：其中：AtomicInteger是保证高并发情况下的原子性，ReentrantLock标识可重入锁，都是JUC包下需要了解的这里不赘述，需要的百度了解下。这段代码关键点就在于：notEmpty.await()，从队列中消费数据，当队列为空是，线程阻塞，所以我们大致知道现在出现的问题是线程阻塞，但是还是不知道具体哪行代码的问题。如果能够明确知道这次更改了哪些代码，可以直接执行步骤6，不知道的话可以通过步骤5来定位问题。5.watch 查看哪个Controller执行了代码这个脚本可以检测一切通过DispatcherServlet匹配Handler的方法，也就是进入Controller的请求，如下：找到了对应的代码之后，我们来进一步观察异常信息，这里可能会有一个问题：就是我明明能通过日志去查看错误信息，为什么还需要这么繁琐的去操作。我的业务场景是：日志还是非常大的，刚捞到就被刷过去了，这时候定位日志不是很好操作，当然想捞下来日志肯定也是可以的，也很直观，我一般也都是去查看日志进行问题定位，这里也是提供一个思路。6.watch 该方法异常信息如上，错误很直观的提示了出来，下面就可以修复解决了，这里我们也可以通过trace指令，查看执行时长：返回信息如下，也可以看到错误信息，和每个方法执行的时长7.jad 反编译热更新在上面知道问题之后，我们就来定位问题就好了，命令：jad 类全路径 方法名此时代码就被反编译了，为了能够更改，所以我们需要输出为java文件指令：jad com.arthas.controller.OrderController > /tmp/OrderController.java即：jad 类全路径 方法名 > 存储路径/存储名称然后到tmp路径下vi修改java文件即可，修改完成之后，查看对应的classloader为编译做准备但是这里编译出错了，官方提示：所以我们本地编译好class文件，上传上去是一样的编译前调用更新前代码更新后代码编译指令编译后调用三次可以发现时间从6734.666529ms变成3ms左右，说明热更新的代码生效了8.profile 绘制火焰图做后续分析
