Роль многопоточности в веб-приложении

Я использую java (Servlets, JSP) с 2 лет для разработки веб-приложений. За эти 2 года мне никогда не приходилось использовать multithreading (явно - я знаю, что контейнеры сервлетов используют потоки для обслуживания одного сервлета для разных запросов) в любом проекте.

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

Итак, мой вопрос в том, какова роль multithreading в веб-приложении? Любой пример, в котором multithreading может использоваться в веб-приложении, будет оценен.

Спасибо заранее.

Ответ 1

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

Рассмотрим, например, что у вас есть веб-приложение, которое активирует пользовательское состояние в сети GSM (например, активирует план 4G) и отправляет подтверждающее SMS-сообщение или сообщение электронной почты в конце.

Зная, что веб-вызов займет несколько минут - особенно если сеть GSM подчеркнута - нет смысла называть ее прямо из веб-потока.

Таким образом, когда пользователь нажимает "Активировать", сервер возвращает что-то вроде "Спасибо за активацию плана 4G. Ваш план будет активирован через несколько минут, и вы получите подтверждающее SMS/электронное письмо".

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

Workflow:

1- Пользователь нажимает кнопку "Активировать"
2- Сервлет получает запрос и активирует новую задачу "Активировать 4G-план" в пуле потоков.
3- Сервлет немедленно возвращает ответ HTML пользователю, не дожидаясь завершения задачи.
4- Конец транзакции Http
, , .

Асинхронно, план 4G активируется позже, и пользователь получает уведомление через SMS или электронную почту и т.д.

Ответ 2

Говоря о реальном мире, есть несколько причин использовать многопоточность, и я бы не стал нанимать веб-разработчика, который не знает об этом. Но в конце концов, причины использования многопоточности одинаковы для стандартного и веб-разработки: вы либо хотите что-то, что требуется некоторое время (aka blocking), сделанное в фоновом режиме, чтобы дать пользователю некоторый ответ между ними, или вы есть задача, которая может быть ускорена за счет того, что она запускается на нескольких ядрах. Однако, когда многопоточность действительно полезна, это другой вопрос.

Ситуация 1: Веб-сервер, для которого требуется некоторая обработка, и имеет низкую скорость/секунду

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

Ситуация 2: Веб-сервер, который требует некоторой обработки и имеет высокий уровень хитов/секунду

Здесь многопоточность возможна, но поскольку ядра обычно заняты другими запросами, ресурсов нет, чтобы использовать их правильно. Фактически распространение задачи на несколько потоков может даже отрицательно повлиять на время отклика, так как задача теперь фрагментирована и все части должны быть заполнены, а порядок выполнения с потоками - undefined. Таким образом, один клиент может сразу получить ответ, в то время как другие могут подождать в тайм-ауте, пока их последний фрагмент не будет обработан.

Ситуация 3: Веб-сервер должен выполнить некоторую обработку, которая занимает очень много времени

Здесь требуется многопоточность, нет никакого способа обойти это. Клиент не может ждать минут или, возможно, часов до получения ответа. В этом случае система обратного вызова обычно реализуется, поэтому в основном каждая задача имеет "API", который может быть запрошен для текущего состояния. Большинство интернет-магазинов являются примером для этого: вы заказываете что-то, а позже можете запросить статус своего заказа.

Альтернативой поточной обработке является процесс-форкирование, как это делает Apache в стандартной конфигурации. Преимущество заключается в том, что загрузка распределяется по ядрам (в основном применимым к ситуации 2), и сам веб-код не должен ничего делать, чтобы использовать все эти ядра, поскольку ОС обрабатывает это автоматически. Однако, если у вас есть несбалансированная нагрузка, некоторые ядра могут быть бездействующими, а ресурсы не используются оптимальным образом. Потоковая ситуация почти всегда является лучшим решением, если это делается правильно. Но стандартная конфигурация Apache/Tomcat использует очень устаревшую модель потоков, создавая один поток для каждого запроса. Эффективно учитывая определенное количество обращений/секунд, процессор больше занят потоками, чем с фактической обработкой этих запросов.

Ответ 3

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

Тогда зачем использовать многопоточность явно? Что нужно разработчику веб-приложений подвергать себя многопоточности?

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

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

Ответ 4

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

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