转载

一次 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 ) { runApplication (*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 工具来分析。

可以看到，新版 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 进程什么时候会退出你可以比较完整的打出来，那就很棒了。

原文 https://club.perfma.com/article/1642314

正文到此结束