sun.misc.Signal的替代品 [英] Alternative to sun.misc.Signal

问题描述

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

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

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

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

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

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

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

This is unacceptable in my situation because:

• 信号不仅用于查杀应用程序


• 应用程序非常庞大 - 模块/ JVM之间的每次通信概念变化都需要数年才能实现

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

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?

推荐答案

在学习Java中的信号处理时，您会发现无限重复的广告，我们鼓励您避免编写直接依赖于信号的Java代码。一般的最佳做法是允许JVM通过注册 ctrl + c 和其他信号上正常退出/javase/8/docs/technotes/guides/lang/hook-design.htmlrel =noreferrer>关闭挂钩。直接处理信号会使您的Java程序依赖于操作系统。

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 instead. Handling signals directly makes your Java program OS-dependent.

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

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

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

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 could change, 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.

兄弟班 sun.misc.Unsafe 被广泛使用，并且同样没有文档记录。我们正努力尝试删除此课程，因为它是成为'倾销场'对于非标准但必要的方法，但当前提案，限制一些非标准API，默认情况下保持 sun.misc.Unsafe 和 sun.misc.Signal 。实际上阻​​止访问这些类的早期计划仍然包含一个命令行标志，允许访问它们以实现向后兼容。

The sibling class sun.misc.Unsafe is 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.Unsafe and sun.misc.Signal available 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.Signal 而必须计划此行为发生变化的可能性，它高度不太可能这种行为会在JDK 10之前发生变化，如果它做了新的，更好的机制将可能引入，或者如果需要，将有合理的方式重新启用它。

In short while you cannot rely on sun.misc.Signal and must plan for the eventuality that this behavior changes, it is highly unlikely that this behavior will change before JDK 10, and if it does either a new, better mechanism will probably be introduced or there will be a reasonable way to re-enable it if needed.

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

However it would be wise to compartmentalize the code that relies on any sun.misc classes 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.Signal的替代品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！