The Servlet interface is the central abstraction of the servlet API. All servlets implement this interface either directly, or more commonly, by extending a class that implements the interface. The two classes in the servlet API that implement the Servlet interface are GenericServlet and HttpServlet. For most purposes, developers will extend HttpServlet to implement their servlets.
Servlet接口是Servlet API的核心抽象。所有的servlets或者直接实现该接口，或者更常见的继承实现该接口的类。在servlet API中实现Servlet接口的两个类为GenericServlet和HttoServlet。大多数情况下，开发者继承HttpServlet实现他们的servlets。
SRV.2.1 Request Handling Methods
请求处理方法
The basic Servlet interface defines a service method for handling client requests. This method is called for each request that the servlet container routes to an instance of a servlet.
Servlet接口定义了service方法来处理客户端的请求。对于每一个请求，都会调用该方法，servlet容器对应生成一个servlet的实例。
The handling of concurrent requests to a web application generally requires the web developer design servlets that can deal with multiple threads executing within the service method at a particular time.
对于web应用处理并发请求，通常会要求开发者设计servlets使service方法能同时处理多线程。
Generally the web container handles concurrent requests to the same servlet by concurrent execution of the service method on different threads.
通常web容器通过相同servlet不同线程的service方法的并发执行来处理并发请求。
SRV.2.1.1 HTTP Specific Request Handling Methods
HTTP指定的请求处理方法
The HttpServlet abstract subclass adds additional methods beyond the basic Servlet interface which are automatically called by the service method in the HttpServlet class to aid in processing HTTP based requests. These methods are:
继承自Servlet接口的HttpServlet的抽象子类添加了几个方法，根据HTTP请求的方式由service方法自动调用，这些方法是：
• doGet for handling HTTP GET requests
doGet 处理HTTP GET请求
• doPost for handling HTTP POST requests
doPost 处理HTTP Post请求
• doPut for handling HTTP PUT requests
doPut 处理HTTP PUT请求
• doDelete for handling HTTP DELETE requests
doDelete 处理HTTP DELETE请求
• doHead for handling HTTP HEAD requests
doHead 处理HTTP HEAD请求
• doOptions for handling HTTP OPTIONS requests
doOptions 处理HTTP OPTIONS请求
• doTrace for handling HTTP TRACE requests
doTrace 处理HTTP TRACE请求
Typically when developing HTTP based servlets, a Servlet Developer will only concern himself with the doGet and doPost methods. The other methods are considered to be methods for use by programmers very familiar with HTTP programming.
通常开发基于HTTP的servlets时，一个Servlet开发者仅考虑doGet和doPost方法，其他方法只有那些对HTTP开发熟悉的程序员才会考虑使用。
SRV.2.1.2 Additional Methods
添加的方法
The doPut and doDelete methods allow Servlet Developers to support HTTP/1.1 clients that employ these features. The doHead method in HttpServlet is a specialized form of the doGet method that returns only the headers produced by the doGet method. The doOptions method responds with which HTTP methods are supported by the servlet. The doTrace method generates a response containing all instances of the headers sent in the TRACE request.
doPut和doDelete方法允许Servlet开发者支持HTTP/1.1客户端开发相关的特性。HttpServlet中的doHead方法必须指定表单以doGet方式返回，只是仅返回由doGet方式生成的headers。doOptions方法对servlet支持的HTTP方法做出响应。doTrace方法对于所有headers发出的TRACE请求作出响应。
In containers that support only HTTP/1.0, only the doGet, doHead and doPost methods are supported, as HTTP/1.0 does not define the PUT, DELETE, OPTIONS, and TRACE methods.
对于只支持HTTP/1.0的容器，只能支持doHead和doPost方法，因为HTTP/1.0并没有定义PUT、DELETE、OPTIONS和TRACE方式。
SRV.2.1.3 Conditional GET Support
有条件的GET支持
The HttpServlet interface defines the getLastModified method to support conditional GET operations. A conditional GET operation requests a resource be sent only if it has been modified since a specified time. In appropriate situations, implementation of this method may aid efficient utilization of network resources.
SRV.2.2 Number of Instances
The servlet declaration which is part of the deployment descriptor of the web application containing the servlet, as described in Chapter SRV.13, “Deployment Descriptor”, controls how the servlet container provides instances of the servlet.
For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration. However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.
In the case where a servlet was deployed as part of an application marked in the deployment descriptor as distributable, a container may have only one instance per servlet declaration per virtual machine (VM). However, if the servlet in a distributable application implements the SingleThreadModel interface, the container may instantiate multiple instances of that servlet in each VM of the container.
SRV.2.2.1 Note About The Single Thread Model
The use of the SingleThreadModel interface guarantees that only one thread at a time will execute in a given servlet instance’s service method. It is important to note that this guarantee only applies to each servlet instance, since the container may choose to pool such objects. Objects that are accessible to more than one servlet instance at a time, such as instances of HttpSession, may be available at any particular time to multiple servlets, including those that implement SingleThreadModel.
SRV.2.3 Servlet Life Cycle
A servlet is managed through a well defined life cycle that defines how it is loaded, instantiated and initialized, handles requests from clients, and how it is taken out of service. This life cycle is expressed in the API by the init, service, and destroy methods of the javax.servlet.Servlet interface that all servlets must implement directly, or indirectly through the GenericServlet or HttpServlet abstract classes.
SRV.2.3.1 Loading and Instantiation
The servlet container is responsible for loading and instantiating servlets. The loading and instantiation can occur when the container is started, or delayed until the container determines the servlet is needed to service a request.
When the servlet engine is started, needed servlet classes must be located by the servlet container. The servlet container loads the servlet class using normal Java class loading facilities. The loading may be from a local file system, a remote file system, or other network services.
After loading the Servlet class, the container instantiates it for use.
SRV.2.3.2 Initialization
After the servlet object is instantiated, the container must initialize the servlet before it can handle requests from clients. Initialization is provided so that a servlet can read persistent configuration data, initialize costly resources (such as JDBC™ API based connections), and perform other one-time activities. The container initializes the servlet instance by calling the init method of the Servlet interface with a unique (per servlet declaration) object implementing the ServletConfig interface. This configuration object allows the servlet to access name-value initialization parameters from the web application’s configuration information. The configuration object also gives the servlet access to an object (implementing the ServletContext
interface) that describes the servlet’s runtime environment. See Chapter SRV.3, “Servlet Context” for more information about the ServletContext interface.
SRV.2.3.2.1 Error Conditions on Initialization
During initialization, the servlet instance can throw an UnavailableException or a ServletException. In this case the servlet must not be placed into active service and must be released by the servlet container. The destroy method is not called as it is considered unsuccessful initialization.
A new instance may be instantiated and initialized by the container after a failed initialization. The exception to this rule is when an UnavailableException indicates a minimum time of unavailability, and the container must wait for the period to pass before creating and initializing a new servlet instance.
SRV.2.3.2.2 Tool Considerations
The triggering of static initialization methods when a tool loads and introspects a web application is to be distinguished from the calling of the init method. Developers should not assume a servlet is in an active container runtime until the init
method of the Servlet interface is called. For example, a servlet should not try to establish connections to databases or Enterprise JavaBeans™ containers when only static (class) initialization methods have been invoked.
SRV.2.3.3 Request Handling
After a servlet is properly initialized, the servlet container may use it to handle client requests. Requests are represented by request objects of type ServletRequest. The servlet fills out respones to requests by calling methods of a provided object of type ServletResponse. These objects are passed as parameters to the service method of
the Servlet interface.
In the case of an HTTP request, the objects provided by the container are of types HttpServletRequest and HttpServletResponse.
Note that a servlet instance placed into service by a servlet container may handle no requests during its lifetime.
SRV.2.3.3.1 Multithreading Issues
A servlet container may send concurrent requests through the service method of the servlet. To handle the requests the developer of the servlet must make adequate provisions for concurrent processing with multiple threads in the service method.
An alternative for the developer is to implement the SingleThreadModel interface which requires the container to guarantee that there is only one request thread at a time in the service method. A servlet container may satisfy this requirement by serializing requests on a servlet, or by maintaining a pool of servlet instances. If the servlet is part of a web application that has been marked as distributable, the container may maintain a pool of servlet instances in each VM that the application is distributed across.
For servlets not implementing the SingleThreadModel interface, if the service method (or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class) has been defined with the synchronized keyword, the servlet container cannot use the instance pool approach, but must serialize requests through it. It is strongly recommended that developers not synchronize the service method (or methods dispatched to it) in these circumstances because of detrimental effects on performance.
SRV.2.3.3.2 Exceptions During Request Handling
A servlet may throw either a ServletException or an UnavailableException during the service of a request. A ServletException signals that some error occurred during the processing of the request and that the container should take appropriate measures to clean up the request.
An UnavailableException signals that the servlet is unable to handle requests either temporarily or permanently.
If a permanent unavailability is indicated by the UnavailableException, the servlet container must remove the servlet from service, call its destroy method, and release the servlet instance.
If temporary unavailability is indicated by the UnavailableException, then the container may choose to not route any requests through the servlet during the time period of the temporary unavailability. Any requests refused by the container during this period must be returned with a SERVICE_UNAVAILABLE (503) response status along with a Retry-After header indicating when the unavailability will terminate.
The container may choose to ignore the distinction between a permanent and temporary unavailability and treat all UnavailableExceptions as permanent, thereby removing a servlet that throws any UnavailableException from service.
SRV.2.3.3.3 Thread Safety
Implementations of the request and response objects are not guaranteed to be thread safe. This means that they should only be used within the scope of the request handling thread.
References to the request and response objects must not be given to objects executing in other threads as the resulting behavior may be nondeterministic.
SRV.2.3.4 End of Service
The servlet container is not required to keep a servlet loaded for any particular period of time. A servlet instance may be kept active in a servlet container for a period of milliseconds, for the lifetime of the servlet container (which could be a
number of days, months, or years), or any amount of time in between.
When the servlet container determines that a servlet should be removed from service, it calls the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. For example, the
container may do this when it wants to conserve memory resources, or when it itself is being shut down.
Before the servlet container calls the destroy method, it must allow any threads that are currently running in the service method of the servlet to complete execution, or exceed a server defined time limit.
Once the destroy method is called on a servlet instance, the container may not route other requests to that instance of the servlet. If the container needs to enable the servlet again, it must do so with a new instance of the servlet’s class.
After the destroy method completes, the servlet container must release the servlet instance so that it is eligible for garbage collection.
