采坑笔记

• Meta区Full GC导致服务无法响应

  现象：应用hung死，调用接口返回503，无法服务

  排查过程：现场dump了内存，GC记录，以及线程运行快照。首先看了GC发现是Full GC，但是不清楚是哪里发生的，看线程运行快照也没发现什么问题。于是在本地用HeapAnalysis分析，堆区没看出什么问题，大对象都是应该占用的；于是查看方法区，通过ClassLoader Analysis发现Fastjson相关的类较多，因此怀疑是class泄露，进一步通过MAT的OQL语法分析，发现是Fastjson在序列化Jetty容器的HttpServletRequest时，为了加快速度于是创建新的类时抛了异常，导致动态创建的类在方法区堆积从而引发Full GC，后续我们也向Fastjson提了相关bug

  解决方案：将序列化HttpServletRequest的代码移除

• 伪死循环导致CPU 100%

  现象：在有赞双11全链路压测期间，某个业务调用API，导致我们的应用CPU几乎接近100%

  排查过程：经过日志分析，发现该接口存在大量超时，但是从代码没看出特别有问题的地方。于是我们将接口在QA环境模拟调用，用VisualVM连上去，通过抽样器抽样CPU，发现某个方法消耗CPU较高，因此我们迅速定位到源码，发现这段代码主要是执行轮询任务是否完成，如果完成则调用完成回调，如果未完成继续放到队列。再结合之前的环境观察发现大量超时的任务被放到队列，导致任务被取出后，任务仍然是未完成状态，这样会将任务放回队列，这样其实构成了一个死循环

  解决方案：将主动轮询改为异步通知，我们这里是Dubbo调用，Dubbo调用返回的Future实际是一个FutureAdapter，可以获取到里面的ResponseFuture(DefaultFuture)，这个类型的Future支持设置Callback，任务完成时会通知到设置的回调