9

我们目前正在为我们的一款产品添加服务器端脚本功能。作为其中的一部分，我正在评估 JSR 223 脚本引擎。由于我们可能会在服务器上运行大量脚本，因此我特别关心这些脚本引擎的内存使用情况。将 Rhino（Apple JDK 1.6.0_65-b14-462-11M4609，Mac OS X 10.9.2）与 Nashorn（Oracle JDK 1.8.0-b132）进行比较，每个 ScriptEngine 实例的内存使用量似乎存在巨大差异。

为了测试这一点，我使用了一个简单的程序来启动 10 个空白 ScriptEngine 实例，然后阻止从标准输入读取。然后我使用 jmap 进行堆转储（jmap -dump:format=b,file=heap.bin），然后在转储中搜索相关的脚本引擎实例：

import javax.script.*;
public class test {
    public static void main(String...args) throws Exception {
        ScriptContext context = new SimpleScriptContext();
        context.setWriter(null);
        context.setErrorWriter(null);
        context.setReader(null);
        ScriptEngine js[] = new ScriptEngine[10];
        for (int i = 0; i < 10; ++i) {
            js[i] = new ScriptEngineManager().getEngineByName("javascript");
            js[i].setContext(context);
            System.out.println(js[i].getClass().toString());
        }
        System.in.read();
    }
}

取消上下文中各种读取器/写入器字段的原因是因为我们不使用它们，并且早期的 Rhino 堆转储表明它们构成了每个实例开销的很大一部分（并且似乎没有共享） .

在 Eclipse MAT 中分析这些堆转储，然后我得到以下每个实例保留的堆大小：

  • Rhino：13,472 字节/实例（如果我不将读取器/写入器字段清空，则上升到 73,832 字节/实例）
  • Nashorn：324,408 字节/实例

Nashorn 的规模会增加 24 倍吗？执行速度不是我们将要执行的脚本（主要是 I/O 绑定）的主要关注点，因此我正在考虑发布我们自己的 Rhino 副本以在 Java 8+ 中使用。

4

1 回答 1

0

什么是纳肖恩？

Nashorn 是一个用于 JVM 的 JavaScript 引擎，随 Java 8 一起发布。Nashorn 包含一个嵌入式 JavaScript 解释器和一个命令行工具。Nashorn 的目标是使用原生 JVM 在 Java 中实现高性能的 JavaScript 运行时。使用 Nashorn，开发人员可以将 JavaScript 嵌入到 Java 应用程序中，还可以从 JavaScript 代码调用 Java 方法和类，从而提供两种语言之间的无缝集成。

为什么内存消耗大？

Nashorn 对象和属性图目前无法扩展到很多属性。使 PropertyMap 不可变的原因是允许通过比较 PropertyMap 引用来快速验证内联调用站点。这将导致 Nashorn 中的高内存消耗。

一种解决方案是切换到pre-script-java-functions，因为在 java 服务器中，它将具有用于特定任务的 java 函数，并且来自 Nashorn 引擎，您将调用该函数，它不会创建对象映射以及它将创建的所有内容仅在 java 中执行函数并为您提供结果，因此内存消耗相对较低，而不是使用 JS 函数映射 Java 中的所有内容。这些类型的 pre-script-java-functions 用于WSO2-Identity Server 自适应脚本功能。这是在 Nashorn 中处理高内存分配和内存消耗的一种方法。

于 2021-07-30T04:56:24.443 回答