高负载下 Groovy Shell 解释器中的锁定争用

Question

我们正在评估我们应用程序中的 GroovyShell 解释器 (v2.4) 以动态执行标准 Java 语法。

早些时候，我们为它使用 Java BeanShell 解释器，但它在高负载下有一个 issue，这促使我们寻找替代方案，例如 Groovy.

示例Java代码

static String script = "int y = x * x; System.out.println(\"** value of y ** :: \" + y ); ";

GroovyShell gs = new GroovyShell();
Script evalScript = gs.parse("void evalMethod() {" + script + "}");
// bind variables
Binding binding = new Binding();
binding.setVariable("x", 5);
evalScript.setBinding(binding);
// invoke eval method
evalScript.invokeMethod("evalMethod", null);

当多个线程同时执行上述代码时，我们会看到线程锁争用。我们有多个线程处于阻塞状态，这会降低应用程序性能。

阻塞的线程调用堆栈

java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.ClassLoader.loadClass(ClassLoader.java:404)
- waiting to lock <0x00000007bc425e40> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
- locked <0x00000007bd369ba8> (a groovy.lang.GroovyClassLoader)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:677)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:545)
at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:185)
at org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:170)
at org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:126)
at org.codehaus.groovy.control.ResolveVisitor.resolveToOuter(ResolveVisitor.java:676)
at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:313)
at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:845)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:696)
at org.codehaus.groovy.control.ResolveVisitor.transformMethodCallExpression(ResolveVisitor.java:1081)
at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:702)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitExpressionStatement(ClassCodeExpressionTransformer.java:142)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)
at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:37)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:166)
at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:1336)
at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:71)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClassCodeContainer(ClassCodeVisitorSupport.java:104)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitConstructorOrMethod(ClassCodeVisitorSupport.java:115)
at org.codehaus.groovy.ast.ClassCodeExpressionTransformer.visitConstructorOrMethod(ClassCodeExpressionTransformer.java:53)
at org.codehaus.groovy.control.ResolveVisitor.visitConstructorOrMethod(ResolveVisitor.java:201)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:126)
at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1081)
at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:53)
at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1279)
at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:176)
at org.codehaus.groovy.control.CompilationUnit.call(CompilationUnit.java:663)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:943)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:605)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:554)
at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
- locked <0x00000007bd372240> (a java.util.HashMap)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
at groovy.lang.GroovyShell.parse(GroovyShell.java:736)
at groovy.lang.GroovyShell.parse(GroovyShell.java:727)

我的问题是：

有人遇到过这样的问题吗？如果是，您能否提出任何可能的解决方案？我在谷歌上搜索了这个问题，很少有博客建议缓存 groovy Script 对象。 Script 对象是线程安全的吗？此外，我需要将变量绑定到 Script 对象（通过 groovy Binding 对象，这对于不同线程中的每次执行都是不同的），所以我不认为缓存 groovy Script对象是一个可行的选择。
在将 Groovy Shell 解释器与 Java 一起使用时，是否需要遵循任何最佳实践？
我们可以考虑其他任何图书馆吗？我的要求是动态执行标准 Java 语法。

Answer 1

groovy解析&编译是比较重的部分

如果您的脚本是静态的 - 那么您只需解析一次

如果脚本总是不同但重复 - 您可以将已编译的 groovy 脚本缓存到

ConcurrentHashMap<String, Class<groovy.lang.Script>>

之后

Script evalScript = gs.parse(...);

只需将 evalScript.getClass() 放入已编译脚本的缓存中即可。

和 gs.parse(...) 之前检查您是否编译了脚本，如果存在缓存 class 则只获取一个新实例。

检查下面的例子和执行速度

String script = "int y = x * x; System.out.println(\"** value of y ** :: \" + y ); ";

def ts = System.currentTimeMillis()
for(int i=0;i<100;i++){
    GroovyShell gs = new GroovyShell();
    Script evalScript = gs.parse("void evalMethod() {" + script + "}");
    // bind variables
    Binding binding = new Binding();
    binding.setVariable("x", i);
    evalScript.setBinding(binding);
    // invoke eval method
    evalScript.invokeMethod("evalMethod", null);
}
println ">> ${System.currentTimeMillis() - ts} millis"

1165 millis

String script = "int y = x * x; System.out.println(\"** value of y ** :: \" + y ); ";
GroovyShell gs = new GroovyShell();
Class<Script> scriptClass = gs.parse("void evalMethod() {" + script + "}").getClass();

def ts = System.currentTimeMillis()
for(int i=0;i<100;i++){
    Script evalScript = scriptClass.newInstance();
    // bind variables
    Binding binding = new Binding();
    binding.setVariable("x", i);
    evalScript.setBinding(binding);
    // invoke eval method
    evalScript.invokeMethod("evalMethod", null);
}
println ">> ${System.currentTimeMillis() - ts} millis"

6 millis

高负载下 Groovy Shell 解释器中的锁定争用

Lock contention in Groovy Shell interpreter under high load

java

groovy

multithreading

groovyshell

检查下面的例子和执行速度