Java 替代 sun.misc.Signal

Alternative to sun.misc.Signal

提问by plancys

I started research to find an alternative to the sun.misc.Signalclass, because it could be unsupported in upcoming JDKs (we're currently working on 1.6). When I build the project I get:

我开始研究以寻找sun.misc.Signal该类的替代方案，因为它可能在即将推出的 JDK 中不受支持（我们目前正在开发 1.6）。当我构建项目时，我得到：

warning: sun.misc.SignalHandler is Sun proprietary API and may be removed in a future release

警告：sun.misc.SignalHandler 是 Sun 专有的 API，可能会在未来的版本中删除

I came across multiple solutions but they don't fit my project e.g. in this question.

我遇到了多种解决方案，但它们不适合我的项目，例如在这个问题中。

This is unacceptable in my situation because:

这在我的情况下是不可接受的，因为：

• Signals are used not only for killing application
• The application is huge - every conceptual change of communication between modules/JVMs could take years to implement

• 信号不仅用于杀死应用程序
• 应用程序是巨大的 - 模块/JVM 之间通信的每一个概念变化都可能需要数年才能实现

Thus, the desirable solution is to find something like a new Oracle version of this class or something which works in the same way. Does such a solution exist?

因此，理想的解决方案是找到类似此类的新 Oracle 版本或以相同方式工作的东西。是否存在这样的解决方案？

回答by Jon B

Your best bet is to transition away from signals since they are not well supported.

最好的办法是远离信号，因为它们没有得到很好的支持。

Alternatives for IPC:

IPC 的替代品：

• Sockets (including web services, JMS, etc)
• File locking
• Memory mapped file

• 套接字（包括 Web 服务、JMS 等）
• 文件锁定
• 内存映射文件

回答by dimo414

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+cand other signals by registering a shutdown hookinstead. Handling signals directly makes your Java program OS-dependent.

由于您在学习 Java 中的信号处理时会发现无穷无尽的重复，因此我们鼓励您避免编写直接依赖于信号的 Java 代码。一般的最佳实践是通过注册关闭挂钩来允许 JVM 在ctrl+c和其他信号上正常退出。直接处理信号使您的 Java 程序依赖于操作系统。

But sometimes that's OK, and you really, really do want to handle signals yourself.

但有时这没关系，而且您确实非常想自己处理信号。

Even though it's not exposed as part of the official JDK API, some part of the JVM has to handle signals (in order to trigger the shutdown hooks and exit), and that component is sun.misc.Signal. Although this is an implementation detail and therefore couldchange, it is unlikely in practice. If it were to change, it would need to be replaced with an equivalent mechanism, and likely documented in the Java Platform Troubleshooting Guide.

尽管它没有作为官方 JDK API 的一部分公开，但 JVM 的某些部分必须处理信号（为了触发关闭钩子和退出），而该组件是sun.misc.Signal. 尽管这是一个实现细节，因此可能会更改，但在实践中不太可能。如果要更改，则需要用等效机制替换，并且可能记录在Java 平台故障排除指南 中。

The sibling class sun.misc.Unsafeis widely used and is similarly undocumented. There is active work towards trying to remove this class because it's "become a 'dumping ground' for non-standard, yet necessary, methods", but the current proposal, while limiting some non-standard APIs, keeps both sun.misc.Unsafeand sun.misc.Signalavailable by default. An earlier plan to actually prevent access to these classes would still have included a command-line flag to allow access to them for backwards-compatibility.

兄弟类sun.misc.Unsafe被广泛使用并且同样没有记录。有积极的工作试图删除这个类，因为它“成为非标准但必要的方法的‘倾倒场’”，但当前的提案在限制一些非标准 API 的同时sun.misc.Unsafe，sun.misc.Signal默认情况下保持两者可用。实际阻止访问这些类的早期计划仍将包含一个命令行标志，以允许访问它们以实现向后兼容。

In short while you cannotrely on sun.misc.Signaland mustplan for the eventuality that this behavior changes, it is highly unlikelythat this behavior will change before JDK 10, and if it does either a new, better mechanism will probablybe introduced or there will be a reasonable way to re-enable it if needed.

简而言之，虽然您不能依赖sun.misc.Signal并且必须为这种行为改变的可能性做好计划，但这种行为在 JDK 10 之前不太可能改变，如果它改变了，可能会引入一个新的、更好的机制，或者会有一个如果需要重新启用它的合理方法。

However it would be wise to compartmentalize the code that relies on any sun.miscclasses to as small a scope as possible - create a wrapping API for signal handling so that callers don't need to interact directly with sun.misc. That way if the API changes you only need to change the implementation of your wrapper, rather than all your signal handling code.

然而，将依赖于任何sun.misc类的代码划分为尽可能小的范围是明智的- 创建一个包装 API 来处理信号，这样调用者就不需要直接与sun.misc. 这样，如果 API 发生变化，您只需要更改包装器的实现，而不是所有信号处理代码。

回答by Brenda.ZMPOV

If you can not accept any possibility that sun.misc.Signalmight change in the recent future then just implement the signal handling yourself, with the JNI interface, in a language that compiles to machine code (like C) and import the library with System.load. Using JNI, java can use C and C can use java. The first time I used JNI I found it amusing to have the ability to use the whole java api from within my C program.

如果您不能接受sun.misc.Signal在最近的将来可能发生变化的任何可能性，那么只需使用 JNI 接口以编译为机器代码的语言（如 C）自己实现信号处理，并使用System.load. 使用JNI，java可以使用C，C可以使用java。我第一次使用 JNI 时，我发现能够在我的 C 程序中使用整个 java api 很有趣。

Now the only thing you have to worry about is if the OS interface will change or, far more likely, that the choice of OS in use will change.

现在您唯一需要担心的是操作系统界面是否会发生变化，或者更有可能的是，所用操作系统的选择是否会发生变化。