Java服务刚启动时，一小波接口超时排查全过程_Java教程

原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。

简介

我们组有一个流量较大的Java服务，每次发代码时，服务都会有一小波接口超时，之前简单分析过，发现这些超时的case仅发生在服务刚启动时，少量请求会耗时好几秒，但之后又马上恢复正常。

问题发生

如下，是我们服务的一次上线，可以看到，上线期间(21:10左右)会有一小波499超时。
Java服务刚启动时，一小波接口超时排查全过程

而从我们全链路日志平台查看这些超时的调用，会发现外部网络操作(如：rpc调用、查询数据库等)耗时不高，所以耗时来源于执行java代码而非外部调用。

但为啥就刚启动完成那会比较耗时，之后又正常了呢，有点经验的话，肯定会想到这里面估计发生了什么隐式操作，那Java代码执行时会有哪些隐式操作可能导致耗时高呢？
我想到了如下几种情况：

懒加载操作，如连接池初始化、缓存加载？

经过检查，发现这些都已在启动时加载，不会延迟到请求时。

发生了GC？

经过检查，启动时GC正常，耗时不高。

JIT即时编译功能导致？

java代码默认是解释执行的，当某些代码被多次执行后，会被JIT编译成原生指令执行，执行性能相应提升，但我通过JVM参数-Xint关闭了JIT后，发现问题依然存在，故排除了此原因。

执行过程中有锁？

经过检查代码，未发现锁的存在。

操作系统相关隐式操作，上下文切换、缺页中断、文件io慢？

经初步检查，CPU、内存、磁盘使用率都正常，这部分深入排查比较费力，且有权限限制，暂先跳过。

那会是什么原因导致的？

问题排查

暂时没啥头绪，我打算先用arthas的profile命令，收集一些CPU火焰图看看。

由于超时仅发生在刚启动完成后的部分请求，之后又恢复正常，故我计划在启动完成后开始收集火焰图，每次收集10s的火焰图，收集3次，然后对比前后的火焰图，看看它们有什么不同，收集脚本如下：

function flamegraph_sample(){
    # 不断检测服务直到它启动完成
    while sleep 1; do curl -sS --connect-timeout 3 -m3 http://127.0.0.1:8080/health | grep ok && break; done
    pid=`pgrep -n java`
    for i in {1..3}; do
        java -jar arthas-boot.jar -c "profiler start --alluser" "$pid";
        sleep 10s;
        java -jar arthas-boot.jar -c "profiler stop --file /tmp/flamegraph_cpu_%t.html " "$pid";
    done
    java -jar arthas-boot.jar -c "stop" "$pid";
}

生成的前2个火焰图如下：
Java服务刚启动时，一小波接口超时排查全过程

乍一看，火焰图中没有明显的瓶颈点，但经过仔细查看，在第一张火焰图中搜索ClassLoader，可以搜到不少类加载操作(红色部分)，而第二张则基本没有！

难道是类加载导致的？目前我有80%信心怀疑就是它导致的，但类加载有那么慢？

为此，我计划使用profile命令的-e wall模式收集刚启动完成时的调用栈，并使用jfr格式保存数据，其中wall模式适合诊断高耗时问题，而jfr格式数据会保存时间戳与线程名称，适合case by case分析，命令如下：

profiler start -e wall --file /tmp/result.jfr

收集到jfr文件后，使用jmc工具打开，然后我在日志平台上找到一个慢调用日志，它显示http-nio-8080-exec-28线程在21:14:10到21:14:18时间段是一次耗时近8s的慢调用，所以我用此条件在jmc里过滤出此case的调用栈数据，如下：
Java服务刚启动时，一小波接口超时排查全过程
可以发现，确实绝大多数耗时发生在类加载上，类加载之所以慢是因为加载类有锁竞争，而我们接口由于查表较多，确实会触发非常多类的加载，所以问题比较明显。

问题解决

知道原因后，解决起来就简单了，把类提前加载到JVM即可，为了简单，我直接使用了spring中的工具方法，如下：

private static final String[] CLASS_PREFIX_ARR = new String[] {
                "org.apache", "com.thoughtworks", "io.netty", "com.google", "io.grpc",
                "com.alibaba", "org.springframework", "cn.hutool", "com.fasterxml", "org.hibernate", 
                "io.opencensus", "org.redisson", "io.micrometer", "io.prometheus",
        };

PathMatchingResourcePatternResolver resolver = new PathMatchingResourcePatternResolver();
for (String classPrefix : CLASS_PREFIX_ARR) {
    Resource[] resources;
    try {
        resources = resolver.getResources(
                "classpath*:" + StringUtils.replaceChars(classPrefix, '.', '/') + "/**/*.class");
    } catch (IOException e) {
        ExceptionUtils.rethrow(e);
        return;
    }
    for (Resource resource : resources) {
        String className = null;
        try (InputStream is = resource.getInputStream()) {
            ClassReader cr = new ClassReader(is);
            className = StringUtils.replaceChars(cr.getClassName(), '/', '.');
            Class<?> clz = Class.forName(className);
            log.info("preLoadClass success: " + className + ", classLoader: " + clz.getClassLoader());
        } catch (Throwable e) { 
            log.warn("preLoadClass failed: " + className);
        }
    }
}

类预加载上线后，后面又进行过多次代码发布，发布过程中几乎不会再产生超时情况，问题确认已解决。

总结

此次问题的排查过程，还是用到了不少排查技巧的，总结一下：

当看起来不应该慢的代码执行慢时，可以想想有哪些可能的隐式操作存在，此次case的隐式操作就是类加载。
当诊断问题没有头绪时，可考虑使用arthas的profile命令来绘制火焰图，看从火焰图中能不能找到线索，尽管不会总是有效。
当从CPU火焰图中看不出明显问题时，可通过对比问题前后的火焰图来找不同点。
理解profile的-e cpu(默认)与-e wall选项的差异，一般-e cpu诊断高cpu问题，而-e wall诊断高耗时问题，但如果是偶尔慢一下，需要case by case分析，可考虑使用jfr格式保存诊断数据。