When you call :
Object isThreadSafe = scriptEngine.getFactory().getParameter("THREADING");
It returns MULTITHREADED
as per:
But it is not clear what is the exact impact of this.
Does it mean that :
It would be great if answers could illustrate with some code.
Unfortunately this information is misleading if it comes to GroovyScriptEngineImpl
class. The Javadoc you mentioned says:
"MULTITHREADED" - The engine implementation is internally thread-safe and scripts may execute concurrently although effects of script execution on one thread may be visible to scripts on other threads.
GroovyScriptEngineImpl
does not apply to this, because e.g. you can change the classloader with GroovyScriptEngineImpl.setClassLoader(GroovyClassLoader classLoader)
method and it may cause unpredictable behavior when it happens in concurrent execution (this method is not even atomic and does not synchronize execution between threads).
Regarding scriptEngine.eval(script, bindings)
execution, you have to be aware of its non-deterministic nature when you share same bindings
across many different threads. javax.script.SimpleBindings
default constructor uses HashMap
and you should definitely avoid it - in case of multithreaded execution it's better to use ConcurrentHashMap<String,Object>
to at least allow safe concurrent access. But even though you can't get any guarantee when you evaluate concurrently multiple scripts and those scripts will change global bindings. Consider following example:
import org.codehaus.groovy.jsr223.GroovyScriptEngineImpl
import javax.script.ScriptContext
import javax.script.SimpleBindings
import javax.script.SimpleScriptContext
import java.util.concurrent.ConcurrentHashMap
import java.util.concurrent.ExecutorService
import java.util.concurrent.Executors
import java.util.concurrent.Future
class GroovyScriptEngineExample {
static void main(args) {
def script1 = '''
def x = 4
y++
x++
'''
def script2 = '''
def y = 10
x += y
'''
final GroovyScriptEngineImpl engine = new GroovyScriptEngineImpl()
final ExecutorService executorService = Executors.newFixedThreadPool(5)
(0..3).each {
List<Future> tasks = []
final SimpleBindings bindings = new SimpleBindings(new ConcurrentHashMap<String, Object>())
bindings.put('x', 1)
bindings.put('y', 1)
(0..<5).each {
tasks << executorService.submit {
engine.setClassLoader(new GroovyClassLoader())
engine.eval(script1, bindings)
}
tasks << executorService.submit {
println engine.getClassLoader()
engine.eval(script2, bindings)
}
}
tasks*.get()
println bindings.entrySet()
}
executorService.shutdown()
}
}
In this example we define two Groovy scripts:
def x = 4
y++
x++
and:
def y = 10
x += y
In the first script we define a local variable def x = 4
and x++
increments only our local script variable. When we print x
binding after running this script we will see that it won't change during the execution. However y++
in this case incremented y
binding value.
In the second script we define local variable def y = 10
and we add value of local y
(10
in this case) to current global x
binding value.
As you can see both scripts modify global bindings. In the exemplary code shown in this post we run both scripts 20 times concurrently. We have no idea in what order both scripts get executed (imagine that there is a random timeout in each execution, so one script may hang for couple of seconds). Our bindings
use ConcurrentHashMap
internally so we are only safe if it comes to concurrent access - two threads won't update same binding at the same time. But we have no idea what is the result. After each execution. The first level loop executes 4 times and internal loop executes 5 times and during each execution it submits script evaluation using shared script engine and shared bindings. Also first task replaces GroovyClassLoader
in the engine to show you that it is not safe to share its instance across multiple threads. Below you can find exemplary output (exemplary, because each time you'll run there is a high probability you will get different results):
groovy.lang.GroovyClassLoader@1d6b34d4
groovy.lang.GroovyClassLoader@1d6b34d4
groovy.lang.GroovyClassLoader@64f061f1
groovy.lang.GroovyClassLoader@1c8107ef
groovy.lang.GroovyClassLoader@1c8107ef
[x=41, y=2]
groovy.lang.GroovyClassLoader@338f357a
groovy.lang.GroovyClassLoader@2bc966b6
groovy.lang.GroovyClassLoader@2bc966b6
groovy.lang.GroovyClassLoader@48469ff3
groovy.lang.GroovyClassLoader@48469ff3
[x=51, y=4]
groovy.lang.GroovyClassLoader@238fb21e
groovy.lang.GroovyClassLoader@798865b5
groovy.lang.GroovyClassLoader@17685149
groovy.lang.GroovyClassLoader@50d12b8b
groovy.lang.GroovyClassLoader@1a833027
[x=51, y=6]
groovy.lang.GroovyClassLoader@62e5f0c5
groovy.lang.GroovyClassLoader@62e5f0c5
groovy.lang.GroovyClassLoader@7c1f39b5
groovy.lang.GroovyClassLoader@657dc5d2
groovy.lang.GroovyClassLoader@28536260
[x=51, y=6]
A few conclusions:
GroovyClassLoader
is non-deterministic (in the 1st loop 3 different classloader instances were printed while in the 3rd one we have printed 5 different classloader instances)ConcurrentHashMap
but we have no control over the execution order, so in case of relying on binding value from previous execution you never know what value to expect.So, how to be thread-safe when using GroovyScriptEngineImpl
in multithreaded environment?
new SimpleBindings(Collections.unmodifiableMap(map))
for thatbindings
state modificationGroovyScriptEngineImpl
and don't allow changing classloader after object was initializedHope it helps.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With