最近在看gRPC的一个Demo中，看到一个比较有意思的写法，程序中使用了addShutdownHook()函数。
addShutdownHook（）函数的用法如下：
/**
* Registers a new virtual-machine shutdown hook.
*
* <p> The Java virtual machine <i>shuts down</i> in response to two kinds
* of events:
*
* <ul>
*
* <li> The program <i>exits</i> normally, when the last non-daemon
* thread exits or when the <tt>{@link #exit exit}</tt> (equivalently,
* {@link System#exit(int) System.exit}) method is invoked, or
*
* <li> The virtual machine is <i>terminated</i> in response to a
* user interrupt, such as typing <tt>^C</tt>, or a system-wide event,
* such as user logoff or system shutdown.
*
* </ul>
*
* <p> A <i>shutdown hook</i> is simply an initialized but unstarted
* thread. When the virtual machine begins its shutdown sequence it will
* start all registered shutdown hooks in some unspecified order and let
* them run concurrently. When all the hooks have finished it will then
* run all uninvoked finalizers if finalization-on-exit has been enabled.
* Finally, the virtual machine will halt. Note that daemon threads will
* continue to run during the shutdown sequence, as will non-daemon threads
* if shutdown was initiated by invoking the <tt>{@link #exit exit}</tt>
* method.
*
* <p> Once the shutdown sequence has begun it can be stopped only by
* invoking the <tt>{@link #halt halt}</tt> method, which forcibly
* terminates the virtual machine.
*
* <p> Once the shutdown sequence has begun it is impossible to register a
* new shutdown hook or de-register a previously-registered hook.
* Attempting either of these operations will cause an
* <tt>{@link IllegalStateException}</tt> to be thrown.
*
* <p> Shutdown hooks run at a delicate time in the life cycle of a virtual
* machine and should therefore be coded defensively. They should, in
* particular, be written to be thread-safe and to avoid deadlocks insofar
* as possible. They should also not rely blindly upon services that may
* have registered their own shutdown hooks and therefore may themselves in
* the process of shutting down. Attempts to use other thread-based
* services such as the AWT event-dispatch thread, for example, may lead to
* deadlocks.
*
* <p> Shutdown hooks should also finish their work quickly. When a
* program invokes <tt>{@link #exit exit}</tt> the expectation is
* that the virtual machine will promptly shut down and exit. When the
* virtual machine is terminated due to user logoff or system shutdown the
* underlying operating system may only allow a fixed amount of time in
* which to shut down and exit. It is therefore inadvisable to attempt any
* user interaction or to perform a long-running computation in a shutdown
* hook.
*
* <p> Uncaught exceptions are handled in shutdown hooks just as in any
* other thread, by invoking the <tt>{@link ThreadGroup#uncaughtException
* uncaughtException}</tt> method of the thread's <tt>{@link
* ThreadGroup}</tt> object. The default implementation of this method
* prints the exception's stack trace to <tt>{@link System#err}</tt> and
* terminates the thread; it does not cause the virtual machine to exit or
* halt.
*
* <p> In rare circumstances the virtual machine may <i>abort</i>, that is,
* stop running without shutting down cleanly. This occurs when the
* virtual machine is terminated externally, for example with the
* <tt>SIGKILL</tt> signal on Unix or the <tt>TerminateProcess</tt> call on
* Microsoft Windows. The virtual machine may also abort if a native
* method goes awry by, for example, corrupting internal data structures or
* attempting to access nonexistent memory. If the virtual machine aborts
* then no guarantee can be made about whether or not any shutdown hooks
* will be run. <p>
*
* @param hook
* An initialized but unstarted <tt>{@link Thread}</tt> object
*
* @throws IllegalArgumentException
* If the specified hook has already been registered,
* or if it can be determined that the hook is already running or
* has already been run
*
* @throws IllegalStateException
* If the virtual machine is already in the process
* of shutting down
*
* @throws SecurityException
* If a security manager is present and it denies
* <tt>{@link RuntimePermission}("shutdownHooks")</tt>
*
* @see #removeShutdownHook
* @see #halt(int)
* @see #exit(int)
* @since 1.3
*/ 根据 Java API, 所谓 shutdown hook 就是已经初始化但尚未开始执行的线程对象。在Runtime 注册后，如果JVM要停止前，这些 shutdown hook 便开始执行。也就是在你的程序结束前，执行一些清理工作，尤其是没有用户界面的程序。
这些 shutdown hook 都是些线程对象，因此，你的清理工作要写在 run() 里。根据 Java API，你的清理工作不能太重了，要尽快结束。但仍然可以对数据库进行操作。问题是这个度该如何把握。
翻译：
public void addShutdownHook(Thread hook)
注册新的虚拟机来关闭挂钩。Java 虚拟机会为了响应以下两类事件而关闭：
程序正常退出：这发生在最后的非守护线程退出时，或者在调用 exit（等同于System.exit）方法时。
为响应用户中断而终止虚拟机：如键入 ^C(注：也就是我们再dos窗口下常用的Ctrl+C退出命令)；或发生系统事件，比如用户注销或系统关闭。
shutdown hook只是一个已初始化但尚未启动的线程。虚拟机开始启用其关闭序列时，它会以某种未指定的顺序启动所有已注册的关闭挂钩，并让它们同时运行。运行完所有的挂钩后，如果已启用退出终结，那么虚拟机接着会运行所有未调用的终结方法。最后，虚拟机会暂停。注意，关闭序列期间会继续运行守护线程，如果通过调用 exit 方法来发起关闭序列，那么也会继续运行非守护线程。
一旦开始了关闭序列，则只能通过调用 halt 方法来停止这个序列，此方法可强行终止虚拟机。
一旦开始了关闭序列，则不可能注册新的关闭挂钩或取消注册先前已注册的挂钩。尝试执行这些操作会导致抛出 IllegalStateException。
关闭挂钩可在虚拟机生命周期中的特定时间运行，因此应保护性地对其进行编码。特别是应将关闭挂钩编写为线程安全的，并尽可能地避免死锁。关闭挂钩还应该不盲目地依靠某些服务，这些服务可能已注册了自己的关闭挂钩，所以其本身可能正处于关闭进程中。
关闭挂钩应该快速地完成其工作。当程序调用 exit 时，虚拟机应该迅速地关闭并退出。由于用户注销或系统关闭而终止虚拟机时，底层的操作系统可能只允许在固定的时间内关闭并退出。因此在关闭挂钩中尝试进行任何用户交互或执行长时间的计算都是不明智的。
与其他所有线程一样，通过调用线程 ThreadGroup 对象的 uncaughtException 方法，可在关闭挂钩中处理未捕获的异常。此方法的默认实现是将该异常的堆栈跟踪 (stack trace) 打印至 System.err 并终止线程；它不会导致虚拟机退出或暂停。
仅在很少的情况下，虚拟机可能会中止，也就是没有完全关闭就停止运行。虚拟机被外部终止时会出现这种现象，比如在 Unix 上使用 SIGKILL 信号或者在 Microsoft Windows 上调用 TerminateProcess。如果由于内部数据结构损坏或试图访问不存在的内存而导致本机方法执行错误，那么可能也会中止虚拟机。如果虚拟机中止，则无法保证是否将运行关闭挂钩。
注：
在eclipse环境下，程序运行时的那个红色小方形按钮是强制终止程序，也就是相当于kill进程。因此这时候，如果你的程序中有一个hook，那么它就不会执行。因为按照上文的说法，只有在两种情况下运行hook中的程序。这一点和tomcat的程序关闭有点类似，tomcat中的listener中的contextDestroyed（）方法也是在jvm关闭的时候才执行这个函数里面的程序。而我们如果直接关掉tomcat的运行窗口，就相当于直接kill掉进程了，因此并不会执行这个函数，但是如果使用的是tomcat里面的shutdown.bat命令，那么这个函数就会执行。
所以对于意外关闭JVM或者强制杀死进程的情况，想要清理垃圾或者一些资源回收的问题，本文的addShutdownHook的方法也不管用。
假如你在程序中还开启了一个端口，那么意外的程序终止，这个端口还被占用，并没有被释放，那么下一次程序重启或者别的程序要使用这个端口的时候，就会出现端口被占用的情况。
对于addShutdownHook（）中的Hook，这个线程里面更不能出现死循环的情况，因为这样的话，那么当程序正常终止的时候，就会出现程序关闭不了的情况。