你们没发现我很近的原创原创少了很多嘛，一是很近花了很多时间做视频，本来我写文章就是利用周末的两天时间，但是现在基本上两天都要拍摄剪辑了，尽管请了小伙伴做字幕，还是得耗费大量时间在拍摄和剪辑上。
所以我只能利用工作日熬一下才能写出来了，这周因为要发布，本来是没排期写文章的，你们也看到了我发了两个视频嘛。
但是今天我一发布就吓尿了….
事情是这样的…..
我和小组伙伴很近负责的系统今天上线了，因为涉及到的业务尤其多所以选择白天发布，怕出问题找不到对应的负责人。
看到3点25那个fullgc没，我发布上去一分钟不到就疯狂GC，我当时就吓尿了，马上点了回滚按钮。
而且我发现cpu几乎在我发布的瞬间，直接打到了峰值。
所幸只发布了一台，我紧张的望向了四面，发现四面的同事没注重到我，我顿时没那么紧张了，拿起桌上用剩下的纸巾搽掉了我鬓角马上留下的汗水。
我其实已经知道大概是什么问题了，无非就是死循环，或者大对象什么的。
但是我还是想找个人承担这个锅。
我马上找到三歪，我问他：你刚才是不是点过我的系统？
他说：对啊，我刚才点了，我本来就经常使用你的系统，咋了？（刚好正中下怀嘻嘻）
我说过多少次啊，叫你不要乱点，这已经不是第一次了，现在把我的系统点坏了，怎么办？都怪你。
他：委屈巴巴一副要哭的样子。
我：诶，算了算了，下次注重哈，我去排查下什么情况，看看你点坏了哪里。
他：丙哥真好，丙哥真棒，丙哥我爱你。
总算是找到背锅侠了，我就开始排查问题吧。
注：以下代码都是伪代码，为了还原排查过程
一般CPU100%疯狂GC，都是死循环的锅，那怎么排查呢？
先进服务器，用top-c命令找出当前进程的运行列表
按一下P可以按照CPU使用率进行排序
显示Java进程PID为2609的java进程消耗很高
然后我们需要根据PID查出CPU里面消耗很高的进程
使用命令top-Hp2609找出这个进程下面的线程，继续按P排序
可以看到2854CPU消耗很高
image-
2854是十进制的，我们需要转换为十六进制，转换结果：b26
接下来就需要导出我们的进程快照了，看看这个线程做了啥
再用grep查看一下线程在文件里做了啥
我这里就随便定位一个，基本上这样查都可以定位到你死循环的那个类，那一行，这里你还可以在jstack出来的文件中看到很多熟悉的名词，至于是啥，你们留言告诉我好了，就当是个课后作业了。
我写了个伪代码，看看当时我为啥会写出这个死循环，对了当时我上线的是预发，也是后台系统非线上的，虽然都是自己在玩，但是大家还是要引以为戒。
我当时写了个代码预备去查出数据库的数据，订正下日期，仔细看没问题，但是我忘了数据库的偏移值自己去计算了，因为以前都是框架，自己临时写的就没管。
导致每次都能查出10个数据，在很后判定的时候就一直true不退出了，其实很后会退出，但是得循环很多次。
我这里退出的逻辑比较取巧，就是想着很后一次查询肯定跟我的页数不一样，那就是很后一页了，那我就处理完退出。
结果没想到也是个坑了。
大家写的时候也要注重很多小坑，这次我就给个demo顺便带大家温习一下线上故障的排查，下次我可能搞点内存泄露，集群宕机什么的故障，这样就有素材了呀。
假如真出问题，第一时间找个三歪这样的背锅侠，排查过程自己去电脑上操作一下，很近有点忙，预备写个分布式锁的文章，如何？
文章地址：https://www.tianxianmao.com/article/online/9450.html
