我开始研究寻找替代方案sun.misc.Signal类，因为即将推出的 JDK 可能不支持它（我们目前正在开发 1.6）。当我构建项目时，我得到：
警告：sun.misc.SignalHandler 是 Sun 专有的 API，可能是
在未来版本中删除
我遇到了多种解决方案，但它们不适合我的项目，例如在这个问题 https://stackoverflow.com/questions/5023520/sending-signals-to-a-running-jvm.
这在我的情况下是不可接受的，因为：
- 信号不仅仅用于杀死应用程序
- 该应用程序非常庞大 - 模块/JVM 之间通信的每一个概念上的改变都可能需要数年时间才能实现
因此，理想的解决方案是找到此类的新 Oracle 版本或以相同方式工作的东西。这样的解决方案存在吗？
As you will find repeated ad infinitum when learning about signal handling in Java, you are encouraged to avoid writing Java code that depends directly on signals. The general best practice is to allow the JVM to exit normally on ctrl+c and other signals by registering a shutdown hook https://docs.oracle.com/javase/8/docs/technotes/guides/lang/hook-design.html instead. Handling signals directly makes your Java program OS-dependent.
但有时这没关系，而且您真的非常想自己处理信号。
尽管它没有作为官方 JDK API 的一部分公开，但 JVM 的某些部分必须处理信号（以便触发关闭挂钩并退出），并且该组件是sun.misc.Signal。尽管这是一个实现细节，因此could改变，实际中不太可能。如果要改变，则需要用等效的机制替换，并且可能记录在Java 平台故障排除指南 http://download.java.net/jdk9/docs/technotes/guides/troubleshoot/signals.html.
兄弟班sun.misc.Unsafe被广泛使用并且是同样无证 https://stackoverflow.com/questions/16819234/where-is-sun-misc-unsafe-documented。人们正在积极努力尝试删除此类，因为它是“成为非标准但必要方法的“垃圾场” https://docs.google.com/document/d/1GDm_cAxYInmoHMor-AkStzWvwE9pw6tnz_CebJQxuUE/edit”，但是目前的提案 http://openjdk.java.net/jeps/260，同时限制一些非标准API，保留两者sun.misc.Unsafe and sun.misc.Signal默认可用。实际上阻止访问这些类的早期计划仍然包含一个命令行标志，以允许访问它们以实现向后兼容性。
短时间内你cannot依靠sun.misc.Signal and must为这种行为改变的可能性做好计划，不大可能这种行为将在 JDK 10 之前发生变化，如果发生变化，将会有一个新的、更好的机制probably被引入，或者如果需要的话将有一个合理的方法来重新启用它。
然而，明智的做法是将依赖于任何sun.misc类的范围尽可能小 - 创建一个用于信号处理的包装 API，以便调用者不需要直接交互sun.misc。这样，如果 API 发生更改，您只需更改包装器的实现，而不需要更改所有信号处理代码。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
