Я довольно новичок в Java, и мой опыт ограничен веб-приложениями, работающими на веб-контейнере (в моем случае Jboss).
Правильно ли я сказал, что для веб-приложений веб-контейнер заботится о многопоточности? Если да, могу ли я представить новые протекторы в веб-приложениях? Есть ли какое-то преимущество в этом, и в каком сценарии это нужно сделать?
Ответы:
Правильно ли я сказал, что для веб-приложений веб-контейнер заботится о многопоточности?
Большинство веб-серверов (Java и другие, включая JBoss) следуют модели «один поток на запрос», т.е. каждый HTTP-запрос полностью обрабатывается ровно одним потоком. Этот поток часто проводит большую часть времени в ожидании таких вещей, как запросы БД. Веб-контейнер будет создавать новые темы по мере необходимости.
Некоторые серверы (в Java-экосистеме, в первую очередь Netty ) выполняют асинхронную обработку запросов, либо с моделью «один поток делает все», либо с чем-то более сложным. Основная идея заключается в том, что большое количество ожидающих потоков приводит к бесполезной трате ресурсов, поэтому асинхронная работа может быть более эффективной.
Если да, могу ли я представить новые протекторы в веб-приложениях?
Это возможно, но должно быть сделано очень осторожно, так как ошибки (такие как утечки памяти или отсутствие синхронизации) могут привести к ошибкам, которые очень трудно воспроизвести, или могут повредить весь сервер.
Есть ли какое-то преимущество в этом, и в каком сценарии это нужно сделать?
Ну, преимущество в том, что вы можете делать вещи параллельно. Использование потоков для улучшения чистой вычислительной скорости - это то, что вы не должны делать на веб-сервере, так как это замедлит обработку других запросов. Подобные вещи должны выполняться на отдельном сервере, возможно, с использованием какой-либо очереди заданий.
Допустимый сценарий многопоточности в контексте обработки HTTP-запроса может быть, если вам нужен доступ к другим сетевым ресурсам, например, для вызова нескольких различных веб-служб. Если вы делаете это за один раз, вам придется ждать, пока каждый вызов не завершится по очереди. Но если вы используете несколько потоков, общее время ожидания - это только задержка одного самого медленного вызова.
В ответ на ваш вопрос:
Чем отличается многопоточность в веб-приложении на основе Java от автономного приложения на Java
Это не отличается. Обычно программные веб-приложения уже обеспечивают многопоточность, превращая каждый новый запрос в поток. Вы можете использовать / создавать потоки так же, как и любое другое приложение.
Действительно, многопоточность может значительно повысить производительность, если вы правильно ее используете. Для задач с интенсивным вводом / выводом, таких как доступ к сети и доступ к дискам, увеличение производительности почти всегда гарантируется. Для сложных вычислительных задач вы должны придерживаться правила одного потока на ядро сервера. Например, если ваше ядро имеет процессор i7, вы должны придерживаться 7 потоков для выполнения вычислительных задач.
В ответ на ваш вопрос:
Есть ли какое-то преимущество в этом, и в каком сценарии это нужно сделать?
Майкл Боргварт говорит, что вы не должны делать это для повышения скорости вычислений. Я не согласен, так как эта статья предполагает, что многопоточность может помочь обеспечить оперативность, когда пользователям необходимо выполнить сложную вычислительную задачу. Говоря простым языком, пользователям не придется долго ждать выполнения сложных вычислительных задач с многопоточностью.
Если вы собираетесь много использовать потоки, я предлагаю использовать пул потоков. Это уменьшит накладные расходы на создание потоков.
Ну, это хороший вопрос, и я думаю, что большинство разработчиков, занимающихся разработкой веб-приложений, не используют многопоточность явно. Причина вполне очевидна, поскольку для развертывания приложения вы используете сервер приложений, сервер приложений внутренне управляет пулом потоков для входящих запросов.
Тогда зачем использовать многопоточность явно? Зачем нужно разработчику веб-приложений подвергать себя многопоточности?
Когда вы работаете с крупномасштабным приложением, в котором вам приходится одновременно обрабатывать много запросов, трудно обрабатывать все виды запросов синхронно, потому что конкретный вид запроса мог выполнять большую обработку, что могло бы снизить производительность вашего приложения.
Давайте рассмотрим пример, когда веб-приложение после обработки определенного вида запроса должно уведомлять пользователей по электронной почте и SMS. Выполнение этого синхронно с потоком запросов может снизить производительность вашего веб-приложения. Так что здесь идет роль многопоточности. В таких случаях рекомендуется разработать автономное многопоточное приложение по сети, которое отвечает только за отправку электронной почты и SMS.
Concurrency Utilities.