Не синхронизировать метод обслуживания сервлета.
Если вы синхронизируете метод service сервлета, вы фактически делаете «резервирование доступа» для потока за один раз для этого экземпляра сервлета.
Класс Struts ActionServlet является HttpServlet, и в основном здесь представляют интерес методы doGet и doPost. Если говорить о Struts, то метод process является главной точкой входа, но тот же принцип применяется ко всем методам, как и для общего метода service.
Идея такова.
Когда вы объявляете сервлет в вашем web.app, контейнер сервлета (например, Tomcat) создаст только один экземпляр этого сервлета. Это означает, что существует только один экземпляр для обслуживания всех запросов .
Если в одно и то же время поступает больше запросов, каждый поток запросов получает шанс при использовании метода service, поскольку синхронизация не применяется.
Если у вас есть 10 потоков запросов, каждый из них будет выполняться одновременно в методе service. Обычно это безопасно, поскольку обработка, выполняемая в методе service, не связана с каким-либо состоянием, связанным с текущим запросом, который он обрабатывает. У вас возникают проблемы, если вы добавляете состояние к своим сервлетам Вот статья с более подробной информацией по теме .
Теперь вернемся к Struts .
Struts использует шаблон, называемый Front Controller , где ActionServlet является этим контроллером. Это, в свою очередь, делегирует конкретные запросы конкретным Action классам, указанным в его конфигурации (a.k.a struts-config.xml).
Все входящие запросы проходят здесь. Если вы установите синхронизацию в этот момент (метод Struts process или метод сервлета service выше), вы резервируете сервлет для потока за раз. В случае распорок вы резервируете всю обработку запроса в один поток за один раз .
Это означает, что если 10 запросов поступают одновременно, в случае без синхронизации все могут выполняться бок о бок, в то время как в случае с запросом синхронизации 2 придется ждать, пока запрос 1 не будет выполнен, 3 ждет 2 и т. Д. ( т.е. запросы обрабатываются последовательно). А это означает плохую производительность.
Возможно, для удачливого пользователя, который сделал запрос 1, производительности не будет, но число 10 придется подождать. Тогда как насчет числа 100? 200
Нет необходимости синхронизировать точку входа, если вы программируете свое приложение с учетом безопасности потоков. Если ваше приложение не поддерживает синхронизацию, то синхронизация точки входа снизит производительность.
P.S. Еще одна вещь. Если вы планируете понизить синхронизацию в процессе, а именно классы Action, обратите внимание, что они также не являются поточно-ориентированными, и имеет только один его экземпляр в структуре Struts .