The lifecycle of the servlet, the difference between servlet and CGI __java

In general, a servlet can accomplish the same function as a CGI.

CGI application development is difficult because it requires programmers to have the knowledge to handle parameter passing, which is not a generic skill. CGI is not portable, and CGI applications written for a particular platform can only run in this environment. Each CGI application exists in a process that is activated by a client request and is unloaded after the request is serviced. This pattern causes high memory, CPU overhead, and cannot serve multiple customers in the same process.

The servlet provides all the benefits of Java applications: portable, robust, and easy to develop. Using the servlet tag technique, the servlet can generate dynamic content embedded in static HTML pages.

The main advantage of the servlet for CGI is that a servlet is activated by the first request sent by the client, and then it will continue to run in the background, waiting for a later request. Each request will generate a new thread, not a complete process. Multiple customers can get a service at the same time in the same process. In general, the servlet process is unloaded only when the Web server is unloaded.

Comparison between Java servlet and CGI (Common Gateway Interface Common Gateway Interface):

Compared to traditional CGI and many other CGI-like technologies, the Java servlet is more efficient, easier to use, more powerful, more portable, and less expensive to invest. In the course of future technology development, the servlet may completely replace the CGI.

In traditional CGI, each request starts a new process, and if the CGI program itself is executing for a short time, the overhead of starting the process is likely to exceed the actual execution time. In the servlet, each request is handled by a lightweight Java thread (rather than a heavyweight operating system process).

In traditional CGI, if there are n concurrent requests for the same CGI program, the CGI program's code is repeatedly loaded n times in memory, and for the servlet, the request is n threads, and only one servlet class code is required. In terms of performance tuning, the servlet also has more options than CGI.

　　* Convenient　

The servlet provides a number of utility routines, such as automatically parsing and decoding HTML form data, reading and setting HTTP headers, processing cookies, tracking session state, and so on.

　　* Strong function

In the servlet, many tasks that are difficult to accomplish with traditional CGI programs can be done easily. For example, a servlet can interact directly with a Web server, whereas a normal CGI program cannot. The servlet can also share data between programs, making it easy to implement features such as database connection pooling.

　　* Good portability

The servlet is written in Java and the Servlet API has perfect standards. Therefore, the servlet written for iplanet Enterprise server can be ported to Apache, Microsoft IIS, or WebSTAR without any substantial changes. Almost all mainstream servers support the servlet directly or through Plug-ins.

