Спецификация Java RMI по использованию потока: "..может или не может выполняться в отдельном потоке"

Question

У меня может быть проблема с моим приложением. Существует клиент, выполняющий несколько потоков, которые могут выполнять довольно длительные вызовы сервера через Java RMI. Конечно, длительный звонок от одного клиента не должен блокировать всех остальных.
Я проверил это, и он работает на моей машине. Поэтому я создал два потока на клиенте и фиктивный вызов на сервере. При запуске клиенты оба вызывают фиктивный метод, который просто выполняет огромное количество операций sysout. Видно, что эти вызовы обрабатываются параллельно, без блокировки.
Я был очень доволен, пока коллега не указал, что спецификация RMI не обязательно гарантирует такое поведение.
И на самом деле в тексте по университету Ланкастера говорится, что

«Метод, отправленный средой выполнения RMI удаленному объекту Реализация (сервер) может выполняться или не выполняться в отдельном потоке. Звонки с разных клиентов будут выполняться виртуальными машинами в разных темах. С той же клиентской машины это не гарантируется, что каждый метод будет выполняться в отдельном потоке »[ 1 ]

Что я могу с этим поделать? Возможно ли, что на практике это не сработает?

Answer 1

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

Answer 2

На основании моего тестирования на ноутбуке Mac каждый отдельный клиентский запрос, кажется, выполняется в отдельном потоке (я пробовал до тысячи потоков без каких-либо проблем. Я не знаю, если хотя есть верхняя граница. Я предполагаю, что максимальное количество потоков будет ограничено только памятью).

Затем эти потоки задерживаются на некоторое время (минуту или две), если они могут обслуживать больше клиентов. Если они какое-то время не используются, они получают GC.

Обратите внимание, что я использовал Thread.sleep() на сервере для удержания каждого запроса, поэтому ни один из потоков не смог завершить задачу и перейти к другому запросу.

Дело в том, что при необходимости JVM может даже выделить отдельный поток для каждого клиентского запроса. Если работа выполнена и потоки свободны, она может использовать существующие потоки без создания новых.

Я не вижу ситуации, когда какой-либо клиентский запрос застрял бы в ожидании из-за ограничений RMI. Независимо от того, сколько потоков на сервере «занято» обработкой существующих запросов, новые клиентские запросы будут приниматься.

Answer 3

Эта формулировка означает, что вы не можете предполагать, что все это будет выполняться в одном потоке. Таким образом, вы отвечаете за любую необходимую синхронизацию.