Почему метод init () сервлета выполняется в другом потоке?

#java #multithreading #jsp #tomcat #servlets

#java #многопоточность #jsp #tomcat #сервлеты

Вопрос:

Это отрывок из книги «Сервлеты Head First и JSP». Чего я не понимаю, так это почему init() метод сам по себе выполняется в потоке A , а service() методы, которые приходят после, выполняются в другом потоке, B .

Означает ли это, что каждый запрос от браузера к сервлету получает два потока? Или init() является общим для всех экземпляров сервлета, которые может создать контейнер? Это было бы неправильно, потому что это не статический метод?

1. init() запускается только один раз во время инициализации сервлета и выполняется в потоке, который запускает приложение. С другой стороны, service() вызывается для каждого запроса в случайном потоке контейнера, обычно берущемся из пула потоков.

2. Как написано в описании: init запускается при запуске. Он выполняется не для каждого запроса. Это отчасти вводит в заблуждение, поскольку не каждый запрос получает другой поток, но идея в том, что он не однопоточный.

Ответ №1:

Сервлет инициализируется только один раз с помощью init() , но для каждого нового запроса создается новый поток или выделяется из пула для вызова экземпляра сервлета соответствующим методом.

Объекты HttpRequest и HttpResponse будут новыми для каждого нового запроса и для потока, но не для экземпляра сервлета.

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

2. @ArunRajagopal Все экземпляры сервлета уничтожаются при завершении работы сервера или при удалении приложения.

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

Ответ №2:

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