Así que me he encontrado el experimento y los informes del motor Rhino "Mozilla Rhino" es multiproceso cual el JavaDocs afirma
"multiproceso" - La puesta en marcha del motor es internamente flujos seguros y guiones de mayo ejecutarse concurrentemente aunque los efectos de la escritura ejecución de un hilo pueden ser visibles a secuencias de comandos en otros hilos."
Aquí está el código ... parece multi-hilo para mí, siempre y cuando los enlaces se pasa en ar e threadsafe también.
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")));
}
}
}
... la salida es ...
EngineName: AppleScriptEngine, roscado: null
EngineName: Mozilla Rhino, roscado: multiproceso
Para responder a su exacta pregunta ...
¿Se supone que los enlaces son seguros para subprocesos?
Me parece que es su responsabilidad hacer que sean seguros para las roscas. En otras palabras, pasar solo objetos inmutables y si el motor es Thread-safe o no se convierte en un problema.
¿Se debe permitir que varios subprocesos compartan una única instancia de ScriptEngine?
Me parece que pueden, pero la clave es compartir el estado que puede ocurrir a través de los enlaces. Los objetos inmutables son tus amigos.
... ¿o debería cada hilo construir una instancia efímera?
Me parece que la mejor manera de pensar en esto es que cada ejecución de eval es una instancia de corta duración.
... ¿o los mantienen en una piscina?
En este día y edad, intentar reunir recursos por su cuenta rara vez es una buena idea. Dale una oportunidad a la instancia efímera, mide su rendimiento y trabaja desde allí.
¿Qué ocurre si varios subprocesos invocan simultáneamente ScriptEngine.eval (...)?
Si entiendo la respuesta del motor de Rhino a MULTITHREADING correctamente, ScriptEngine.eval debería estar bien con las llamadas simultáneas.
La misma pregunta para los casos CompiledScript
estado, el JavaDocs que "Los cambios en el estado de la ScriptEngine causados por la ejecución de la CompiledScript puede visibles durante las ejecuciones posteriores de secuencias de comandos por el motor." http://docs.oracle.com/javase/6/docs/api/javax/script/CompiledScript.html. Por lo tanto, no suenan a prueba de subprocesos en absoluto en un entorno en el que parece que intenta minimizar el número de instancias de ScriptEngine.
Mismas preguntas para las implementaciones de interfaz generadas con Invocable.getInterface (...)? Usted está solo aquí. No entiendo exactamente por qué o cuándo se usará esta capacidad, y me parece que puede estar "saltando al tiburón" aquí. Si desea profundizar en el lenguaje de scripting, le recomiendo que abandone JavaScript y busque en Groovy una Java más scriptable.
Presumiblemente, los objetos colocados en Vinculaciones siguen a la recolección de basura de Java. ¿Qué pasa con la recolección de basura de objetos que no terminan en los enlaces?
Si no terminan en enlaces, espero que estén vinculados al ScriptEngine y sigan su ciclo de vida (basado en los documentos que he leído). Combinar las instancias de ScriptEngine no suena como una gran idea.
No sé, pero los JavaDocs sugiero que se puede pedir la ejecución de sus garantías de seguridad de los subprocesos: http: //download.oracle.com/javase/6/docs/api/javax/script/ ScriptEngineFactory.html # getParameter (java.lang.String) mira el método getParameter y juega con THREADING. –