Синглтон против одиночной темы

Question

Обычно сервлеты запускаются только один раз, и веб-контейнер просто создает новый поток для каждого пользовательского запроса.Допустим, если я создаю свой собственный веб-контейнер с нуля, а вместо потоков я просто создаю сервлеты как Singleton.Я что-то здесь упущу?Я предполагаю, что в этом случае синглтон может обслуживать только один пользовательский запрос за раз, а не несколько.

Answer 1

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

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

Допустим, если я создаю свой собственный веб-контейнер с нуля, а вместо потоков я просто создаю сервлеты как Singleton. Я что-нибудь здесь упущу?

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

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

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

Answer 2

JavaEE раньше имел механизм для этого - интерфейс маркера с именем SingleThreadModel, который мог бы реализовать ваш сервлет:

Гарантирует, что сервлеты обрабатывают только один запрос за раз.Этот интерфейс не имеет методов.

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

Обратите внимание, что SingleThreadModel не решает весь потоквопросы безопасности.Например, атрибуты сеанса и статические переменные по-прежнему могут быть доступны для нескольких запросов в нескольких потоках одновременно, даже если используются сервлеты SingleThreadModel.Разработчику рекомендуется использовать другие средства для решения этих проблем вместо реализации этого интерфейса, например избегать использования переменной экземпляра или синхронизировать блок кода, обращающийся к этим ресурсам.Этот интерфейс устарел в Servlet API версии 2.4.

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

Это было объявлено устаревшим в Servlet 2.4 по причинамзадокументировано выше.Те же самые причины все еще относятся к вашему вопросу.

Answer 3

Вот и все.

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