The servlet lifecycle servlet has a good definition of lifetime, including Hegazai, instantiating, initializing, processing client requests, and how to be removed. This lifetime is expressed by the init,service and destroy methods of the Javax.servlet.Servlet interface.
1. Loading and instantiation
The container is responsible for loading and instantiating a servlet. Instantiation and loading can occur either at the time the engine is started or when the container needs the servlet to request service from the customer.
First, the container must locate the servlet class, and, if necessary, the container loads the servlet using the usual Java class loader tool, either from the native file system or from the remote file system or even other network services. After the container loads the servlet class, it instantiates an instance of the class. Note that multiple instances may be instantiated, for example, a servlet class has multiple definitions because of different initial parameters, or the servlet implements Singlethreadmodel, causing the container to generate an instance pool for it.
2. Initialization
After the servlet is loaded and instantiated, the container must initialize it before it can handle the client request. The process of initialization is primarily to read permanent configuration information, expensive resources (such as JDBC connections), and other tasks that only need to be performed once. Complete this procedure by calling its Init method and passing it a unique one (one per servlet definition) ServletConfig object. The configuration object passed to it allows the servlet to access the name-value pair (name-value) initialization parameters in the container's configuration information. This configuration object also provides a way for the servlet to access specific objects that implement the ServletContext interface, which describes the environment in which the servlet is running.
2.1 Initialization error Handling
During initialization, the servlet instance may indicate that it cannot perform a valid service by throwing a unavailableexception or servletexception exception. If a servlet throws such an exception, it will not be placed in a valid service and should be immediately released by the container. In this case the Destroy method is not invoked because the initialization did not complete successfully. After the failed instance is freed, the container may instantiate a new instance at any time, the only exception to this rule is if the failed servlet throws an exception that is unavailableexception and the exception indicates the minimum invalid time. The container then waits for at least the time specified by that point to try again to create a new instance.
2.2. Instrumental factors
When the tool (note: According to the author's understanding, this tool may be the application server of some inspection tools, usually verifying the legality and integrity of the application) loading and introspection (Introspect) a Web application, it may load and introspect the class in the application, This behavior triggers the static initial method of those classes to be executed, so the developer cannot assume that it will be in the active container running state (Active container runtime) only when the servlet's Init method is invoked. As an example, this means that the servlet cannot attempt to establish a database connection or to connect to an EJB container when its static (class) initialization method is invoked.
3, processing requests
After the servlet is properly initialized, the container can use it to process the request. Each request is represented by an object of type ServletRequest, and the servlet uses servletresponse back should be requested. These objects are passed to the servlet as arguments to the service method. In the case of HTTP requests, the container must provide a concrete implementation of the HttpServletRequest and httpservletresponse that represent the request and the response. Note that the container may create a servlet instance and put it into the waiting service state, but this instance may not have handled any requests at all during its lifetime.
3.1, multithreading issues
The container may also send multiple client requests to an instance's service method, which means that the developer must ensure that the servlet is written to handle concurrency issues. If the developer wants to prevent this default behavior, then he can have the servlet written by him implement Singlethreadmodel. Implementing this class ensures that only one thread at a time executes the service method and executes it once. A container can satisfy this by queuing the request or maintaining a servlet instance pool. If the servlet is part of a distributed application, then the container may maintain an instance pool in each JVM in which the application is distributed. If the developer uses the Synchronized keyword to define the service method (or Doget and dopost), the container queues the request, which is required by the underlying Java runtime system. We strongly recommend that developers do not sync service methods or HttpServlet services such as Doget and Dopost.
3.2, processing the exception in the request
The servlet may throw servletexception or unavailableexception exceptions when servicing requests. Servletexception indicates that an error occurred during the processing of the request the container should use the appropriate method to clear the request. Unavailableexception indicates that the servlet cannot process the request, either temporarily or permanently. If unavailableexception indicates that it is permanent, the container must remove the servlet from the service, call its Destroy method, and release its instance. If the indication is temporary, the container may choose not to send any requests to it in the temporarily unavailable time period specified in the exception information. Requests that are rejected in this time period must use Service_unavailable (503) to return the state for response and should carry a response header that will be retried later (Retry-after) to indicate that the service is temporary. The container can also choose not to differentiate between temporary and permanent unavailable and all as permanent and remove the servlet that throws the exception.
3.3 Thread Safety
Developers should be aware that the container implementation of the request and Response objects (note: The container implementation of the HttpServletRequest and Httpservletresponese) is not guaranteed to be thread-safe, which means that they can only be used in the scope of the request processing thread, These objects cannot be referenced by other thread of execution because the behavior of the reference is indeterminate.
4. End of service
The container is not required to hold a loaded servlet for a long time, so a servlet instance may survive only a few milliseconds in the container, Of course, it could be any other longer time (but certainly shorter than the lifetime of the container) when the container decides to remove it (possibly because of saving memory resources or shutting itself down), Then it must allow the servlet to release any resources it is using and save any permanent state (this process is achieved by invoking the Destroy method). Before a container can invoke the Destroy method, it must allow the thread that is executing in the service method to execute or execute for a period of time defined by the server (this time period before the container calls destroy). Once the Destroy method is invoked, the container will no longer send any requests to the instance. If the container needs to use the servlet again, it must create a new instance. After the Destroy method completes, the container must release the servlet instance so that it can be garbage collected.
The difference is that the servlet is in the server process.
It runs its service method in a multi-threaded manner,
An instance can serve multiple requests,
And its instances are not generally destroyed,
And CGI has a new process for each request,
After the service is finished, destroy it.

So it's less efficient than servlet.

go from  http://www.360doc.com/content/09/0522/22/152371_3613050.shtml