我开始研究寻找该类的替代方案，因为它在即将推出的JDK中可能不受支持（我们目前正在开发1.6）。当我构建项目时，我得到：sun.misc.Signal
警告：sun.misc.SignalHandler 是 Sun 专有的 API，可能会在将来的发行版中删除
我遇到了多种解决方案，但它们不适合我的项目，例如在这个问题中。
这在我的情况下是不可接受的，因为：
因此，理想的解决方案是找到类似此类的新Oracle版本或以相同方式工作的东西。是否存在这样的解决方案？
由于在学习Java中的信号处理时，您会发现重复的无限期，因此建议您避免编写直接依赖于信号的Java代码。一般的最佳实践是通过注册关机钩子来允许JVM在+和其他信号上正常退出。直接处理信号会使 Java 程序依赖于操作系统。ctrlc
但有时这没关系，你真的，真的想自己处理信号。
即使它没有作为官方JDK API的一部分公开，JVM的某些部分也必须处理信号（为了触发关闭钩子并退出），并且该组件是。尽管这是一个实现细节，因此可能会更改，但在实践中不太可能。如果要更改它，则需要用等效的机制替换它，并且可能记录在 Java 平台故障诊断指南中。sun.misc.Signal
同级类被广泛使用，并且同样未记录。在尝试删除此类方面正在积极开展工作，因为它“成为非标准但必要的方法的'倾倒场'”，但目前的提案虽然限制了一些非标准API，但默认情况下保留了两者并可用。实际阻止访问这些类的早期计划仍将包含一个命令行标志，以允许访问它们以实现向后兼容性。sun.misc.Unsafesun.misc.Unsafesun.misc.Signal
简而言之，虽然您不能依赖并且必须为这种行为发生变化的可能性进行规划，但在JDK 10之前，这种行为极不可能改变，如果它确实如此，可能会引入一种新的，更好的机制，或者如果需要，会有一种合理的方法来重新启用它。sun.misc.Signal
但是，明智的做法是将依赖于任何类的代码划分为尽可能小的范围 - 创建一个用于信号处理的包装API，以便调用方不需要直接与.这样，如果 API 发生变化，您只需要更改包装器的实现，而不是所有信号处理代码。sun.miscsun.misc
如果您无法接受任何可能在最近的将来发生变化的可能性，那么只需使用JNI接口以编译为机器代码（如C）的语言自己实现信号处理，然后导入库。使用JNI，java可以使用C，C可以使用java。我第一次使用JNI时，我发现能够从我的C程序中使用整个Java API很有趣。sun.misc.SignalSystem.load
现在，您唯一需要担心的是操作系统界面是否会改变，或者更有可能的是，使用中的操作系统的选择将发生变化。
