来自Nashorn的IllegalArgumentException异常——它是Java 8中的一个bug吗？

Question

我使用Nashorn javascript引擎来评估java应用程序中编写的所有服务器端javascript代码。为了提高性能，我在启动和评估时使用spring初始化JsEngine

我无法找到问题的根本原因。

@Component
public class JsEngine {

    private ScriptEngine scriptEngine;

    @PostConstruct
    public void init() throws ScriptException, IOException{
        scriptEngine = new ScriptEngineManager().getEngineByName("nashorn");
        this.cacheAllCoreEngines();
        for(String key: defaultEngineSource.keySet()){
            scriptEngine.eval(defaultEngineSource.get(key));
        }
    }

    private void cacheAllCoreEngines()throws IOException{
       //read all core files such as mustache, etc. 
       defaultEngineSource.put("mustache",  FileUtil.readFileFromDisk("<actual path..>/mustache.js"));
    }

    public Object eval(String source) throws  ScriptException{
            .... code to handle exceptions 
            return scriptEngine.eval (source);
    }

}

JsEngine使用如下所示，

public class AppRendererImpl implements  AppRenderer {

    @Autowired
    JsEngine jsEngine;

    public String render(){
     ....
     .... //Read source from disk or cache
     jsEngine.eval(source);....
    }     
}

几个渲染周期后的异常，

例外情况：
java。lang.IllegalArgumentException:目标和筛选器类型在java上不匹配：（ScriptObject）对象，（Object）对象
。lang.invoke。方法论。java上的newIllegalArgumentException（MethodHandleStatics.java:115）
。lang.invoke。方法手柄。java上的filterArgument（MethodHandles.java:2416）
。lang.invoke。MethodHandles。jdk上的filterArguments（MethodHandles.java:2403）
。纳肖恩。内部的查找。MethodHandleFactory$StandardMethodHandleFunctionality。jdk上的filterArguments（MethodHandleFactory.java:277）
。纳肖恩。内部的运行时。WithObject。jdk上的过滤器（WithObject.java:270）
。纳肖恩。内部的运行时。WithObject。fixExpressionCallSite（WithObject.java:249）
位于jdk。纳肖恩。内部的运行时。WithObject。在jdk上查找（WithObject.java:169）
。纳肖恩。内部的运行时。连接器NashornLinker。jdk上的GetGuardInvocation（NashornLinker.java:96）
。内部的dynalink。支持CompositeTypebasedGuardingDynamics。GetGuardInvocation（compositeTypeBasedGuardingDynamicScand.java:176）
在jdk上。内部的dynalink。支持复合防护。jdk上的GetGuardInvocation（compositeGuardingDynamicScand.java:124）
。内部的dynalink。支持LinkerServiceSimp。jdk上的GetGuardInvocation（LinkerServiceSiml.java:144）
。内部的dynalink。动态熟料。在jdk上重新链接（dynamicsolder.java:232）
。纳肖恩。内部的脚本。脚本$^eval_jdk的L6$_L8（：21）
。纳肖恩。内部的脚本。脚本$^eval_jdk的L6$_L40（：41）
。纳肖恩。内部的脚本。脚本$^eval。jdk上的runScript（：1）
。纳肖恩。内部的运行时。ScriptFunctionData。在jdk上调用（ScriptFunctionData.java:498）
。纳肖恩。内部的运行时。脚本函数。在jdk上调用（ScriptFunction.java:206）
。纳肖恩。内部的运行时。脚本运行时。在jdk上应用（ScriptRuntime.java:378）
。纳肖恩。应用程序编程接口。脚本编写。纳什启动了引擎。evalImpl（NashornScriptEngine.java:546）
位于jdk。纳肖恩。应用程序编程接口。脚本编写。纳什启动了引擎。evalImpl（NashornScriptEngine.java:528）
位于jdk。纳肖恩。应用程序编程接口。脚本编写。纳什启动了引擎。evalImpl（NashornScriptEngine.java:524）
位于jdk。纳肖恩。应用程序编程接口。脚本编写。纳什启动了引擎。eval（NashornScriptEngine.java:194）
在javax上。剧本抽象脚本引擎。eval（AbstractScriptEngine.java:264）
在com上。努贝。门户。引擎。js。JsEngine。eval（JsEngine.java:111）
在com上。努贝。门户。引擎。html。标签。HtmlTagScript。eval（HtmlTagScript.java:66）
。。。。。。。。

