Хорошая альтернатива общедоступной памяти IPC для приложений на Java/С++ в Linux

Ответ 1

Это зависит от того, как вы планируете взаимодействовать со своими приложениями. В среде POSIX у вас есть каналы, разделяемая память, сокеты, семафоры и очереди сообщений. См. Этот вопрос: Сравнивая IDIX linux IPC для получения дополнительной информации.

Какова модель взаимодействия для ваших процессов (например, клиент/сервер, производитель-потребитель и т.д.)?

Из личного опыта я бы предложил, чтобы ваш лучший выбор был бы трубами (поскольку они являются просто файлами для чтения и записи байтов) или сокетов (поскольку оба языка поддерживают их).

Ответ 2

Как сказал mikelong, это многое зависит от того, что вы делаете. AFAIK, ни один из методов IPC не имеет собственных привязок Java, поэтому вам, вероятно, придется использовать JNI и создавать привязки самостоятельно, поэтому все разные методы примерно одинаково сложны. Если вы выполняете передачу сообщений, я настоятельно рекомендую использовать очереди сообщений. Они очень просты в использовании (как только у вас есть привязки), и имеют хорошую производительность. Если вам нужно "поделиться" с каким-то ресурсом, вы, вероятно, захотите придерживаться общей памяти.

Похоже, что у вас есть какая-то клиентская/серверная вещь, я бы сказал, что использую либо очереди сообщений, либо сокеты домена unix, либо именованные каналы. Все они связаны с копированием данных в ядро, поэтому они не так быстры, как разделяемая память, но они все еще очень быстрые. Если у вас есть сообщения, подобные данным (отдельные небольшие пакеты), перейдите в очередь сообщений. Это, наверное, самое чистое решение. Если у вас больше потока данных, используйте трубы или сокеты. Сокеты имеют то преимущество, что вы можете легко сделать его прозрачным в сети (например, X11) позже, если хотите, но с ними немного сложнее работать, чем с трубами. Производительность, вероятно, очень похожа.

Ответ 3

Хотя, вероятно, не самый эффективный, Java поддерживает только сокеты из коробки (лучшее, что я помню). Они очень гибкие, возможно, не так быстро, как другие варианты. Как упомянуто Zifre, это дает вам возможность прозрачности сети, а также прозрачности языка/привязки; так как почти каждый язык поддерживает библиотеку сокетов из коробки в эти дни.

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

Ответ 4

Самый простой способ общения между приложениями, написанными на разных языках, - IMHO CORBA. Там есть очень хороший open source CORBA ORBs. Мы используем TAO для С++ и JacORB для Java. Существуют также компании, такие как OCI и средство устранения, которые предоставляют технической поддержки.

Ответ 5

В настоящее время я использую общую память для IPC между приложениями Java и С++, но ищем более удобную альтернативу.

Может ли кто-нибудь советовать лучший метод, но с той же скоростью?

Для простой общей памяти вам даже не нужна специальная библиотека:

class Main {
    private static class CustomThread extends Thread {
        public int x = 0;
        public void run() {
            x = 5;
        }
    }

    public static void main(String[] args) {

        CustomThread t = new CustomThread();
        t.start();

        System.out.println(t.x);
        System.out.println(t.x);
    }
}

Локальная переменная x доступна за пределами потока и внутри, позволяя вам использовать ее для передачи информации в поток и из него.