hazelcast常见问题_Hazelcast谈到“不安全”问题–“最大的问题是它已经存在了这么长时间”

hazelcast常见问题

JAXenter：似乎已经计划从JDK 9中删除sun.misc.Unsafe API。这是什么原因？

Christoph Engelbert：原因实际上很简单。 首先，希望使用Project Jigsaw将JDK本身拆分为模块，另一个明显的原因是安全性。 由于并非所有模块都需要安装，因此某些计算机上出现安全问题的机会较小。

为此，Jigsaw项目引入了一种新的可见性。 在私有，私有和公共包旁边有一个模块。 这意味着模块元数据定义了实际上从模块中导出了哪些软件包-这个想法与OSGi非常相似。 因此，本发明的目的还在于清理从不意味着用户可见的包装。

就是说， sun.misc.Unsafe并不会真正消失，而是从用户的角度隐藏起来。 JDK / JRE内部仍然可以使用它。

关于这一举动，目前正在进行非常有争议的辩论。 您在哪里看到删除sun.misc.Unsafe的问题？

最大的问题是它可用了这么长时间。 人们将其用于各种解决方案。 在某些情况下，AtomicX类可以解决问题，但是人们使用了它，也许是因为它很酷。 或者，您可以使用它向稍快一些但并非必需的数组中进行写入，然后使用用例，其中sun.misc.Unsafe是唯一真正的解决方案。

这些用例之一是与本机代码的交互。 一个简单的示例是我编写的一个小项目，该项目围绕libbz2库实现了Java包装器。 C代码使用本机指针读取和写入内存，而您只有内存地址。 没有sun.misc.Unsafe，就不可能在Java中读取或写入内存地址。

不安全的另一个原因是性能，它几乎所有方法都被内化了，这意味着实际的本机调用从未真正执行过，而是将一段特殊的汇编代码直接插入到了Java代码中。 如果您在低延迟空间中工作，这是必不可少的。

还有更多用例，但要用一个简短的概述将它们全部命名，将花费太长时间：快速反序列化，模拟框架，Java对象布局分析，网络库等。

删除对Hazelcast及其客户意味着什么？

这在很大程度上取决于Oracle提供的迁移路径的外观。 当前的计划是提供一个命令行标志，以重新导出故意隐藏的sun.misc程序包。 该标志的确切外观尚不清楚，但可以在Java 9中使用sun.misc.Unsafe 。

Hazelcast Enterprise在其HD Memory实现中使用sun.misc.Unsafe将大量数据存储在Java进程存储空间中。 我们很可能必须重新实现HD存储引擎才能使用可能的替换API。

这意味着我们使用HD Memory的任何企业客户都将至少在第一次遇到Java 9问题。 每当宣布Java 9时，我们将开始吸引人们记住为Java 9设置命令行标志。

还请参见： 关于Unsafe的争论仍在继续–“总体Java 9感觉有些破烂”

我在这里看到的真正问题是，人们将不得不在他们的JVM启动配置中添加一个新的未知参数。 大多数人甚至可能都不知道他们使用Unsafe，因为它是来自隐藏在其应用程序中的一个或多个库的暂时依赖。 如果您看一下已经出现了几天的文档 ，就会发现有多少个大型且通常使用的框架以一种或另一种方式依赖于Unsafe。

这对我来说意味着：

• 将不会设置此参数，并且应用程序将无法再启动或减慢速度，或者
• 它将成为一种事实上的标准。

但是还有更多–即使库在无法使用sun.misc.Unsafe的情况下提供备用，但它们通常没有像Unsafe代码路径那样经过广泛的测试。 原因很简单，没有必要。 也就是说，用户可能会看到以前从未遇到过的问题。

为什么不像将使用sun.misc.Unsafe的库更新为官方支持的API一样容易？

用户可能会使用不再积极开发的库。 就像我上面的示例库（libbz2包装器）一样，很长一段时间都没有活跃的开发，它只是功能完善。 尽管我可能进行更新，但其他库现在可能已被放弃。

只要库或应用程序是开放源代码，就有很大的机会有人会进行开发并创建新版本，但是有很多付费库正在使用中，而创建它的原始公司已经不复存在了。 没有人可以更新它，购买替代品是使用它的公司的投资。

这些公司很可能会继续使用Java 8。

Hazelcast在前面提到的公共Google文档中提出了一些解决方案。 你能总结一下你的想法吗？

Google文档尚未提出任何解决方案。 这只是我们的发现的集合。 它可视化了库的数量，并表明市场上几乎所有大型应用程序都受到影响。

我们成立了一个基本工作组，以研究实现平稳迁移路径的构想，并研究sun.misc.Unsafe的替代方案。

在工作组仍处于早期阶段的时候，我开始与Paul Sandoz接触，并积极研究他的VarHandles提案，以发现API中缺少的用例和问题。 我还研究了首个性能基准，以确保它提供必要的性能。 但是，它仍然仅是sun.misc.Unsafe的子集的替代品。

谁在支持您的职位？

查看Google文档，您会发现各种各样的公司，从银行到JVM开发人员，再到Java用户组（例如SouJava）。 除此之外，还有很多行业知名人士，例如Peter Lawrey和Martijn Verburg。 此外，还有一些Java冠军（并非直接在Google Doc或工作组中工作）支持我们的职位，例如Kirk Pepperdine。

还请参见： Java的Unsafe类–“当然也有没有它的方法！”

由于sun.misc.Unsafe是Java的Performance-Swiss-Army-Knife，因此它已被广泛使用，并且Java生态系统的完整分支依赖于此。 这就是为什么我们必须采取行动。 彼得·劳瑞（Peter Lawrey）和我去年已经尝试过建立这种意识，但我们失败了。 它终于得到了应有的关注。

您认为可能的结果是什么？ 您能否说服Oracle找到除删除sun.misc.Unsafe之外的另一种解决方案？

我不认为我们要这样做。 我在这里可能与其他许多人有不同的看法，但Unsafe API丑陋，笨拙，……我说丑陋吗？ 甚至在Oracle提出删除它的计划之前，我都赞成使用干净且受支持的替换API，Unsafe应该“消失”，但请保留具有旧库的人的命令行标志。

我们真正需要确保的是，我们有替代产品可以满足当前的快速使用情况，并以干净的方式解决问题。 如果我回顾一下去年的Oracle调查，大多数sun.misc.Unsafe用户准备根据替换来重新实现其逻辑。 反对者的比例非常接近，无论解决方案是什么样的，他们都不可能做其他任何事情。

我想以我个人觉得很奇怪的事实结束。

几天前，Twitter上有一条推文说：“框架开发人员只是不喜欢放在用户的位置上”。 除了该句子可能是正确的事实之外，我想知道为什么Oracle应该能够比我自己编写更快的Java代码。 对我来说，这听起来像是一个非常错误的想法，并且在研究其他VM语言（如.NET或Python或其他任何语言）时，几乎所有语言都定义了“不安全的部分”，在其中可以进行纯内存访问–我想是有原因的。 如果我们永远都不会拥有sun.misc.Unsafe ，那么谁知道今天的Java将在哪里。 最有可能至少不在高频交易中。

翻译自: https://jaxenter.com/hazelcast-on-java-unsafe-class-119286.html

hazelcast常见问题