«В распределенной среде нельзя использовать многопоточность» - почему?

Question

Я работаю над платформой, на которой размещаются небольшие Java-приложения, все из которых в настоящее время используют один поток, живут в движке Docker, потребляют данные с сервера Kafka и регистрируются в центральной БД.

СейчасМне нужно поставить другое приложение Java на этой платформе.Это приложение под рукой использует многопоточность относительно интенсивно, я уже проверил его в контейнере Docker, и оно отлично работает там, поэтому я готов развернуть его на платформе, где оно будет масштабироваться вручную, то есть какой-то человек определит числоконтейнеров, которые должны быть запущены, каждый из которых содержит экземпляр этого приложения.

Мой архитектор возражает, говоря: «В распределенной среде мы никогда не используем многопоточность».Итак, теперь я должен реорганизовать свое приложение, исключив из него любую логику, связанную с потоками, сделав его однопоточным.Я попросил у него более подробные рассуждения, но он кричит: «Если вы не знаете об этом принципе, вам не место рядом с Java».

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

Честно говоря, я не вижу проблемы многопоточности внутриконтейнер.Это действительно ошибка или как-то «запрещено»?

Спасибо.

Answer 1

Когда вы пишете, например, веб-приложение, которое будет работать на сервере приложений Java EE, обычно вы не должны запускать свои собственные потоки в веб-приложении. Сервер приложений будет управлять потоками и выделять потоки для обработки входящих запросов на сервере.

Однако нет строгого правила или причины, по которой использование многопоточности в распределенной среде никогда не является хорошей идеей.

Существуют преимущества создания приложений однопоточными: код будет проще, и вам не придется сталкиваться с трудными проблемами параллелизма.

Но «в распределенной среде, в которой мы никогда не используем многопоточность», это не всегда всегда так, и «если вы не знаете об этом принципе, у вас нет места рядом с Java», это звучит высокомерно и снисходительно.

Answer 2

Полагаю, он говорит вам об этом только потому, что использование одного потока устраняет проблемы с многопоточностью и упорядочением данных.Хотя в многопоточности нет ничего плохого.

Answer 3

Распределенные системы обычно имеют задачи, которые сильно связаны с вводом / выводом.

Если в вашей системе блокируются вызовы ввода / вывода

Единственный способ достижения параллелизма внутри процесса - это создание новоготемы, чтобы сделать другую полезную работу.(Многопоточность).

• Предостережение при таком подходе заключается в том, что, если в полете слишком много потоков, операционная система будет тратить слишком много времени на переключение контекста между потоками, что является расточительной работой.

Если в вашей системе вызовы ввода-вывода не блокируются

Тогда вы можете избежать многопоточного подхода и использовать один поток для обслуживания всех ваших запросов.(читайте о циклах событий или Java Netty Framework или NodeJS)

Преимущество однопоточного подхода

1. ОС не использует расточительные переключатели контекста потока.
2. Вы НЕ столкнетесь с какими-либо проблемами параллелизма, такими как «мертвые» блокировки или условия гонки.

Недостатком является то, что

1. Зачастую небезопасно кодировать / думать в неблокирующем режиме.fashion
2. Обычно вы используете больше памяти в виде очередей блокировки.

Answer 4

Что?Мы довольно интенсивно используем RxJava и Spring Reactor в нашем приложении, и оно работает довольно хорошо.В любом случае вы не можете работать с потоками в двух JVM.Так что просто убедитесь, что ваша логика работает так, как вы ожидаете, на одной JVM.