一次 JVM 进程退出的缘由分析

最近咱们在测试把 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() 调用会直接退出。这篇文章的连接在这里：mp.weixin.qq.com/s/lYajWCb-o…

因此执行 main 函数之后，main 线程就退出了，新旧 APM 都同样。接下来就是要弄清楚一个常见的问题：一个 JVM 进程何时会退出。

JVM 进程何时会退出

关于这个问题，Java 语言规范《12.8. Program Exit》小节里有写，连接在这里：docs.oracle.com/javase/spec… ，我把内容贴在了下面。

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 工具来分析。

能够看到，新版 APM 里，只有一个阻塞在 sleep 上的 main 线程是非守护线程，若是这个线程也退出了，那就是全部的非守护线程都退出了。这里的 main 没有退出仍是后来加了 sleep 致使的。

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

能够看到旧版 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 的源码以下所示。

能够看到，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 不会退出，以下所示。

另外值得注意的是，java 的 daemon 线程概念是本身设计的，在 linux 原生线程中，并无对应的特性。

小结

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

若是看完这篇文章，下次有人问起，Java 进程何时会退出你能够比较完整的打出来，那就很棒了。