这个方法可以看注释
/* Invoked by the JNI DestroyJavaVM procedure when the last non-daemon * thread has finished. Unlike the exit method, this method does not * actually halt the VM. */翻译一下就是该方法会在最后一个非daemon线程（非守护线程）结束时被JNI的DestroyJavaVM方法调用。
java中有两类线程，用户线程和守护线程，守护线程是服务于用户线程，如GC线程，JVM判断是否结束的标志就是是否还有用户线程在工作。
当最后一个用户线程结束时，就会调用 Shutdown.shutdown。这是JVM这类虚拟机语言特有的"权利"，倘若是golang这类编译成可执行的二进制文件时，当全部用户线程结束时是不会执行ShutdownHook的。
举个例子，当java进程正常退出时，没有在代码中主动结束进程，也没有kill，就像这样
public static void main(String[] args) { Runtime.getRuntime().addShutdownHook(new Thread() { @Override public void run() { super.run(); System.out.println("I'm shutdown hook "); } }); }当main线程运行完了后，也能打印出I'm shutdown hook，反观golang就做不到这一点（如果可以做到，可以私信告诉我，我是个golang新手）
通过如上两个调用的分析，我们概括出如下结论：
我们能看出java的ShutdownHook其实覆盖的非常全面了，只有一处无法覆盖，即当我们杀死进程时使用了kill -9时，由于程序无法捕获处理，进程被直接杀死，所以无法执行ShutdownHook。
总结综上，我们得出一些结论
重写捕获信号需要注意主动退出进程，否则进程可能永远不会退出，捕获信号的执行是异步的
用户级的ShutdownHook是绑定在系统级的ShutdownHook之上，且用户级是异步执行，系统级是同步顺序执行，用户级处于系统级执行顺序的第二位
ShutdownHook 覆盖的面比较广，不论是手动调用接口退出进程，还是捕获信号退出进程，抑或是用户线程执行完毕退出，都会执行ShutdownHook，唯一不会执行的就是kill -9