抽丝剥茧：线上突发多次Full GC，终于解决了..... | 芋道源码 —

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7169543360632324126 「魔性的茶叶」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

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

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

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

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

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

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

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

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

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

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

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

这个明显是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仪表板：

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

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

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