背景有朋友碰到了一个情况：java.lang.system#exit无法退出应用程序。
我听到这种情况的时候是感觉很惊奇的，这函数还能不起作用？这就好奇不已了呀
接着，朋友继续给出了他的场景描述：在dubbo应用连接注册中心的时候，如果连接(超时)失败，期望调用system#exit退出应用程序，但是程序并没有按期望退出，jvm进程还存在
与此同时，如果把执行system#exit的代码放到另一个线程，程序可以按期望退出，jvm进程结束
用伪代码描述如下：
future<object> future = 连接注册中心的future;try { object o = future.get(3, timeunit.seconds);} catch (exception e) { log.error("connect failed xxxx"); system.exit(1); // 程序无法退出}-----------future<object> future = 连接注册中心的future;try { object o = future.get(3, timeunit.seconds);} catch (exception e) { log.error("connect failed xxxx"); new thread(() -> system.exit(1)).start(); // 程序能按期望退出}
朋友面临的场景比伪代码描述的情况复杂的多，但所面临的本质问题是一样的。
更一般化地问题，在dubbo的org.apache.dubbo.registry.zookeeper.zookeeperregistry#zookeeperregistry构造函数中，直接执行system.exit(1);程序无法退出，放在异步线程中执行却可以按期望退出
即：
// org.apache.dubbo.registry.zookeeper.zookeeperregistry#zookeeperregistrypublic zookeeperregistry(url url, zookeepertransporter zookeepertransporter) { super(url); system.exit(1); //jvm进程无法退出 // ...(省略)}-----------// org.apache.dubbo.registry.zookeeper.zookeeperregistry#zookeeperregistrypublic zookeeperregistry(url url, zookeepertransporter zookeepertransporter) { super(url); new thread(() -> {system.exit(1);}).start(); //jvm进程正常退出 // ...(省略)}
这就更令人惊奇了！
问题排查要找出问题产生的原因，首先得有一些预备知识，否则会茫然无措，感觉无从下手
java.lang.system#exit 方法是java提供的能够停止jvm进程的方法
该方法被触发时，jvm会去调用shutdown hook(关闭勾子)方法，直到所有勾子方法执行完毕，才会关闭jvm进程
由上述第2点猜测：是否存在死循环的勾子函数无法退出，以致jvm没有去关闭进程？
举个例子：
public static void main(string[] args) { runtime.getruntime().addshutdownhook(new thread(() -> { while (true) { try { system.out.println("closing..."); timeunit.seconds.sleep(1); } catch (interruptedexception e) { } } })); system.out.println("before exit..."); system.exit(0); system.out.println("after exit..."); //代码不会执行}
如上，在main方法里先注册了一个shutdown hook，该勾子函数是个死循环，永远也不会退出，每3秒打印一次"closing&hellip;"
接着执行system.exit(0);方法，期望退出jvm进程
before exit...
closing...
closing...
closing...
closing...
closing...
...
结果是控制台不断打印"closing&hellip;"，且jvm进程没有退出
原因正是上述第二点储备知识提到的：jvm会等待所有勾子执行完毕之后，才关闭进程。而示例中的shutdown hook 永远也不会执行完毕，因此jvm进程也不会被关闭
尽管有了储备知识，仍然很疑惑：如果存在死循环的shutdown hook，那么system.exit无论是在主线程中调用，还是在异步线程中调用，都应该不会关闭jvm进程；反之，如果不存在死循环的shutdown hook，无论是在哪个线程调用，都应该会关闭jvm进程。为什么在背景的伪代码中，却是因为不同的调用线程执行system.exit，导致不一样的结果呢？
这时候只好想办法，看看shutdown hook们都在偷摸干啥事，为什么未执行完毕，以致jvm进程不能退出
恰好对dubbo的源码也略有研究，很容易就找到org.apache.dubbo.registry.zookeeper.zookeeperregistry#zookeeperregistry的构造函数，并在其中加上一行代码，如下所示，改完之后重新编译源码，并引入自己的工程中进行debug
注：本次使用的dubbo版本为2.7.6
// org.apache.dubbo.registry.zookeeper.zookeeperregistry#zookeeperregistrypublic zookeeperregistry(url url, zookeepertransporter zookeepertransporter) { super(url); system.exit(1); // 新增加的一行代码 // ...(省略)}
启动工程，熟悉dubbo的朋友应该会知道，应用启动的过程中会去注册中心(这儿是zookeeper)注册或者订阅，因为启动的是消费者，因此应用会尝试连接注册中心zookeeper，会走到zookeeperregistry的构造函数，由于构造函数第二行是新增的代码system.exit(1);按照背景的说法，jvm不会退出，且会卡死，这时候，借助idea的"快照"功能，可以"拍"下java线程栈的运行情况，功能上相当于执行jstack命令
从线程栈中看出一个可疑的线程：dubboshutdownhook
从名字上可以看出是一个dubbo注册的一个shutdown hook，其主要目的是为了关闭连接、做一些资源的回收等工作
从图中也可以看出，线程阻塞在org.apache.dubbo.registry.support.abstractregistryfactory第83行
public static void destroyall() { if (!destroyed.compareandset(false, true)) { return; } if (logger.isinfoenabled()) { logger.info("close all registries " + getregistries()); } // lock up the registry shutdown process lock.lock(); // 83行，dubboshutdownhook线程阻塞在此处 try { for (registry registry : getregistries()) { try { registry.destroy(); } catch (throwable e) { logger.error(e.getmessage(), e); } } registries.clear(); } finally { // release the lock lock.unlock(); }}
从代码中很显然可以看出，因为获取不到锁，因此线程阻塞在第83行，等待获取锁，也就是说，有别的线程持着这把锁，但还没释放，dubboshutdownhook不得不等待着
通过idea，查看有哪些地方获取了这把锁，如下，找到了
org.apache.dubbo.registry.support.abstractregistryfactory#getregistry(org.apache.dubbo.common.url)
会获取锁
// org.apache.dubbo.registry.support.abstractregistryfactorypublic registry getregistry(url url) { // ...(省略) lock.lock(); // 获取锁 try { // ...(省略) // 创建registry，由于我们选用的注册中心是zookeeper，因此通过spi选择了zookeeperregistryfactory对zookeeperregistry进行创建，最终会调用到我们添加过一行system.exit的zookeeperregistry构造函数中 registry = createregistry(url); // ...(省略) } finally { // release the lock lock.unlock(); // 创建完registry，与注册中心连上之后，才会释放锁 }}
// org.apache.dubbo.registry.zookeeper.zookeeperregistryfactorypublic registry createregistry(url url) { // 调用修改过源码的zookeeperregistry构造函数 return new zookeeperregistry(url, zookeepertransporter);}
如此，system.exit无法退出jvm进程的问题总算真相大白了：
1.dubbo启动过程中会先获取锁，然后创建registry与注册中心进行连接，在zookeeperregistry中调用了java.lang.system#exit方法，程序转而执行"唤起shutdown hook"的代码并阻塞等待所有勾子函数执行完毕，而此时，之前持有的锁并没有释放
2.所有勾子函数(每个勾子函数都对应一个线程)被唤醒并执行，其中有一个dubbo的勾子函数在执行的过程中，需要获取步骤1中的锁，由于获取锁失败，就阻塞等待着
3.由于1没有释放锁的情况下等待2执行完，而2的执行需要等待1释放锁，这样就形成了一个类似"死锁"的场景，因此也就导致了程序卡死，而jvm进程还存活的现象。之所以称为"类似"死锁，是因为1中执行system.exit的线程，也即持有锁的线程，永远不会走到释放锁的代码：一旦程序进入system.exit的世界里，就像进了一个单向虫洞，只能进不能出，如果勾子函数执行完毕，jvm进程接着就会被关闭，不会有机会再释放锁
那么，为什么在异步线程中执行system.exit，却能够正常退出jvm？
那是因为："唤起shutdown hook"并阻塞等待所有勾子函数执行完毕的线程是其它线程(此处假设是线程a)，该线程在阻塞时并未持有任何锁，而主线程会继续往下执行并接着释放锁。一旦锁释放，shutdown hook就有机会持有该锁，并且执行其它资源的回收操作，等到所有的shutdown hook执行完毕，a线程就能从阻塞中返回并执行halt方法关闭jvm，因此能够正常退出jvm进程
深入学习
以上是对java.lang.system#exit 无法退出程序问题的分析，来龙去脉已经阐述清楚，受益于对dubbo源码的了解以及正确的排查思路和排查手段，整个问题排查过程其实并没有花太多时间，但可以趁着这个机会，把java.lang.system#exit系统学习一下，或许会对以后问题排查、基础组件设计提供一些思路
system#exit
// java.lang.systempublic static void exit(int status) { runtime.getruntime().exit(status);}
terminates the currently running java virtual machine. the argument serves as a status code; by convention, a nonzero status code indicates abnormal termination.
this method calls the exit method in class runtime. this method never returns normally.
the call system.exit(n) is effectively equivalent to the call:
runtime.getruntime().exit(n)
这个方法实现非常简单，是runtime#exit的一个简便写法，其作用是用来关闭jvm进程，一旦调用该方法，永远也不会从该方法正常返回：执行完该方法后jvm进程就直接关闭了。
入参status取值分两类：0值与非0值，0值意味着正常关闭，非0值意味着异常关闭。
传入0值[有可能]会去执行所有的finalizer方法，非0值则一定不会执行(都不正常了，还执行啥finalizer呢?)。这儿提及[有可能]是因为，默认并不会执行finalizers，需要调用java.lang.runtime#runfinalizersonexit方法开启，而该方法早被jdk标识为deprecated，因此通常情况下是不会开启的
// java.lang.runtime@deprecatedpublic static void runfinalizersonexit(boolean value) { securitymanager security = system.getsecuritymanager(); if (security != null) { try { security.checkexit(0); } catch (securityexception e) { throw new securityexception("runfinalizersonexit"); } } shutdown.setrunfinalizersonexit(value);}
接着看java.lang.runtime#exit，可以看到，最终调用的是shutdown.exit(status);，该方法是个包级别可见的方法，外部不可见
// java.lang.runtimepublic void exit(int status) { securitymanager security = system.getsecuritymanager(); if (security != null) { security.checkexit(status); } shutdown.exit(status);}
// java.lang.shutdownstatic void exit(int status) { // ...(省略) synchronized (shutdown.class) { /* synchronize on the class object, causing any other thread * that attempts to initiate shutdown to stall indefinitely */ // 执行shutdown序列 sequence(); // 关闭jvm halt(status); }}
// java.lang.shutdownprivate static void sequence() { // ...(省略) runhooks(); // ...(省略)}
// java.lang.shutdownprivate static void runhooks() { for (int i=0; i < max_system_hooks; i++) { try { runnable hook; synchronized (lock) { // 这个锁很重要，目的是通过happens-before保证内存的可见性 currentrunninghook = i; hook = hooks[i]; } if (hook != null) hook.run(); //执行勾子函数 } catch(throwable t) { if (t instanceof threaddeath) { threaddeath td = (threaddeath)t; throw td; } } }}
java.lang.shutdown#runhooks有两个点需要注意，第一点max_system_hooks(hooks)这个并不是我们注册的shutdown hooks，而是按顺序预定义的系统关闭勾子，目前jdk源码(jdk8)预定义了三个：
console restore hook
application hooks
deleteonexit hook
其中，application hooks才是我们应用程序中主动注册的shutdown hook。
在java.lang.applicationshutdownhooks类初始化时，会执行static代码块，并在其中注册了application hooks
// java.lang.applicationshutdownhooksclass applicationshutdownhooks { /* the set of registered hooks */ // 这个才是我们应用程序代码中注册的shutdown hook private static identityhashmap<thread, thread> hooks; static { try { shutdown.add(1 /* shutdown hook invocation order */, false /* not registered if shutdown in progress */, new runnable() { public void run() { runhooks(); } } ); hooks = new identityhashmap<>(); } catch (illegalstateexception e) { // application shutdown hooks cannot be added if // shutdown is in progress. hooks = null; } }
其次要注意的点是，给hook变量赋值的时候进行了加锁
runnable hook;synchronized (lock) { currentrunninghook = i; hook = hooks[i];}
一般而言，给局部变量赋值是不需要加锁的，因为局部变量是栈上变量，而线程栈之间数据是隔离的，不会出现线程安全的问题，因此不需要靠加锁来保证数据并发访问的安全性。
而此处加锁也并非为了解决线程安全问题，其真正的目的在于，通过happens-before规则来保证hooks的内存可见性：an unlock on a monitor happens-before every subsequent lock on that monitor。
如果不加锁，有可能导致从hooks数组中读取到的值并不是内存中最新的变量值，而是一个旧值
上面是读取hooks数组给hook变量赋值，为了满足hb(happens-before)原则，需要确保写操作中同样对hooks变量进行了加锁，因此我们看一下写hooks数组的地方，如下：
// java.lang.shutdownstatic void add(int slot, boolean registershutdowninprogress, runnable hook) { synchronized (lock) { // ...(省略) hooks[slot] = hook; }}
写 操作确实加了锁，这样才能让接下来的 读 操作的加锁行为满足hb原则
由于篇幅原因，就不展开具体的hb介绍，相信了解过hb原则的朋友一下就能明白其中的原理
这个点个人感觉很有意思，因为锁的作用不单是为了保证线程安全，还可以用来做为内存通信、保证内存可见性的手段，因此可以当作面试的一个点，当下次面试官问到：你写的代码中用过锁（synchronized）吗？什么场景用到锁？都集群部署了，单机锁还有意义吗？ 我们就可以回答：为了保证内存的可见性，balabalaba
所以你瞧，这个点其实也给我们设计基础组件带来很大的启发，synchronized在当今集群、分布式环境下并非一无是处，总有合适的地方在等待着它发挥光和热
注：jdk源码中真处处是宝藏，很多地方隐藏着巧妙而不可缺少的设计
在给hook变量赋值之后，就执行 if (hook != null) hook.run();，其中会执行到application hooks，即上面提到的在applicationshutdownhooks类初始化时注册的勾子，勾子内部调用了java.lang.applicationshutdownhooks#runhooks方法
// java.lang.applicationshutdownhooksshutdown.add(1 /* shutdown hook invocation order */, false /* not registered if shutdown in progress */, new runnable() { public void run() { runhooks(); } });
// java.lang.applicationshutdownhooksstatic void runhooks() { collection<thread> threads; synchronized(applicationshutdownhooks.class) { threads = hooks.keyset(); // hooks才是应用程序真正注册的shutdown hook hooks = null; } // 每一个shutdown hook都对应一个thread，由此可见是并发执行关闭勾子函数 for (thread hook : threads) { hook.start(); } for (thread hook : threads) { while (true) { try { hook.join(); // 死等到hook执行完毕 break; } catch (interruptedexception ignored) { // 即便被唤醒都不搭理，接着进行下一轮循环，继续死等 } } }}
上面的hooks才是应用程序真正注册的shutdown hook，由源码可以看出，每一个hook都对应着一个thread，且调用了它们的start方法，即开启thread，意味着shutdown hook是并发、无序地执行
接着，唤起shutdown hook的线程，会通过死循环和join死等到所有关闭勾子都执行完毕，且忽略任何 唤醒异常。也即是说，如果勾子们不执行完，唤醒线程是不会离开的
等所有的application hooks执行完毕，接下来会执行deleteonexit hook(如果存在)，等所有system hooks执行完毕，也基本意味着sequence方法执行完毕，接下来就执行halt方法关闭jvm虚拟机
synchronized (shutdown.class) { sequence(); halt(status);}
这里额外还有一个知识点，上文只是提了一嘴，可能会容易忽略，此处拿出来解释一下：执行java.lang.system#exit永远也不会从该方法正常返回，也即是说，即便system#exit后边跟着的是finally，也不会执行 。一不注意就容易掉坑里
try { // ... system.exit(0);} finally { // 这里的代码永远执行不到}
java.lang.runtime#addshutdownhook
聊完system#exit方法，接着来聊聊注册shutdown hook的方法。该方法本身实现上很简单，如下示：
// java.lang.runtimepublic void addshutdownhook(thread hook) { // ...(省略) applicationshutdownhooks.add(hook);}// java.lang.applicationshutdownhooksstatic synchronized void add(thread hook) { // ...(省略) hooks.put(hook, hook);}
需要注意的是，注册的关闭勾子会在以下几种时机被调用到
程序正常退出
最后一个非守护线程执行完毕退出时
system.exit方法被调用时
程序响应外部事件
程序响应用户输入事件，例如在控制台按ctrl+c(^+c)
程序响应系统事件，如用户注销、系统关机等
除此之外，shutdown hook是不会被执行的
shutdown hook存在的意义之一，是能够帮助我们实现优雅停机，而优雅停机的意义是：应用的重启、停机等操作，不影响业务的连续性
以dubbo provider的视角为例，优雅停机需要满足两点基本诉求：
consumer不应该请求到已经下线的provider
在途请求需要处理完毕，不能被停机指令中断
dubbo注册了shutdown hook，jvm在收到操作系统发来的关闭指令时，会执行关闭勾子
在勾子中停止与注册中心的连接，注册中心会通知consumer某个provider已下线，后续不应该再调用该provider进行服务。此行为是断掉上游流量，满足第一点诉求
接着，勾子执行protocol(dubbo相关概念)的注销逻辑，在其中判断server(dubbo相关概念)是否还在处理请求，在超时时间内等待所有任务处理完毕，则关闭server。此行为是处理在途请求，满足第二点述求
因此，一种优雅停机的整体方案如下：
$pid = ps | grep xxx // 查找要关闭的应用kill $pid // 发出关闭应用指令sleep for a period of time // 等待一段时间，让应用程序执行shutdown hook进行现场的保留跟资源的清理工作$pid = ps | grep xxx // 再次查找要关闭的应用，如果还存在，就需要强行关闭应用if($pid){kill -9 $pid} // 等待一段时间之后，应用程序仍然没有正常停止，则需要强行关闭应用
以上就是java system#exit无法退出程序的问题如何解决的详细内容。