当前位置: 首页 > 面试题库 >

Rhino Script Engine的生命周期和并发语义是什么

单于轶
2023-03-14
问题内容

我对(Rhino)脚本引擎和相关类的生命周期和并发语义感兴趣。特别:

  1. Bindings认为是线程安全的?
  2. 是否应该允许多个线程共享一个ScriptEngine实例?
  3. …还是每个线程都应该构造一个短暂的实例?
  4. …或将它们放在游泳池中?
  5. 如果多个线程同时调用ScriptEngine.eval(...)怎么办?
  6. CompiledScript实例同样的问题
  7. 对于使用Invocable.getInterface(...)?生成的接口实现,存在相同的问题。
  8. 大概,放置在Bindings中的对象遵循Java的垃圾回收。那些没有出现在绑定中的对象的垃圾回收又如何呢?

问题答案:

因此,我进行了实验,Rhino引擎报告“ Mozilla Rhino”已被JavaDocs断言为“ MULTITHREADED”

“多线程”-引擎实现在内部是线程安全的,并且脚本可以同时执行,尽管脚本在一个线程上的执行效果可能对其他线程上的脚本可见。

这是代码…对我来说,它看起来是线程安全的,只要您传递的绑定也是线程安全的即可。

package org.rekdev;
import java.util.*;
import javax.script.*;
public class JavaScriptWTF {
    public static void main( String[] args ) {
        ScriptEngineManager mgr = new ScriptEngineManager();
        List<ScriptEngineFactory> factories = mgr.getEngineFactories();
        for ( ScriptEngineFactory factory : factories ) {
            System.out.println( String.format(
                    "engineName: %s, THREADING: %s",
                    factory.getEngineName(),
                    factory.getParameter( "THREADING" ) ) );
        }
    }
}

…输出是…

engineName:AppleScriptEngine,
THREADING :null engineName:Mozilla Rhino,THREADING:MULTITHREADED


要回答您的确切问题…

  1. 绑定应该是线程安全的吗?
    在我看来,使它们成为线程安全是您的责任。换句话说,仅传递不可变的对象,并且引擎是否为线程安全的都不会成为问题。

  2. 是否应该允许多个线程共享一个ScriptEngine实例?
    在我看来,这听起来很可行,但关键是可以通过绑定进行状态共享。不可变的对象是您的朋友。

  3. …还是每个线程都应该构造一个短暂的实例?
    在我看来,最好的思路是每次执行eval都是短暂的实例。

  4. …或将它们放在游泳池中?
    在当今这个时代,尝试自己收集资源很少是一个好主意。给短暂的实例一个镜头,衡量它的性能,然后从那里开始锻炼。

  5. 如果多个线程同时调用ScriptEngine.eval(…),会发生什么?
    如果我正确理解Rhino引擎对MULTITHREADING的响应,则ScriptEngine.eval应该可以进行并发调用。

  6. 对于CompiledScript实例
    ,存在相同的问题JavaDocs指出:“由CompiledScript的执行引起的ScriptEngine状态的更改可能在引擎随后执行脚本的过程中可见。”
    http://docs.oracle.com/javase/6/docs/api/javax/script/CompiledScript.html。因此,在您似乎试图尽量减少ScriptEngine实例数量的环境中,它们根本不具备线程安全性。

  7. 使用Invocable.getInterface(…)生成的接口实现是否存在相同的问题?你自己一个人在这里。我不确切知道为什么或何时使用此功能,这听起来像是您可能在这里“跳鲨”。如果您想更深入地了解脚本语言,建议您放弃JavaScript,而选择Groovy以获得更可脚本化的Java。

  8. 大概,放置在Bindings中的对象遵循Java的垃圾回收。那些没有出现在绑定中的对象的垃圾回收又如何呢?
    如果它们不以绑定结尾,我希望将它们绑定到ScriptEngine并遵循其生命周期(基于我阅读的文档)。合并ScriptEngine实例听起来不是一个好主意。



 类似资料:
  • 我对Spring的生命周期感到困惑。 上面的代码片段是否创建了对象? 如果上述答案为真。 a) 然后,对于作用域为“singleton”的bean,获取在上述代码片段中创建的对象。我是对还是错? b)对于范围为“原型”的情况,创建的对象是否未使用。因为,容器总是返回新对象。 上面的代码片段是否创建了对象? 如果答案是假的, Spring框架如何验证bean定义是否正确。 根据亨利的回答 通常,单例

  • 本文向大家介绍本地存储的生命周期是什么?相关面试题,主要包含被问及本地存储的生命周期是什么?时的应答技巧和注意事项,需要的朋友参考一下 : 和 都能控制数据的存储时间。 是一个绝对的过期时间, 是文档被访问之后的存活时间(是相对时间)。默认是 。 : 当会话被关闭后(浏览器、标签页被关闭),就会被清除。与 用法一样。 : 除非被主动清除,不然永久储存在浏览器中。 : 没有过期时间,除非主动清除。

  • 我对铁锈寿命的学习过程如下(基于铁锈书): 我想注释,当引用后面的值超出范围时 通常(并不总是!请参阅. data部分,即'静态')值位于块中 我们注释像这样的块,例如结构字段像 。 在哪一点上我的理解是错误的?提前感谢你对我的宽容。 免责声明:

  • 注:本文档提供的生命周期指的是 Universal App 的生命周期,它依赖 rax-app 提供的 runApp方法。 App 级生命周期 launch  在 App 启动时触发 使用生命周期 你可以使用 rax-app 提供的 useAppLaunch 来注册 App 级别的生命周期。 示例: import { useAppLaunch } from 'rax-app'; useAppLa

  • 我们大致为WebAPplication设计了4个生命周期: 请求初始化其实就是从URL中解析提取出{module}, {action}, {method}; 然后再根据{module}, {action}, {method}找到对应的Controller文件; 然后再调用对应的{method},完了之后再发送响应。当然响应的过程中肯定是要顺带着解析下模板标签啦。 恩,这就完了,貌似感觉很简单啊。

  • 如下图. 可以看出,基本周期是: created mounted updated (update 可以理解成人肉手动操作触发) destroyed 上面步骤中的 1,3,4都是自动触发。 每个步骤都有对应的 beforeXyz方法 所以, 我们一般使用mounted 作为页面初始化时执行的方法