线上服务异常的定位、处理与优化的探索 - 第五章 实战操作
线上服务紧急热部署
适用场景
- 线上服务器未开启、不支持、不允许热部署应用。
- 甲方IT管理制度严谨，发版需提前申请。
- 项目组发版出现纰漏，为减少项目影响，需要动态替换Class完成一部分函数功能的逻辑变更。
- 不适用于Class增加方法、字段、改变引用等，原因请查看3.1.4章节。
模拟场景
某费控项目资金模块定制开发了导出网银付款文件功能，格式为银行前置机指定格式。由于资金业务涉密安全等级较高，甲方要求此功能需对接已有的前沿信安数据安全系统，保证导出的网银付款文件只能在安装有加密客户端的电脑上打开。
某日甲方出纳接银行通知对网银文件格式做调整，开发人员本地完成代码修改。按照甲方要求每周只能发版一次，发版后测试发现导出的网银文件未加密，经开发人员跟踪核实为：开发机未安装加密客户端，为方便本地测试将加密代码逻辑注释，打包程序时没有放开此段代码。
解决方案
通过svn记录检查，发现加密文件部分的代码已被注释，确定问题原因。主要使用Arthas进行热部署替换Class文件，达到不停机修改函数逻辑的目标。
第一步：启动Arthas，挂载应用进程
java -jar arthas-boot.jar
第二步：使用Arthas的jad命令反编译需要处理的Classs，并为其指定保存目录。
jad --source-only com.epoch.customizeproject.xx.CalssXX > /tempCode/CalssXX.java
第三步：使用Arthas的sc命令查找存在问题代码的Class的ClassLoader。
sc -d com.epoch.customizeproject.xx.CalssXX | grep classLoaderHash
第四步：使用Linux的vim编辑第二步中jad反编译后的源码，增加需要的代码、逻辑。
vim /tempCode/CalssXX.java
第五步：使用Arthas的mc命令编译上一步中修改好的代码，并且通过-c参数指定ClassLoader(第三步中sc查询到的ClassLoader)。
mc -c 1bce5c85 /tempCode/CalssXX.java -d /tempCode/CalssXX.class
第六步：使用Arthas的redefine命令重新加载、替换新编译好的Class文件
第七步：验证修改结果
注意，以上步骤中，第五步使用mc命令有可能失败。如果编译失败可以在本地编译好.class文件，再上传到服务器。
线上服务CPU100%快速定位
适用场景
- 线上服务器CPU100%超卖，长时间负载过高，测试环境没有出现，需要线上定位问题代码点。
- 此类情况应优先检查JVM的堆内存、永久代内存，以及观察GC频率、时间是否存在非正常的现象。
模拟场景
某费控项目投产一段时间后出现应用卡顿，请求超时等现象，重启后短暂恢复正常又复现卡顿。经检查JVM参数、GC次数与时间、堆内存等均正常。Top进程发现CPU始终超过100%，有超卖嫌疑。通过jstack追踪线程堆栈信息，准确定位具体问题代码的位置。
解决方案
已知服务器CPU100%超卖，一段时间或长时间内无下明显降现象，同时确定JVM调优的参数合理，GC次数和时间。排查代码是否存在线程死循环、死锁等现象。
第一步：找到最耗CPU的进程，记录进程的PID值
# top -c 查看进程运行信息列表
键入P(大写)，进程按照CPU使用率排序
第二步：找到最耗CPU的线程，记录线程ID
# top -Hp <pid> 查看指定进程下的线程运行信息列表
键入P(大写)，线程按照CPU使用率排序
主要指标看两项：
CPU% ：该线程的CPU使用率
TIME+：改线程的活动时间，数值表示线程存活时间
第三步：将上一步的线程PID转化为16进制
# printf “%x” <线程ID> 这一步同样也可以使用计算器计算
转为16进制的原因是堆栈里线程id使用16进制表示
第四步：找到线程堆栈信息，定位具体超卖CPU的线程应用代码
# jstack <pid>|grep <'线程ID'> -C5 --color
如上图，通过追踪线程的堆栈信息找到消耗CPU高的线程：Thread-86。根据线程名称可知该线程是一个业务功能的线程，并且线程的状态是：BLOCKED阻塞状态。继续观察线程堆栈信息可以发现问题代码所在目录：com.epoch.xx.ClassXX.methodXX。
第七步：修复与热更新
通过以上追踪得到问题的代码位置，在本地分析和修改代码后可以使用5.1章节的Arthas进行热替换Class达到修复问题，具体使用请查阅5.1章节。
