J'exécute une autre JVM (Java.exe) de l'application principale. Y a-t-il un moyen de partager un objet (objet plutôt important) avec le processus nouvellement créé (au moment de la création ou après la création ou après la création).
someObject sO= new someObject();
//sO is populated
//Creating new process
Runtime rt = Runtime.getRuntime();
Process proc = rt.exec("java -cp " + tempDir + jarsInPath + " " + appMain);
4 Réponses :
Non, il n'y a pas de support de mémoire partagé en Java.
Le moyen le plus simple de s'attaquer aurait-il de sérialiser l'objet dans un fichier temporaire, puis de le désérialiser dans la nouvelle JVM.
Je travaille avec un compilateur (une extension de Java). Je dois prétraiter l'AST qui génère des asts différents. Afin de traiter ceux-ci, je dois à nouveau appeler le compilateur. Au lieu de les exécuter séparément, je tiens à rationaliser ce processus. À l'heure actuelle, je repensez simplement au programme Java d'origine dans le nouveau processus. J'ai essayé sérieusement que c'est plutôt un objet important (un programme complet à préciser) avec de nombreuses structures de données.
Vous pouvez exposer un service pour permettre l'accès aux données de l'objet. Il est comparativement simple de configurer la communication inter-traiter à l'aide de RMI. Il y aura une surcharge IPC afin que cela ne soit pas aussi performant que l'accès local, l'accès à grain fin sera coûteux, mais si vous obtenez un résumé ou d'autres données d'agrégation, cela pourrait être un modèle décent.
Vous ne dites pas pourquoi ce sont des processus distincts. Avez-vous l'occasion de charger le code de votre processus enfant directement dans le parent? Le chargement et le déchargement dynamiques est possible.
Comment puis-je charger le code de votre processus enfant directement dans le parent ». De plus, je ne veux pas obtenir que les données du processus enfant n'envoient que des données du processus parent au processus d'enfant?
Parent-> Enfant, Enfant-> Parent, ne fait aucune différence, on fournit le service l'autre appelle. Mais ma première question était la raison pour laquelle ils sont des processus distincts du tout? Avoir un gros processus, avec des threads faisant des travaux différents. En fonction de vos besoins, vous pouvez simplement relier un gros programme ou charger de manière dynamique des classes en utilisant des API Java standard.
On pourrait penser que ceci est une limitation du modèle d'architecture JVM. Il devient assez difficile de livrer des couches de services sans cette installation. Même les systèmes d'exploitation des massages utiliseront des objets et des services partagés.
Si vous souhaitez partager des objets, le meilleur moyen est d'utiliser des threads au lieu d'un processus séparé. Les processus ne peuvent pas partager la mémoire (sauf par JNI), vous devez donc copier le gros objet dedans dans une forme sérialisée, via des fichiers ou via une connexion de socket RMI (avec ce dernier étant la meilleure option puisqu'elle entraîne une synchronisation inhérente) .
Un thread peut-il être utilisé pour démarrer un autre JVM (Java.exe) comme le code ci-dessus? J'ai toujours vu le processus utilisé pour démarrer une autre JVM.
Non, vous ne pouvez pas démarrer un autre jvm - alors ce serait un processus, pas un fil. Mais avez-vous vraiment besoin d'un autre JVM? Vous ne pouvez pas simplement exécuter la méthode principale () que vous lanceriez la nouvelle JVM avec dans un fil à la place?
J'ai lu que la terre cuite peut faire partager des objets à travers JVM: Stackoverflow.com/Questtions/63926180/...
Je pense que vous pouvez utiliser des caches distribuées à cette fin (EHCache, Memcached et ainsi de suite ...)