重回全面发展亲自操刀

项目场景：

        今年工作变动，优化后在一家做国有项目的私人公司安顿下来了。公司环境不如以前，但是好在瑞欣依然可以每天方便的买到。人文氛围挺好，就是工时感觉有点紧，可能长期从事产品迭代开发，一下子转变做项目有点不能适应。另外，之前公司都取消了的福利这个新家还有，3大补贴、加班餐报销、零食管够，选择还多样，直接让行政点加班餐都行。
       言归正传，今天遇到的是一个springboot服务搞CPU占用，持续在60%-%80，偶尔超过100%，这个服务都是数据采集工作，配合自动任务周期性执行。

---

问题描述

       这个服务持续的高CPU占用，导致达梦数据库也高CPU占用，直接干到了700%多，且基本不难降下来。导致另一个下游业务的udpate执行超时，而且是根据id执行update都超时。

---

原因分析：

        分析原因就是达梦数据库的资源被耗尽，没有多余资源响应。因为业务的问题，是循环里执行，可能每次update有几条不报错，但是中途有一条报错了就导致事务回滚了，最终是都没有成功。

原因分析过程有点坎坷，好多年没有直接面对运维方面的问题了。以前公司有运维顶着，很多时候都到不了研发这块。原因也基本运维就给定位了，到研发只是验证。

1. 首先是觉得达梦没这么脆弱，所以就先去分析查看有没有sql阻塞、锁等。

--  查询达梦数据库信息
SELECT * FROM V$VERSION;
-- 查询当前死锁信息
SELECT lc.lmode, lc.table_id, lc.blocked, vtw.id AS trx_id, vs.sess_id, vs.sql_text, vs.appname, vs.clnt_ip 
FROM v$lock lc
LEFT JOIN v$trxwait vtw ON (lc.trx_id = vtw.id)
LEFT JOIN v$trx vt ON (vtw.id = vt.id) 
LEFT JOIN v$sessions vs ON (vt.sess_id = vs.sess_id)
WHERE vs.sql_text IS NOT NULL;-- 查看涉及死锁的SESS_ID
SELECT VTW.ID AS TRX_ID, VS.SESS_ID, VS.SQL_TEXT, VS.APPNAME, VS.CLNT_IP 
FROM V$TRXWAIT VTW 
LEFT JOIN V$TRX VT ON(VTW.ID = VT.ID) 
LEFT JOIN V$SESSIONS VS ON(VT.SESS_ID = VS.SESS_ID);-- 查询正在执行的sql
select * from v$sessions where state = 'ACTIVE';    -- 解决死锁信息，参数为sess_id
-- sp_close_session(1111);

结果发现也就是执行时间长点，并没有死锁阻塞之类的。

1. 然后，想着达梦咱也不熟悉（几乎没有用过，要说用就是上次来这家公司的二面-上机实现。以前公司大家一直都看不上达梦），所以就想着springboot高CPU长时间占用不正常，不如就先解决它把。

   这次是把以前的jdk自带的分析套路先用上，见历史博文，jdk自带分析命令定位问题
   然后，导出一份GC采样的日志，在收藏的工具网站上先分析一波。
   这里让我惊讶的是服务器居然没有自己安装jdk，而是使用的自带的，还是仅仅是JRE，都不带JDK的一些分析工具，这是什么神操作啊。
   
   
   
   确定暂时还没有死锁之类，也就是GC次数有点多。

2. 最后，就想着收藏Arthas好久了，今天不妨就用下
   安装之类的就不说了，直接去Arthas官方在线文档学习
   想到既然用jdk自带的分析工具导出的GC采样日志分析有那么多的WAIT、TIMED_WAITING，那就直接看线程吧。
   安装完成启动Arthas，选择springboot服务对应的pid，就可以开始表演了。有一点要说的就是，这个可以与项目同在，如果上服务器不方便，都可以直接把Arthas的终端暴露给外网。

java -jar arthas-boot.jar --target-ip 你能访问到的ip --http-port 8563 --telnet-port 3658

看效果

回归主题，上线程分析。


 很快就定位到是业务代码的那一行了，业务代码就不给看了，自己玩去。

---

解决方案：

       上面已经定位到业务代码了，自己去调整优化逻辑，是一个资深代码人应有的素养。
       就写到这里，希望能帮到大家，uping！