我开始研究以找到sun.misc.Signal该类的替代方案，因为它可能在即将推出的 JDK 中不受支持（我们目前正在开发 1.6）。当我构建项目时，我得到：
警告：sun.misc.SignalHandler 是 Sun 专有的 API，可能会在未来的版本中删除
我遇到了多种解决方案，但它们不适合我的项目，例如在这个问题中。
这在我的情况下是不可接受的，因为：
因此，理想的解决方案是找到类似此类的新 Oracle 版本或以相同方式工作的东西。这样的解决方案存在吗？
在学习 Java 中的信号处理时，您会发现反复无止境，因此我们鼓励您避免编写直接依赖于信号的 Java 代码。一般的最佳实践是通过注册一个关闭挂钩ctrl来允许 JVM 在+和其他信号上正常退出。直接处理信号使您的 Java 程序依赖于操作系统。c
但有时这没关系，你真的，真的想自己处理信号。
尽管它没有作为官方 JDK API 的一部分公开，但 JVM 的某些部分必须处理信号（以触发关闭挂钩和退出），并且该组件是sun.misc.Signal. 虽然这是一个实现细节，因此可能会改变，但在实践中不太可能。如果要更改，则需要将其替换为等效机制，并且可能记录在Java 平台故障排除指南中。
兄弟类sun.misc.Unsafe被广泛使用，并且同样没有记录。有积极的工作试图删除这个类，因为它“成为非标准但必要的方法的'垃圾场' ”，但当前的提案在限制一些非标准 API 的同时，默认情况下保留两者sun.misc.Unsafe并sun.misc.Signal可用。实际上阻止访问这些类的早期计划仍然包括一个命令行标志以允许访问它们以实现向后兼容性。
简而言之，虽然您不能依赖sun.misc.Signal并且必须为这种行为发生变化的可能性做计划，但这种行为在 JDK 10 之前不太可能发生变化，如果发生这种情况，可能会引入一种新的、更好的机制，或者会有一个如果需要，可以通过合理的方式重新启用它。
然而，明智的做法是将依赖于任何类的代码划分sun.misc到尽可能小的范围内——为信号处理创建一个包装 API，这样调用者就不需要直接与sun.misc. 这样，如果 API 发生更改，您只需更改包装器的实现，而不是更改所有信号处理代码。
如果您不能接受sun.misc.Signal在最近的将来可能发生变化的任何可能性，那么只需使用 JNI 接口以编译为机器代码（如 C）的语言自己实现信号处理，并使用System.load. 使用JNI，java可以使用C，C可以使用java。第一次使用 JNI 时，我发现能够在我的 C 程序中使用整个 java api 很有趣。
现在您唯一需要担心的是操作系统界面是否会改变，或者更有可能的是，所使用的操作系统的选择是否会改变。
这样的解决方案确实存在。JNR ( https://github.com/jnr/ ) 是一个高效的 POSIX 层；与我在这里读到的 JNI+JNA 进行比较：https ://www.slideshare.net/skrb/jnr-java-native-runtime 。
这是我使用 JNR 在 Java 中处理 SIGHUP 的代码：
SignalHandler handler = new SignalHandler()
{
@Override public void handle(int signal) { reloadThings(); }
};
final POSIX posix = POSIXFactory.getPOSIX(new DefaultPOSIXHandler(), true);
posix.signal(Signal.SIGHUP, handler);
SignalHandler 代码是要做的，posix Handle 是 JNR 入口点 AFAIK，然后最后一行注册信号。
JNR 似乎正在积极开发中（截至 2021 年），而且规模不算太大。对我来说看起来不错 - 因为这个，我才开始使用它。PS：我刚刚检查了它是否可以与 SIGINT = Ctrl+C 一起使用。确实如此。
你最好的选择是从信号中过渡，因为它们没有得到很好的支持。
IPC 的替代方案：