Я использовал классы с константами:
class Enum {
const NAME = 'aaaa';
const SOME_VALUE = 'bbbb';
}
print Enum::NAME;
Сохраните график на диск, затем отобразите его в памяти с помощью MappedByteBuffer . Оба процесса должны использовать одну и ту же память, которая будет использоваться совместно с кешем страниц.
Две JVM звучат сложнее, чем должно быть. Рассматривали ли вы вариант установки «горячего развертывания», когда ваша основная программа загружает график, отображает пользовательский интерфейс, а затем запрашивает (или автоматически ищет) файл jar / class для загрузки, содержащий реальный код алгоритма? Таким образом, код вашего алгоритма будет работать в том же jvm, что и ваш график, но вам не придется перезагружать граф только для того, чтобы перезагрузить реализацию нового алгоритма.
ОБНОВЛЕНИЕ, чтобы ответить на вопрос OP в комментарии:
Вот как вы можете структурировать свой код так, чтобы ваши алгоритмы можно было менять. Неважно, что делают различные алгоритмы, если они работают с одними и теми же входными данными. Просто определите интерфейс, подобный приведенному ниже, и пусть ваши алгоритмы графа реализуют его.
Рассматривали ли вы платформу OSGi? Он находится в одной JVM, но позволяет обновлять пакеты с помощью алгоритмов без перезапуска платформы. Таким образом, у вас может быть долгосрочно работающий пакет с вашими огромными структурами данных и краткосрочными пакетами алгоритмов, получающими доступ к данным.
Возможно, с использованием RMI? Один экземпляр работает как сервер, а остальные как клиенты?
Думаю, это будет намного сложнее, чем перезагрузка с диска.
Если построение графа обходится дорого, возможно, вы сможете сериализовать объект.
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream out = new ObjectOutputStream(bos);
out.writeObject(graph);
out.flush();
byte b[] = bos.toByteArray();
//you can use FileOutputStream instead of a ByteArrayOutputStream
Затем вы можете построить свой объект из файла
ByteArrayInputStream inputBuffer = new ByteArrayInputStream(b);
ObjectInputStream inputStream = new ObjectInputStream(inputBuffer);
try {
Graph graph = (Graph) inputStream.readObject();
} finally {
if (inputStream != null) {
inputStream.close();
}
}
Просто замените ByteArrayInputStream на FileInputStream
Рассматривали ли вы просто использование меньшего количества выборочных данных для тестирования ваших алгоритмов?
, если проблема заключается только в динамической загрузке и запуске вашего кода без конфликтов имен, может быть достаточно собственного загрузчика классов. для нового запуска просто кэшируйте все файлы классов в новом загрузчике классов.
Конечно, вы можете создать на нем интерфейс и раскрыть его через (скажем) RMI .
My однако первоначальные мысли при чтении вашего сообщения
Я знаю, что у LinkedIn есть обширный список людей и связей , который постоянно хранится в памяти и на перезагрузку требуется несколько часов. Но я считаю, что это действительно исключительный случай.
Terracotta разделяет память между множеством экземпляров JVM, поэтому вы можете легко применить кластер к своей системе.