抽丝剥茧：线上突发多次Full GC，终于解决了.....

浅浅的花香味﹌ 2023-10-13 23:37 18阅读 0赞

今天分享一个项目jvm多次fgc的整个排查流程

上班后不久运维突然通知我们组，有一个应用在短时间内多次fgc，即将处于挂掉的状态。我登录skywalking，观察应用整体状况

> 交代下背景，该项目属于一个整合消息的项目，可以称之为消息中心，负责我们应用中的所有的推送，短信及公众号推送，消息都是通过业务方面投递到kakfa消费的方式，所以feign或者http调用的外部调用几乎没有

首先通过cpm(call per minute/每分钟服务被调用数)观察服务整体情况

![图片][df6bbe12e10f7e62ceee939cf1a688ec.png]

我们可以看到在8.到8.07分这段时间有一个波峰，询问产品得知是有医院开启了抢购药品的业务（某些专科医院比如说皮肤病医院，会在一些特定时段，每天开启限制数量的药品抢购，这个抢购属于比较火爆的业务），所以这个流量峰值是正常的。流量一大，消息队列中的消息数量立刻就上来了：

![图片][abe6379f4bf61cf5f4cbf6677ed0c18b.png]

那么我第一个想法，有没有可能是kafka消息堆积呢？应用的处理能力跟不上，导致消息大量堆积，带着这个问题，我去看一下skywalking监控的消费速度，打开Endpoint监控，观察`slow endpoints`:

![图片][236818d0efb75627bb151867923cb58a.png]

可以看到最慢的kafka消费速率在234ms，对于一个需要调用第三方外部接口完成业务的消费来说，这个速度不可以说慢，甚至还可以说有点小快。没关系，只要是性能问题，那么总是有迹可循。我点开最高负载的服务实例查看gc次数：

![图片][a5ab7b2c041a04d47d2d574bd27d9989.png]

可以看到在8.6分流量最高的这段时间fgc的次数达到了70次，这确实离谱，按照我的经验一个健康的应用甚至不应该一天fgc超过10次，这一分钟超过70次居然还没当场挂掉，简直可以称之为坚挺。我们再看看jvm线程数量：

![图片][ac44987f11ed26ab7d6b779ce77055b3.png]

waiting的线程在流量冲入后大量增加，几乎导致了oom，在流量波峰过去后线程数量又慢慢归于平稳

所以观察结论是大量被创建的线程导致的内存飙高，接下来就是需要观察线程快照找出罪魁祸首了

将线程堆栈导入`fastthread.io/`分析堆栈，我们查看线程数最多的相同线程组。

![图片][1d52838c5804b21b6f2a8b84450e7e95.png]

这个明显是OkHttp使用不当导致的OkHttp链接池的异常增多，我第一个反应是联想到我们的fegin调用，feign底层可能使用了OkHttp导致OKHttp链接池创建异常。

下一秒就把自己的推测推翻了，因为首先feign不可能有这么明显的问题，第二是上图中的“`OkHttp api.tpns.tencent.com`”我们并不是通过feign调用，而是直接通过sdk调用的（这个是tpns，腾讯的app推送）

那么，有没有可能是sdk的问题呢？

我们是这么调用腾讯的推送的：

//每次推送都会调用这段代码 
    XingeApp xingeApp = new XingeApp.Builder()
                    .appId(androidAppId)
                    .secretKey(androidSecret)
                    .domainUrl(PREFIXURL)
                    .build();
     return xingeApp.pushApp(pushAppRequest);

点开build方法发现是这样的

public XingeApp build() {
                if (appId == null || secretKey == null) {
                    throw new IllegalArgumentException("Please set appId and secret key.");
                }
    
                return new XingeApp(this);
            }
    
    
    private XingeApp(Builder builder){
            if(builder.domainUrl != null){
                restapiV3.setDomainUrl(builder.domainUrl);
            }
    
            this.accessId = builder.appId;
            this.secretKey = builder.secretKey;
            this.isSignAuth = builder.useSignAuth;
    
            client = new OkHttpClient.Builder()
                    .proxy(builder.proxy)
                    .connectTimeout(builder.connectTimeOut, TimeUnit.SECONDS)//设置连接超时时间
                    .readTimeout(builder.readTimeOut, TimeUnit.SECONDS)//设置读取超时时间
                    .build();
     }

可以看到这个`new XingeApp(this)`到后面是初始化了一个`OkHttpClient`的客户端，点进`OkHttpClient`的Builder方法是这样的：

