性能文章>一次 JVM 进程退出分析>

一次 JVM 进程退出分析原创

9836619

最近我们在测试把 APM 平台迁移到 ES APM,有同学反馈了一个有意思的现象,部署在 docker 中 jar 包项目,在新版 APM 里进程启动完就退出了,被 k8s 中无限重启。

这篇文章写了一下排查的思路,主要包含了下面这些内容。

  • 一个 JVM 进程什么时候会退出
  • 守护线程、非守护线程
  • 从源码角度看 JVM 退出的过程

APM 底层就是使用一个 javaagent 的 jar 包来做字节码改写,那为什么两者会有这么大的差异呢?我一开始想当然认为是新版的 ES APM 代码有毒,导致服务起不来。后面我在本地非 docker 环境中跑了一次,发现没有任何问题,暂时排除了新版 APM 的问题。接下来看看代码是怎么写的。

@SpringBootApplication(scanBasePackages = ["com.masaike.**"])
open class MyRpcServerApplication

fun main(args: Array<String>) {
    runApplication<MyRpcServerApplication>(*args)
    logger.info("#### ClassRpcServerApplication start success")
    System.`in`.read()
}

在之前的文章《关于 /dev/null 差点直播吃鞋的一个小问题》中,我们分析过容器中的 stdin 指向 /dev/null/dev/null 是一个特殊的设备文件,所有接收到的数据都会被丢弃。有人把 /dev/null 比喻为 “黑洞”,从 /dev/null 读数据会立即返回 EOF, System.in.read() 调用会直接退出。

所以执行 main 函数以后,main 线程就退出了,新旧 APM 都一样。接下来就是要弄清楚一个常见的问题:一个 JVM 进程什么时候会退出。

JVM 进程什么时候会退出

关于这个问题,Java 语言规范《12.8. Program Exit》小节里有写,链接在这里:https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.8 ,我把内容贴在了下面。

A program terminates all its activity and exits when one of two things happens:

  • All the threads that are not daemon threads terminate.
  • Some thread invokes the exit method of class Runtime or class System, and the exit operation is not forbidden by the security manager.

翻译过来也就是导致 JVM 的退出只有下面这 2 种情况:

  • 所有的非 daemon 进程退出
  • 某个线程调用了 System.exit( ) 或 Runtime.exit() 显式退出进程

第二种情况当然不符合我们的情况,那嫌疑就放在了第一个上面,也就是换了新版本的 APM 以后,没有非守护进程在运行,所以 main 线程一退出,整个 JVM 进程就退出了。

接下来我们来验证这个想法,方法就是使用 jstack,为了不让接入了新版 APM 的 JVM 退出,先手动加上一个长 sleep。重新打包编译运行镜像,使用 jstack dump 出线程堆栈,可以直接阅读,或者使用「你假笨大神 PerfMa」公司的线程分析 XSheepdog 工具来分析。

image.png

可以看到,新版 APM 里,只有一个阻塞在 sleep 上的 main 线程是非守护线程,如果这个线程也退出了,那就是所有的非守护线程都退出了。这里的 main 没有退出还是后来加了 sleep 导致的。

接下来对比一下旧版 APM,XSheepdog 分析结果如下所示。

image.png

可以看到旧版 APM 里有 5 个非守护线程,其中 4 个非守护线程正是旧版 APM 内部的常驻线程。

到这里,原因就比较清楚了,在 docker 环境中 System.in.read() 调用不会阻塞,会立即退出,main 线程会结束。在旧版里,因为有常驻的非守护的 APM 处理线程在运行,所有整个 JVM 进程不会退出。在新版里,因为没有这些常驻的非守护线程,main 线程退出以后,就不存在非守护线程了,整个 JVM 就退出了。

源码分析

接下的源码分析以下面这段 Java 代码为例,

public class MyMain {
    public static void main(String[] args) {
        System.out.println("in main");
    }
}

接下来我们来调试源码看看,JVM 运行以后会进入 java.c 的 JavaMain 方法,

int JNICALL JavaMain(void * _args) {
    // ...
    /* Initialize the virtual machine */
    InitializeJVM();

    // 获取 public static void main(String[] args) 方法
    mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
                                       "([Ljava/lang/String;)V");
    // 调用 main 方法
    (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
    // main 方法结束以后接下来调用下面的代码
    LEAVE();
}

JavaMain 方法内部就是做了 JVM 的初始化,然后使用 JNI 调用了入口类的 public static void main(String[] args) 方法,如果 main 方法退出,则会调用后面的 LEAVE 方法。

#define LEAVE() \
    do { \
        if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \
            JLI_ReportErrorMessage(JVM_ERROR2); \
            ret = 1; \
        } \
        if (JNI_TRUE) { \
            (*vm)->DestroyJavaVM(vm); \
            return ret; \
        } \
    } while (JNI_FALSE)

LEAVE 方法调用了 DestroyJavaVM(vm); 来触发 JVM 退出,这个退出当然是有条件的。destroy_vm 的源码如下所示。

image.png

可以看到,JVM 会一直等待 main 线程成为最后一个要退出的非守护线程,否则也没有退出的必要。这使用了一个 while 循环等待条件的发生。如果自己是最后一个,就可以准备整个 JVM 的退出了。

也可以把代码稍作修改,新建一个常驻的非守护线程 t,隔 3s 轮询 /tmp/test.txt 文件是否存在。main 线程在 JVM 启动后马上就退出了。

public class MyMain {
    public static void main(String[] args) {
        Thread t = new Thread(new Runnable() {
            @Override
            public void run() {
                File file = new File("/tmp/test.txt");
                while(true) {
                    if (file.exists()) {
                        break;
                    }
                    System.out.println("not exists");
                    try {
                        TimeUnit.SECONDS.sleep(3);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }

            }
        });
        t.setDaemon(false);
        t.start();
        System.out.println("in main");
    }
}

这个例子中,main 函数退出时,会进入 destroy_vm 方法,在这个方法中,会 while 循环等待自己是最后一个非守护线程。如果非守护线程的数量大于 1,则一直阻塞等待,JVM 不会退出,如下所示。

image.png

另外值得注意的是,java 的 daemon 线程概念是自己设计的,在 linux 原生线程中,并没有对应的特性。

小结

为了保证程序常驻运行,Java 中可以使用 CountDownLatch 等并发的类,等待不可能发生的条件。在 Go 中可以使用一个 channel 等待数据写入,但永远不会有数据写入即可。不要依赖外部的 IO 事件,比如本例中的读取 stdin 等。

如果看完这篇文章,下次有人问起,Java 进程什么时候会退出你可以比较完整的打出来,那就很棒了。

点赞收藏
挖坑的张师傅

机械工业出版社《深入理解 JVM 字节码》作者,掘金小册作者《JVM 字节码从入门到精通》、《深入理解TCP 协议》作者,Vim 死忠粉、Kotlin&Go 爱好者、能抓一手好包、喜欢底层技术和分享。微信公众号:张师傅的博客(shifuzhang01)

请先登录,查看6条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

一次 GDB 源码角度分析 jvm 无响应问题

一次 GDB 源码角度分析 jvm 无响应问题

日常Bug排查-集群逐步失去响应

日常Bug排查-集群逐步失去响应

浅析AbstractQueuedSynchronizer

浅析AbstractQueuedSynchronizer

19
6