Servelet笔记

Servelet笔记：
1. multithread
Only one instance of a particular servlet is created, and each request for that servlet passes through the same object. This strategy helps the container make
the best use of available resources. The tradeoff is that the servlet's doGet() and doPost() methods must be programmed in a thread-safe manner.
A Web container will typically create a thread to handle each request. If you want to ensure that a servlet instance handles only one request at a time, a servlet
can implement the SingleThreadModel interface. If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the
servlet's service method. A Web container can implement this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of
Web component instances and dispatching each new request to a free instance. This interface does not prevent synchronization problems that result from Web
components accessing shared resources such as static class variables or external objects.
Resolution:
1. implements SingleThreadModel
2. synchronized the instance variable
3. Avoid using the instance variable
在Serlet中避免使用实例变量是保证Servlet线程安全的最佳选择。从Java 内存模型也可以知道，方法中的临时变量是在栈上分配空间，
而且每个线程都有自己私有的栈空间，所以它们不会影响线程的安全。
(实例变量是在堆中分配的,并被属于该实例的所有线程共享，所以不是线程安全的.)
1、栈区（stack）— 由编译器自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈。
2、堆区（heap） — 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收 。注意它与数据结构中的堆是两回事，分配方式倒是类似于链表。
JSP中用到的OUT,REQUEST,RESPONSE,SESSION,CONFIG,PAGE,PAGECONXT是线程安全的,APPLICATION在整个系统内被使用,所以不是线程安全的.
静态函数只有在内部引用了静态变量的时候，才会出现多线程同步问题。   
 静态函数内部创建的变量，在每个线程调用时都会另行创建，不会共用一个存储单元。   
 但是对于类中的静态成员，在类加载后就占用一个存储区，每个线程访问到该静态成员时，   
 都是对那个公共的存储区操作。   
 下面这段代码对比一下：   
 public   class   a{   
     static   string   name1="";   
     string   name2="";   
     public   static   string   setname1(string   name){   
           this.name1=name;   
     }   
     public   static   string   setname2(string   name){   
           this.name2=name;   
     }   
 }   
 使用这2个静态方法时，setname1会出现多线程同步问题。setname2不会
 
一，servlet容器如何同时处理多个请求。

Servlet采用多线程来处理多个请求同时访问，Servelet容器维护了一个线程池来服务请求。
线程池实际上是等待执行代码的一组线程叫做工作者线程(Worker Thread)，Servlet容器使用一个调度线程来管理工作者线程(Dispatcher Thread)。

当容器收到一个访问Servlet的请求，调度者线程从线程池中选出一个工作者线程，将请求传递给该线程，然后由该线程来执行Servlet的service方法。
当这个线程正在执行的时候，容器收到另外一个请求，调度者线程将从池中选出另外一个工作者线程来服务新的请求，容器并不关系这个请求是否访问的是同一个Servlet还是另外一个Servlet。
当容器同时收到对同一Servlet的多个请求，那这个Servlet的service方法将在多线程中并发的执行。

2.
The ServletContext interface [javax.servlet.ServletContext] defines a servlet's view of the web application within which the servlet is running. It is accessible in a servlet
via the getServletConfig() method, and in a JSP page as the application implicit variable. Servlet contexts provide several APIs that are very useful in building web
applications:
Access To Web Application Resources - A servlet can access static resource files within the web application using the getResource() and getResourceAsStream() methods.
Servlet Context Attributes - The context makes available a storage place for Java objects, identified by string-valued keys. These attributes are global to the
entire web application, and may be accessed by a servlet using the getAttribute(), getAttributeNames(), removeAttribute(), and setAttribute() methods. From a JSP page,
servlet context attributes are also known as "application scope beans".

3.
One of the key characteristics of HTTP is that it is stateless. In other words, there is nothing built in to HTTP that identifies a subsequent request from the
same user as being related to a previous request from that user. This makes building an application that wants to engage in a conversation with the user over several
requests to be somewhat difficult. To alleviate this difficulty, the servlet API provides a programmatic concept called a session, represented as an object that
implements the javax.servlet.http.HttpSession interface. The servlet container will use one of two techniques (cookies or URL rewriting) to ensure that the next
request from the same user will include the session id for this session, so that state information saved in the session can be associated with multiple requests.
This state information is stored in session attributes (in JSP, they are known as "session scope beans"). To avoid occupying resources indefinitely when a user
fails to complete an interaction, sessions have a configurable timeout interval. If the time gap between two requests exceeds this interval, the session will
be timed out, and all session attributes removed. You define a default session timeout in your web application deployment descriptor, and you can dynamically
change it for a particular session by calling the setMaxInactiveInterval() method. Unlike requests, you need to be concerned about thread safety on your session
attributes (the methods these beans provide, not the getAttribute() and setAttribute() methods of the session itself). It is surprisingly easy for there to be
multiple simultaneous requests from the same user, which will therefore access the same session. Another important consideration is that session attributes
occupy memory in your server in between requests. This can have an impact on the number of simultaneous users that your application can support. If your
application requirements include very large numbers of simultaneous users, you will likely want to minimize your use of session attributes, in an effort to
control the overall amount of memory required to support your application.

4.
The original MVC pattern is like a closed loop: The View talks to the Controller, which talks to the Model, which talks to the View.
But, a direct link between the Model and the View is not practical for web applications, and we modify the classic MVC arrangement so that it would look less like a
loop and more like a horseshoe with the controller in the middle.
In the MVC/Model 2 design pattern, application flow is mediated by a central Controller.
The Controller delegates requests - in our case, HTTP requests - to an appropriate handler. The handlers are tied to a Model, and each handler
acts as an adapter between the request and the Model. The Model represents, or encapsulates, an application's business logic or state. Control is usually then
forwarded back through the Controller to the appropriate View. The forwarding can be determined by consulting a set of mappings, usually loaded from a database or
configuration file. This provides a loose coupling between the View and Model, which can make applications significantly easier to create and maintain.