我添加了一些自定义代码，将所有全局对象复制到另一个地图。这是为了满足其他一些要求，我必须以“nube”的形式访问所有全局对象。我不知道这段代码是否会给频繁运行带来任何问题。请记住，我不会从上下文中删除任何对象。

public void movePublicObjects(String prefix) throws NubeException{
    Bindings b1 = scriptEngine.getContext().getBindings(ScriptContext.ENGINE_SCOPE);
    Map<String, Object> nubeObjects = new HashMap<String, Object>();
    for(Entry<String, Object> entry: b1.entrySet()){
        if(!entry.getKey().equals("nube")){
            nubeObjects.put(entry.getKey(), entry.getValue());
        }
    }
    b1.put("nube", nubeObjects);
    return;
}

当我将JsEngine定义为原型时，这段代码工作得很好，但是性能不好。你认为这是Nashorn中的一个bug吗？

Answer 1

要么你破坏了持久JS上下文中的某个东西，违反了优化器的假设，要么这是一个明显的错误。堆栈跟踪显示，你的代码去调用一个方法，脚本运行时中的代码路径设法到达了一个位置，在这个位置上，函数的优化版本将应用于与其假设不匹配的参数（其参数类型过滤器），因此在这个异常中失败。无论你的JS代码如何，在一致的运行时都不应该遵循这个代码路径。

Answer 2

IIRC，Spring@Component将默认为单例作用域，因此您的JsEngine的单ScriptEngine实例将跨线程共享。

我在Nashorn开发者邮件列表上发现了一个关于线程安全的讨论，它说：

. . . Nashorn不是线程安全的。事实上，如果你评估

新的NashornScriptEngineFactory（）. getParameter（"THREADING"）

它将返回null，这意味着“引擎实现不是线程安全的，不能用于在多个线程上并发执行脚本”——请参阅http://docs.oracle.com/javase/7/docs/api/javax/script/ScriptEngineFactory.html#getParameter（java.lang.String）

Nashorn库内部本身是线程安全的。但在单个引擎实例中执行的JavaScript程序不是线程安全的。

如果您以前尝试过，这与Rhino不同。使用Nashorn，您可能需要采取措施保护您的ScriptEngine免受并发访问，这可能解释了您观察到的不可预测的行为。

考虑设置一个池，访问线程本地的引擎实例，或者将组件范围更改为原型而不是单例。

下面是一个使用初始化脚本引擎的线程本地实例的潜在解决方案：

@Component
public class JsEngine {

    private final ThreadLocal<ScriptEngine> threadEngines =
        new ThreadLocal<ScriptEngine>() {
            @Override
            protected ScriptEngine initialValue() {
                ScriptEngine engine =
                    new ScriptEngineManager().getEngineByName("nashorn");
                for (String key: defaultEngineSource.keySet()) {
                    engine.eval(defaultEngineSource.get(key));
                }
                return engine;
            }
        };

    @PostConstruct
    public void init() throws ScriptException, IOException {
        this.cacheAllCoreEngines();
        // engine initialization moved to per-thread via ThreadLocal
    }

    private void cacheAllCoreEngines() throws IOException{
       //read all core files such as mustache, etc. 
       defaultEngineSource.put("mustache", FileUtil.readFileFromDisk("<actual path..>/mustache.js"));
    }

    public Object eval(String source) throws ScriptException{
        // .... code to handle exceptions 
        return threadEngines.get().eval(source);
    }
}

对于每个使用组件的新线程，初始化引擎（使用小胡子等代码）仍然会有开销。然而，如果您的应用程序使用线程池，那么这些相同的线程应该被重用，您不会像使用原型范围那样每次调用都要支付这笔费用。