public Builder() {
          dispatcher = new Dispatcher();
          protocols = DEFAULT_PROTOCOLS;
          connectionSpecs = DEFAULT_CONNECTION_SPECS;
          eventListenerFactory = EventListener.factory(EventListener.NONE);
          proxySelector = ProxySelector.getDefault();
          cookieJar = CookieJar.NO_COOKIES;
          socketFactory = SocketFactory.getDefault();
          hostnameVerifier = OkHostnameVerifier.INSTANCE;
          certificatePinner = CertificatePinner.DEFAULT;
          proxyAuthenticator = Authenticator.NONE;
          authenticator = Authenticator.NONE;
        //可以看到罪魁祸首就在这里
          connectionPool = new ConnectionPool();
          dns = Dns.SYSTEM;
          followSslRedirects = true;
          followRedirects = true;
          retryOnConnectionFailure = true;
          connectTimeout = 10_000;
          readTimeout = 10_000;
          writeTimeout = 10_000;
          pingInterval = 0;
        }

于是真相大白，原来`ConnectionPool`对象是在这里new出来的

可以看到，每次new一个XingeApp就会new一个`OkHttpClient`，顺便new一个`ConnectionPool`。而每次推送的都会new一个XingeApp导致内存中有大量的`ConnectionPool`对象存在，直到堆满了进行一次fgc，又能回收掉很大部分的内存，因为大部分`ConnectionPool`在推送完成后以后都是没用的垃圾内存，推送又是海量的，所以导致内存一直满一直fgc但是又能一直抗住（因为每次fgc可以gc掉大部分内存）

那么怎么解决呢？

最简单的解决方式就是减少`XingeApp`实例的对象，因为没必要每次推送都去new一个对象出来，按理说只需要一个实例就够了，`OkHttpConnectionPool`也只需要一个，链接的复用和摧毁完全交给OkHttp就行。所以修改如下：

//伪代码 双重校验锁
    public static XingeApp getAndroidXingeAppInstance(){
            if (androidXingeAppInstance !=null){
                return androidXingeAppInstance;
            }
            synchronized (TpnsPushLogicImpl.class) {
                if (androidXingeAppInstance !=null) {
                    return androidXingeAppInstance;
                }
                androidXingeAppInstance = new XingeApp.Builder()
                        .appId(staticAndroidAppId)
                        .secretKey(staticAndroidSecret)
                        .domainUrl(PREFIXURL)
                        .build();
                return androidXingeAppInstance;
            }
    }
    
    public void pushMessage(){
         XingeApp xingeApp = getAndroidXingeAppInstance();
        xingeApp.pushMessage;
    }

升级后在推送高峰期重新查看skywalking仪表板：

![图片][e43815ba95bd9fcaa30932089eb81c22.png]

![图片][6cf5c564e9b4451ec0503c7c8770f5ee.png]

可以明显看到线程数量降下来了，gc也只有ygc，说明很健康

重新打出该应用的线程快照，导入线程快照分析工具查看`okHttpConnectionPool`线程

![图片][558d6c56b73c90b9893c4839afecda31.png]

可以看到现在应用内只有一条`OkHttpConnection`的线程，改造成功

[df6bbe12e10f7e62ceee939cf1a688ec.png]: https://img-blog.csdnimg.cn/img_convert/df6bbe12e10f7e62ceee939cf1a688ec.png
[abe6379f4bf61cf5f4cbf6677ed0c18b.png]: https://img-blog.csdnimg.cn/img_convert/abe6379f4bf61cf5f4cbf6677ed0c18b.png
[236818d0efb75627bb151867923cb58a.png]: https://img-blog.csdnimg.cn/img_convert/236818d0efb75627bb151867923cb58a.png
[a5ab7b2c041a04d47d2d574bd27d9989.png]: https://img-blog.csdnimg.cn/img_convert/a5ab7b2c041a04d47d2d574bd27d9989.png
[ac44987f11ed26ab7d6b779ce77055b3.png]: https://img-blog.csdnimg.cn/img_convert/ac44987f11ed26ab7d6b779ce77055b3.png
[1d52838c5804b21b6f2a8b84450e7e95.png]: https://img-blog.csdnimg.cn/img_convert/1d52838c5804b21b6f2a8b84450e7e95.png
[e43815ba95bd9fcaa30932089eb81c22.png]: https://img-blog.csdnimg.cn/img_convert/e43815ba95bd9fcaa30932089eb81c22.png
[6cf5c564e9b4451ec0503c7c8770f5ee.png]: https://img-blog.csdnimg.cn/img_convert/6cf5c564e9b4451ec0503c7c8770f5ee.png
[558d6c56b73c90b9893c4839afecda31.png]: https://img-blog.csdnimg.cn/img_convert/558d6c56b73c90b9893c4839afecda31.png