Итак, я запустил эксперимент, и движок 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, РЕЗЬБА: ноль
engineName: Mozilla Rhino, РЕЗЬБА: МНОГООБРАЗНАЯ
Чтобы ответить на ваш точный вопрос ...
Должны ли привязки быть безопасными для потоков?
Мне кажется, что вы несете ответственность за то, чтобы сделать их потокобезопасными. Другими словами, передавать только неизменяемые объекты и вопрос о том, является ли двигатель потокобезопасным или нет, становится не проблема.
Разрешено ли нескольким потокам совместно использовать один экземпляр ScriptEngine?
Для меня это звучит так, как они могут, но ключом является разделение состояний, которое может происходить через привязки. Неизменные предметы - ваш друг.
... или каждый поток должен создавать недолговечный экземпляр?
Мне кажется, что лучший способ думать об этом - это то, что каждое выполнение eval - это недолговечный экземпляр.
... или держать их в бассейне?
В наше время попытки самостоятельно объединить ресурсы редко бывают полезными. Сделайте короткоживущий экземпляр, оцените его эффективность и отработайте.
Что произойдет, если несколько потоков одновременно вызовут ScriptEngine.eval (...)?
Если я правильно понимаю ответ двигателя Rhino на MULTITHREADING, ScriptEngine.eval должен подойти для одновременных вызовов.
Тот же вопрос для экземпляров CompiledScript
JavaDocs заявляет, что «Изменения в состоянии ScriptEngine, вызванные выполнением CompiledScript, могут быть видны при последующих выполнениях сценариев механизмом». http://docs.oracle.com/javase/6/docs/api/javax/script/CompiledScript.html. Так что они не звучат поточно-ориентированными вообще в среде, где вы, похоже, пытаетесь свести к минимуму количество экземпляров ScriptEngine.
Те же вопросы для реализаций интерфейса, сгенерированных с использованием Invocable.getInterface (...)?
Вы здесь сами по себе. Я не совсем понимаю, почему или когда эта возможность будет использоваться, и мне кажется, что вы здесь «прыгаете с акулой». Если вы хотите углубиться в язык сценариев, я рекомендую отказаться от JavaScript и взглянуть на Groovy для более понятного языка Java.
Предположительно, объекты, помещенные в привязки, следуют за сборкой мусора в Java. А как насчет сборки мусора объектов, которые не попадают в привязки?
Если они не заканчиваются в привязках, я ожидаю, что они будут связаны с ScriptEngine и будут следовать его жизненному циклу (основываясь на документах, которые я прочитал). Объединение экземпляров ScriptEngine не похоже на хорошую идею.