JVM разделяет память

Question

У меня есть некоторые сомнения в JAVA. У меня есть исполнитель задач, который будет создавать новый поток для каждой задачи, и каждый поток будет выполнять задачу из jar по

Runtime.getRuntime().exec(" java -jar myjar");

Я читал в некоторых сообщениях, что, выполняя подобное, каждый поток создаст свою собственную JVM. Затем, если я захочу выполнить один и тот же класс или другой класс из одного и того же jar-файла, используя два потока, он создаст копию одного и того же jar-файла в двух JVM. На самом деле я хочу избежать копирования одной и той же банки в двух JVM. Вместо этого я хочу разделить одну и ту же банку между несколькими JVM.

Пожалуйста, дайте несколько советов об этой ситуации.

Answer 1

JVM не нужна собственная копия банки. Ему просто нужно найти его в своем пути к классам. Один и тот же jar-файл может находиться в classpath нескольких запущенных java-программ.

Конечно, каждая JVM имеет свою собственную память, и классы из jar-файлов в ее пути к классам будут загружаться в память каждой JVM. Совместное использование одной и той же памяти для классов, загруженных двумя разными JVM, невозможно. Если вы хотите разделить память, не используйте несколько процессов Java, а используйте потоки.

Answer 2

(Конечно, у вас может быть две JVM, совместно использующие файл JAR, и это не «создает копию» файлов JAR ... но я не думаю, что это то, что вы действительно подразумеваете под своим вопросом.)

---

Sun / Oracle Java имеет функцию под названием CDS (введена в Java 5.0), которая позволяет классам, загруженным из "rt.jar", делиться между несколькими экземплярами JVM.Скомпилированные классы сохраняются в нечто, известное как «общий архив», который затем может быть отображен в памяти в адресное пространство нескольких JVM ... для ускорения запуска JVM.Однако CDS недоступен для классов приложений.

Очевидно, что реализация IBM 5 Java имеет аналогичную функцию, называемую "Shared Classes" , которая работает и для классов приложений.

---

Вы можете сэкономить часть памяти таким способом, но не ясно, сэкономите ли вы значительный объем памяти.Если вы действительно обеспокоены использованием памяти и временем запуска JVM, вам лучше запускать дочерние приложения Java в родительской JVM.(Недостатком, конечно, является то, что если какое-либо из дочерних приложений Java ведет себя неправильно, это может вызвать проблемы, которые могут быть решены только при выходе из родительской JVM.)

Answer 3

Вы на самом деле не "копируете банку" в JVM.Вы загружаете классы из него, и только те классы, которые необходимы.Теперь, если вам каким-то образом не удалось получить много файлов классов размером несколько МБ и порождать десятки этих процессов, это не должно быть большой проблемой.Вам гораздо лучше просто позволить каждому процессу JVM позаботиться о своих проблемах и упростить задачу.При запуске нескольких JVM есть большая вероятность, что у вас все равно будет какая-то оптимизация в фоновом режиме.Не стоит угадывать оптимизацию реализации.

Если по какой-то причине это действительно является абсолютным требованием, вас ждет сложная поездка.Единственное решение, которое я могу придумать, - написать собственный загрузчик классов, который каким-то образом использует разделяемую память.И это, скорее всего, будет связано с использованием нативного интерфейса Java, что заставит вас писать специфичный для платформы код.Возможно, есть какое-то доступное решение, но я не знаю ничего подобного.

И это все, если исходить из того, что вы должны порождать другие процессы Java.Я думаю, вам будет лучше найти способ, чтобы эти другие процессы выполнялись в отдельных потоках, а не в одном и том же Java-процессе.Утилиты параллелизма Java (в пакете java.util.concurrent) сделали такие вещи более управляемыми.

Сама JVM HotSpot использует обмен данными класса в системном файле JAR, чтобы уменьшить объем памятии ускорить загрузку нескольких JVM.Возможно, исходный код может дать некоторые идеи.Но я думаю, что это должно быть абсолютно последним, чтобы попытаться решить любую проблему, которая у вас есть.Если вы не столкнулись с серьезными проблемами с памятью и действительно не нуждаетесь в нескольких процессах, вы пытаетесь оптимизировать то, от чего вам следует держаться подальше.