前几天临近下班时刻，正在我摸鱼摸得开心的时候，突然发现来了几个生产上的异常的消息，点开一看pod重启，赶紧打开工作台，一看重启次数，我他妈傻了眼，都重启几十次，而且还在以几分钟一次的频率重复着，不过奇怪的是两个实例，另一台只重启了1次，看上去负载很不均衡，像是某个请求一直打到不断重启的实例上，学习的机会又来了，赶紧排查去吧
排查过程
由于我们这里用的是阿里云容器，所以很多命令没有权限，不过好在有一些可视化的界面，一样可以判断问题，首先看一下JVM和cpu使用率吧，
看这个内存占用示意图，明显是有什么大对象占用了太多的堆空间，然后一直gc不掉，反复GC,自然CPU也跟着上去了，然后触发自动重启机制，反复如此，接下来找tail一下gc日志，果然各种报各种Full GC (Allocation Failure，top一下cpu占用也飙升上去了，得了，搞一下崩溃时候的dump日志看一下吧，看看到底是哪些对象死活gc不掉吧，考虑最近没有上线，而且出现的这么有规律，应该是个定时任务触发的场景，不过这里却卡了壳，没有权限，找运维大佬给搞一下吧，下班了？结果第二天才给我dump日志（这个工作效率，比我还摸鱼），拿出来分析一下，找个mat分析工具，虽然我也看不懂，但是结果度娘，也能找个七七八八
首先映入眼帘的是这个线程明显有问题，
再看看大对象，也是这个线程（97.70%），就你了，点进去看看,
41万个从库里查出来的映射对象，应该就是他了
跟着调用链，一层层往下找，果然是个定时任务入口，不管了，先给他暂停了，（开着也卡在某个地方执行不过，不过先暂停观察一下），停掉之后果然pod不再重启。
找到问题了，那就通知一下定时任务的负责人吧，顺便看一下逻辑吧，果然和我猜想的差不多，某个品牌的商品查出来全部丢到内存里做了一些处理，在从线上库里count一下，没错了，几十万条记录，至于为什么一直是那一台出问题，应该是这个任务是分片的，按照分片规则，这个品牌一直落在这台机器上，所以一直卡在这里过不去了。
行，负责人去修改一下逻辑，我就继续摸鱼去吧
后记
1，上云之后，很多传统开发排查问题的方式可能已经切换了一些更加可视化的工具，虽然用着区别不大而且更直观，但是还是要加强新人的培训啊，不然百度一堆命令，用不了就很尴尬
2，运维的工具一定要全面呀，dump日志第二天才提供，这服务可是重启了一个晚上，报警消息可以吵得你睡不着（当然，这个服务没有那么重要，我正常休息，但是这个工作沟通很有问题）
3，我们这个问题，17点发现，18点就和运维同学要求dump日志了，但是直到第二天9点提供，加上我自己下载，用工具打开dump日志（日志很大，下载和解析都很耗时间），应该是12点多才发现问题根源，然后解决，估计要是在BAT我应该早就收拾东西滚蛋了，诚然有些东西不是我一个人的问题，但是这响应速度，着实慢点了，当天解决才是王道呀。
