sun.misc.Signal的替代品
我开始研究找到sun.misc.Signal类的替代方法，因为它可能在即将到来的JDK中不受支持（我们目前正在研究1.6）。 当我构建项目时，我得到：
警告：sun.misc.SignalHandler是Sun专有API，可能会在将来的版本中删除
我遇到了多种解决方案，但它们不适合我的项目，例如在这个问题中 。
这在我的情况下是不可接受的，因为：
- 信号不仅用于杀死应用程序
- 应用程序非常庞大 – 模块/ JVM之间的每次通信概念变化都需要数年时间才能实现
因此，理想的解决方案是找到像这个类的新Oracle版本或者以相同方式工作的东西。 这样的解决方案是否存在？
在学习Java中的信号处理时，您会发现无限重复，我们鼓励您避免编写直接依赖于信号的Java代码。 一般的最佳做法是通过注册关闭钩子来允许JVM在ctrl + c和其他信号上正常退出。 直接处理信号会使您的Java程序依赖于操作系统。
但有时那没关系，你真的，真的想自己处理信号。
尽管它没有作为官方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发生变化，您只需要更改包装器的实现，而不是所有的信号处理代码。
你最好的选择是转移信号，因为它们没有得到很好的支持。
IPC的替代品：
- 套接字（包括Web服务，JMS等）
- 文件锁定
- 内存映射文件