Are servlets thread-safe

A Servlet is instantiated only once in the entire Web container and is singleton (except in distributed environments), so thread-safety issues have nothing to do with the Servlet itself and everything to do with how Tomcat handles it. Tomcat allocates a thread for each request to handle the servlet, so the so-called thread-safety problem is for the shared variables in a servlet. If there are no shared variables in a servlet, no matter how many requests are initiated at the same time, there will be no thread-safety problem. That’s like asking you, is Controller thread-safe? Of course, we could also create a Servlet sample for each request by implementing the SingleThreadModel interface, but there is a limit to the number of servletsthat have been declared expired in Servlet 2.4 and are not recommended. It’s good to just know.

ServletContext

As mentioned in the previous article, we can use getServletConfig() to get the private configuration of the current servlet, such as initialization parameters, name, etc., but the most important thing is its getServletContext() method. We get a ServletContext that represents the current entire Web application view, which is shared by all servlets and is globally unique, so we can use it as the largest cache for the entire Web application.






















public InputStream getResourceAsStream(String path); Public String getInitParameter(String name); / / get the global initialization parameter public ServletRegistration. Dynamic addServlet (String servletName, Servlet Servlet); / / the registration servlet public FilterRegistration. Dynamic addFilter (String filterName, Filter Filter); The Filter / / registrationCopy the code

It is worth noting, however, that the two configuration methods for adding servlets and filters have call requirements. Refer to the Servlet3.1 specification and the Java Doc. These configuration methods were added in Servlet3.0. To enable programmatic definition of servlets, filters, and URL patterns they map to, These methods can only during the application initialization from ServletContextListener interface implementation contexInitialized method or the onStartup ServletContainerInitializer interface implementation Method calls, remember the article make a foreshadowing, ServletContainerInitializer are reserved for our extension methods, and can be registered in the servlet filter. As we’ll continue, here’s an example of registering a servlet out of web.xml

public class AnimalServletContainerInitializer implements ServletContainerInitializer { @Override public void onStartup(Set<Class<? >> c, ServletContext ctx) { ServletRegistration.Dynamic servlet = ctx.addServlet("initializerServlet", new HttpServlet() { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {system.out.println (" this is registered programmatically "); }}); servlet.addMapping("/init"); }}Copy the code

Of course here when I use the fastest way, just to illustrate how this is a feasible scheme, didn’t do the other Settings, mainly check the return value of this method, ServletRegistration. Dynamic

interface Dynamic extends ServletRegistration, Registration.Dynamic
Copy the code

A combination of inheritance methods that can be used to configure servlets through web.xml as interface methods, so that we can programmatically decouple from the constraints of web.xml

A Filter is a similar registration method, and we’ll talk about filters and Listeners in servlets in the next section