Servlet
XXXServlet extends HttpServlet(模板方法设计模式) extends GenericServlet(Servlet适配器类型) implements Servlet
javax.servlet.Servlet接口方法
public void init(ServletConfig config) throws ServletException {}
public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException {}
public void destroy() {}
public ServletConfig getServletConfig() {return null;}
public String getServletInfo() {return null;}
Servlet对象的生命周期表示：Servlet对象从最初的创建，到最终的销毁。
Servlet对象的创建，Servlet对象的方法被调用，Servlet对象的销毁，都是由WEB容器来负责管理的，
javaweb程序员不需要管理这些，主要负责：Servlet类的编写，service方法的实现，Servlet类在web.xml文件中的配置。
Servlet对象“默认情况”下，在服务器启动阶段是不会实例化的。不会创建对象。
Servlet对象的生命周期：
1) 用户打开浏览器在浏览器地址栏上输入URL：http://localhost:8080/oa/save，回车
2) WEB服务器截取请求路径，得知用户要访问的资源是：/oa/save
3) WEB服务器从整个容器中检索/oa/save请求路径对应的Servlet对象
4) 若找到了该Servlet对象
4-1) web容器负责调用该Servlet对象的service方法提供服务，处理请求
5) 若没有找到该Servlet对象
5-1) 通过请求路径/save找到对应的Servlet完整类名（web.xml文件支持的,web.xml文件在服务器启动阶段解析，路径和类名已经绑定在一起了）
5-2) 通过反射机制调用Servlet类的无参数构造方法完成Servlet对象的实例化操作。（Servlet对象已经创建完毕）
5-3) web容器调用该Servlet对象的init方法完成初始化操作。
5-4) web容器调用该Servlet对象的service方法提供服务，处理请求
6) 若“服务器关闭”或“webapp重新部署”或“长时间没有用户再访问该Servlet”，WEB容器
会销毁该Servlet对象占用的内存空间，web容器在销毁该Servlet对象之前，web容器负责
调用该Servlet对象的destroy方法，完成销毁之前的准备工作。
Servlet对象是单实例的，不符合单例模式，是一种伪单例，真单例的构造方法必须是私有化的。
Servlet对象是在多线程环境下运行的一个对象。【单实例多线程环境下运行的一个java对象】
之所以Servlet对象是单实例的，是因为该对象的创建是由WEB容器负责的，javaweb程序员不能干涉
总结：
1) 无参数构造方法只调用一次，对象只创建一个，对象是单例的
2) init方法只被调用一次，在对象创建之后马上执行它，完成初始化操作
3) service方法，只要用户发送请求一次，则执行一次
4) destroy方法也是只执行一次
注意：
init方法在执行的时候，对象已经存在了。
destroy方法在执行的时候，对象还没有被回收，还存在。
重点：
在Servlet类中最好不要手动编写任何构造函数，这样做可能会导致无参数构造函数不存在，
这样通过反射机制创建对象的时候，会出现实例化异常。Servlet对象创建失败。
错误代号：【HTTP状态号】
404 - 资源找不到，通常是路径问题,还有可能是项目本身启动失败
405 - 表示前端发送的请求方式和后台要求的请求方式不同。请求方式错误
500 - 服务器内部错误，通常是服务器中的java程序出现了异常
javax.servlet.ServletConfig接口方法
- String getInitParameter(String name) 通过初始化参数的name获取value
- Enumeration getInitParameterNames() 获取所有初始化参数的name
- ServletContext getServletContext() 获取ServletContext对象
- String getServletName() 【使用较少】
ServletConfig对象是“Servlet对象的配置信息对象”
Servlet对象的配置信息在web.xml文件中的<servlet></servlet>标签内部
ServletConfig对象封装了当前Servlet对象的配置信息。
通过ServletConfig对象可以获取该Servlet对象的相关配置信息。
一个Servlet对象对应一个ServletConfig对象,100个Servlet对象对应100个ServletConfig对象。
javax.servlet.ServletContext接口方法
- void setAttribute(String name, Object object) 向Servlet上下文中绑定一个数据object，起名name (map.put(key,value))
- Object getAttribute(String name) 从Servlet上下文中取object，通过name (Object value = map.get(key))
- void removeAttribute(String name) 移除Servlet上下文中的某个数据，通过name (map.remove(key))
- String getInitParameter(String name) 通过上下文参数的name获取上下文参数value
- Enumeration getInitParameterNames() 获取所有上下文参数的name
- String getRealPath(String path) 获取绝对路径
- InputStream getResourceAsStream(String path) 直接获取文件输入流
ServletContext是一个Servlet上下文对象
ServletContext对象是所有Servlet共享的一个四周环境对象
Context单词翻译：上下文
例如：contextPath就是上下文路径: /prj-servlet-06 【webapp的根路径】
ServletContext可以完成多个Servlet之间共享同一些数据。
ServletContext对象中封装了web.xml文件中所有信息，
ServletContext对象只有一个，web.xml文件也是只有一个
web.xml文件也是在服务器启动阶段被解析，ServletContext也是在服务器启动阶段被创建。
在同一个webapp中，ServletContext对象只有一个
在web服务器启动阶段被创建
在web服务器关闭的时候被销毁
ServletContext对象是一个应用级别的对象。
注：100个app对应100个ServletContext
一个Servlet对应一个ServletConfig，所有的Servlet共享一个ServletContext
通过ServletContext对象可以完成：跨用户传递数据
HTTP协议是什么?
- HTTP协议是一种超文本传输协议
- W3C制定的
- 浏览器和服务器之间提前制定好的一种数据传送格式
HTTP协议包括：请求协议和响应协议
- 请求协议：浏览器向服务器发送数据的时候，数据传送格式
- 响应协议：服务器向浏览器发送数据的时候，数据传送格式
请求协议包括以下四部分：
- 请求行
- 消息报头
- 空白行
- 请求体
响应协议包括以下四部分：
- 状态行
- 消息报头
- 空白行
- 响应体[响应正文]
只有一种方式是POST请求，使用form表单提交数据，并且同时form标签的method属性设置为method="POST"，剩下任何一种请求，一律都是GET方式。
请求协议：基于get方式
GET /prj-servlet-08/user/login?username=admin&password=123 HTTP/1.1 请求行
Accept: text/html, application/xhtml+xml, */* 消息报头
Referer: http://localhost:8080/prj-servlet-08/ 消息报头
Accept-Language: zh-CN 消息报头
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) 消息报头
Accept-Encoding: gzip, deflate 消息报头
Host: localhost:8080 消息报头
Connection: Keep-Alive 消息报头
空白行
请求体
注：
第一：请求行由三部分组成：请求方式、URI、协议版本号
第二：若请求是GET请求，在请求行中发送数据，格式：uri?name=value&name=value.....
第三：GET请求最终浏览器地址栏上会将提交的数据显示出来
请求协议：基于POST方式
POST /prj-servlet-08/user/login HTTP/1.1 请求行
Accept: text/html, application/xhtml+xml, */* 消息报头
Referer: http://localhost:8080/prj-servlet-08/ 消息报头
Accept-Language: zh-CN 消息报头
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) 消息报头
Content-Type: application/x-www-form-urlencoded 消息报头
Accept-Encoding: gzip, deflate 消息报头
Host: localhost:8080 消息报头
Content-Length: 27 消息报头
Connection: Keep-Alive 消息报头
Cache-Control: no-cache 消息报头
空白行
username=admin&password=123 请求体
注：
第一：请求行由三部分组成：请求方式、URI、协议版本号
第二：若请求是POST请求，在请求体中发送数据，格式：name=value&name=value.....
第三：POST请求最终浏览器地址栏上不会将提交的数据显示出来，因为不是在请求行上发送的数据
HTTP协议中包含8种请求方法：
GET 请求获取Request-URI 所标识的资源
POST 在Request-URI 所标识的资源后附加新的数据
HEAD 请求获取由Request-URI 所标识的资源的响应消息报头
PUT 请求服务器存储一个资源，并用Request-URI 作为其标识
DELETE 请求服务器删除Request-URI 所标识的资源
TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求
GET和POST只和请求有关系，和响应无关。无论发送的请求是GET请求还是POST请求，响应协议只有一种格式：
HTTP/1.1 200 OK 状态行
Server: Apache-Coyote/1.1 消息报头
Content-Type: text/html;charset=UTF-8 消息报头
Content-Length: 129 消息报头
Date: Sat, 30 Jan 2016 03:28:29 GMT 消息报头
空白行
<html><head><title>login result</title></head><body><h1 align='center'> 响应体
<font color='red'>login success!</font></h1></body></html>
注：
第一：状态行由三部分组成：协议版本号、响应状态号、状态描述信息
* 响应状态号：【HTTP协议规定的】
- 404 资源找不到
- 500 服务器内部错误
- 200 请求响应完整成功结束
...
状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK 客户端请求成功
400 Bad Request 客户端请求有语法错误，不能被服务器所理解
401 Unauthorized 请求未经授权
403 Forbidden 服务器收到请求，但是拒绝提供服务
404 Not Found 请求资源不存在
500 Internal Server Error 服务器发生不可预期的错误
503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后， 可能恢复正常
405 浏览器客户端发送的请求和底层的方法doPost/doGet不一致导致的。
第二：消息报头包括
* 响应的服务器版本
* 响应的内容类型以及字符编码方式
* 响应长度，字节为单位
* 响应时间
第三：空白行
分离消息报头和响应体的关建行
第四：响应体会显示到网页中。浏览器解释执行HTML代码
GET请求和POST请求在表面上的区别：
- GET请求最终提交的数据会显示到浏览器地址栏上，在请求行上提交数据
- POST请求在请求体中提交数据，不会显示到浏览器地址栏上
- GET请求只能提交普通字符串，因为GET请求在请求行上提交数据
- POST请求不但可以提交普通字符串，而且还可以提交图片等文件
- GET请求提交的字符串长度有限制，只能提交少量数据，这也是因为GET请求在请求行上提交数据
- POST请求提交数据理论上无长度限制，可以提交大数据，这也是因为POST请求在请求体中提交数据
- GET请求最终的请求结果，会存放到浏览器缓存中。【支持Cache】
- POST请求最终的请求结果，不会被放到浏览器缓存中。【不支持Cache：no cache】
注：缓存是一种优化策略，减少IO，提高程序执行效率的重要手段，浏览器也不例外，为了降低服务器的压力，浏览器也是 支持缓存机制的。
GET请求和POST请求怎么选择呢？
- 大多数都是使用GET请求
- 提交的数据中有敏感信息，必须使用POST
- 提交的数据不是普通字符串，例如文件上传，必须使用POST
- 提交的数据长度过长，必须使用POST
- 若请求是读取服务器端的资源，一般都是使用GET请求。读取的资源不会频繁的发生变化，所以这种请求有必要缓存起来。 以提高访问效率
- 若请求是修改服务器端的资源，一般都是使用POST请求。因为每一次修改之后的结果大部分都是不一样的，没有必要缓 存。
javax.servlet.http.HttpServlet接口
POST请求，请重写doPost方法
GET请求，请重写doGet方法
javax.servlet.http.HttpServletRequest接口方法
- String getParameter(String name) 通过参数的name获取参数的value【实际上：获取Map集合中一维数组的首元素】
- String[] getParameterValues(String name) 通过参数Map集合的key获取value，返回的是一个一维数组，适合于checkbox 数据的获取
- Map<String,String[]> getParameterMap() 通过request获取参数Map集合
- Enumeration getParameterNames() 获取所有参数name
- Object getAttribute(String name)
- void setAttribute(String name, Object o)
- void removeAttribute(String name)
- String getRemoteAddr() 通过request对象获取客户端IP地址
- String getContextPath() 获取应用程序的根路径
- String getMethod() 获取请求方式
- String getRequestURI() 获取URI
- StringBuffer getRequestURL() 获取URL
- String getServletPath() 获取servlet路径(url-pattern标签中的路径)
- HttpSession getSession() 获取session对象，若没有获取到session对象，则新建session对象
- HttpSession getSession(boolean create) 获取session对象，若没有获取到session对象，参数为true则新建session对象， 参数为false则返回null
- void setCharacterEncoding(String env) 解决POST请求中的乱码
- Cookie[] getCookies() 从request对象中获取所有提交的Cookie
- RequestDispatcher getRequestDispatcher(String path) 获取请求转发器，转发器指向要转发的路径，调用转发器对象的 forward方法，完成请求转发
javax.servlet.RequestDispatcher接口
- void forward(ServletRequest request,ServletResponse response);
HttpServletRequest是一个请求对象，该对象中包装了HTTP请求协议的全部信息。
表单提交的数据都在request对象中，面向request可以获取表单中的数据。
一次请求对应一个request对象。10次请求对应10个不同的request对象。
乱码可能出现在哪里?
1) 数据“传递”过程中的乱码
2) 数据“展示”过程中的乱码
3) 数据“保存”过程中的乱码
浏览器在提交表单数据的时候，采用ISO-8859-1的这种编码方式提交数据的。
只能解决POST请求中的乱码问题：
- request.setCharacterEncoding("UTF-8");
- 以上代码在从request对象中获取任何数据之前设置有效果
- 以上的代码只对请求体中的数据进行编码，无法对请求行上的数据进行编码，所以只能解决POST，不能解决GET
只能解决GET请求中的乱码问题：
- 修改CATALINA_HOME/conf/server.xml文件
- <Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8"/>
- server.xml文件中的Connector标签中可以编写什么属性呢？
* 参考：C:\tomcat7\webapps\docs\config\http.html
* port 设置端口号
* URIEncoding 设置URI的编码方式
* maxThreads 设置Tomcat服务器可支持的最大线程数量
* ....
GET和POST通用：
String username = request.getParameter("username");
//将username通过ISO-8859-1的编码方式进行解码还原，回归最原始的二进制码
byte[] bytes = username.getBytes("ISO-8859-1");
//再找一种编码方式，要求这种编码方式和浏览器上的编码方式一致，进行重新编码【重新组装】
username = new String(bytes,"UTF-8");
响应时解决乱码问题：
- response.setContentType("text/html;charset=UTF-8");
javax.servlet.http.HttpServletResponse接口方法
- PrintWriter getWriter()
java.io.PrintWriter
- print(String str)
Servlet的线程安全，对于多线程来说,JVM内存中方法区和堆区内存空间是共享的，栈内存空间是独立的，一个线程一个栈。
- 局部变量内存不共享，所以局部变量不存在线程安全问题
- 静态变量和实例变量，静态变量在方法区中，实例变量堆内存的java对象内部，静态变量和实例变量存在线程安全问题
解决方案：
第一种方案：尽量使用局部变量代替实例变量
第二种方案：若必须使用实例变量，那么可以考虑，让对象变成多例，不再是单例。
第三种方案：若必须使用实例变量，必须是单例的，这个时候必须使用线程同步机制：synchronized
注意：使用线程同步机制，是不得以的时候再使用，因为这种方式会让程序的吞吐量降低，用户排队访问，用户体验差。
转发机制(forward)和重定向机制(redirect)
转发：
request.getRequestDispatcher("/b").forward(request,response);
转发是一次请求
转发是request对象触发的
转发的资源路径中不需要添加contextPath
转发只能完成项目内部资源的跳转
重定向：
response.sendRedirect("/prj-servlet-16/b");
重定向是两次请求
重定向是response对象触发的
重定向的资源路径需要添加contextPath
重定向可以完成跨项目资源跳转
重定向可以解决页面刷新问题(操作数据的请求若使用转发，每次刷新都会在数据库操作一次)
Cookie：
- Cookie这种机制是HTTP协议规定的，只要是基于HTTP协议，就有Cookie的存在。
- Cookie可以保存会话状态，但是这个会话状态是保留在客户端上。
- 只要Cookie清除，或者Cookie失效，这个会话状态就没有了。
- Cookie是保存在浏览器客户端上的
- Cookie可以保存在浏览器的缓存中，浏览器关闭Cookie消失
- Cookie也可以保存在客户端的硬盘文件中，浏览器关闭Cookie还在，除非Cookie失效。
javax.servlet.http.Cookie类
创建Cookie对象
Cookie cookie = new Cookie(String cookieName,String cookieValue);
设置Cookie的关联路径
cookie.setPath(request.getContextPath() + "/king");
设置Cookie的有效期为1小时
cookie.setMaxAge(60 * 60);
将Cookie对象发送给浏览器客户端
response.addCookie(cookie);
服务器可以一次向浏览器发送多个Cookie
默认情况下，服务器发送Cookie给浏览器之后，浏览器将Cookie保存在缓存当中，只要不关闭浏览器，Cookie永远存在，并且有效。
当浏览器关闭之后，缓存中的Cookie被清除。
浏览器会不会提交发送这些Cookie给服务器，和请求路径有关系。
请求路径和Cookie是紧密关联的。
不同的请求路径会发送提交不同的Cookie
假如获取Cookie时的路径是 ：
http://127.0.0.1:8080/PrjCookies/servlet/getCookie
将来发送Cookie的路径包括如下路径 ：
http://127.0.0.1:8080/PrjCookies/servlet/getCookie（相同路径）
http://127.0.0.1:8080/PrjCookies/servlet/xxxxx（同目录）
http://127.0.0.1:8080/PrjCookies/servlet/xxxxx/xxxx（子目录）
默认情况下，没有设置Cookie的有效时长，该Cookie被默认保存在浏览器的缓存当中，只要浏览器不关闭Cookie存在，
只要关闭浏览器Cookie消失，我们可以通过设置Cookie的有效时长，以保证Cookie保存在硬盘文件当中。但是这个有效时长
必须是>0的。换句话说，只要设置Cookie的有效时长大于0，则该Cookie会被保存在客户端硬盘文件当中。有效时长过去之后，
则硬盘文件当中的Cookie失效。
cookie有效时长 = 0 直接被删除
cookie有效时长 < 0 不会被存储
cookie有效时长 > 0 存储在硬盘文件当中
url-pattern的编写方式和路径的总结：
1、路径的编写形式：
- <a href="/项目名/资源路径"></a>
- <form action="/项目名/资源路径"></form>
- 重定向：response.sendRedirect("/项目名/资源路径");
- 转发：request.getRequestDispatcher("/资源路径").forward(request,response);
- 欢迎页面
<welcome-file-list>
<welcome-file>资源路径</welcome-file>
</welcome-file-list>
- servlet路径
<servlet>
<servlet-name>hello</servlet-name>
<servlet-class>com.bjpowernode.javaweb.servlet.HelloServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>hello</servlet-name>
<url-pattern>/资源路径</url-pattern>
</servlet-mapping>
- Cookie设置path
cookie.setPath("/项目名/资源路径");
- ServletContext
ServletContext application = config.getServletContext();
application.getRealPath("/WEB-INF/classes/db.properties");
application.getRealPath("/资源路径");
2、url-pattern的编写方式
精确匹配
<url-pattern>/hello</url-pattern>
<url-pattern>/system/hello</url-pattern>
扩展匹配
<url-pattern>/abc/*</url-pattern>
后缀匹配
<url-pattern>*.action</url-pattern>
<url-pattern>*.do</url-pattern>
全部匹配
<url-pattern>/*</url-pattern>
javax.servlet.http.HttpSession接口方法
-void setAttribute(String name, Object value)
-Object getAttribute(String name)
-void removeAttribute(String name)
-void invalidate() 销毁session
Cookie可以将会话状态保存在客户端，HttpSession可以将会话状态保存在服务器端。
HttpSession对象是一个会话级别的对象，一次会话对应一个HttpSession对象。
在WEB容器中，WEB容器维护了大量的HttpSession对象，换句话说，在WEB容器中应该有一个“session列表”，
- 打开浏览器，在浏览器上发送首次请求
- 服务器会创建一个HttpSession对象，该对象代表一次会话
- 同时生成HttpSession对象对应的Cookie对象，并且Cookie对象的name是JSESSIONID，Cookie的value是32位长度的字符串
- 服务器将Cookie的value和HttpSession对象绑定到session列表中
- 服务器将Cookie完整发送给浏览器客户端
- 浏览器客户端将Cookie保存到缓存中
- 只要浏览器不关闭，Cookie不会消失
- 当再次发送请求的时候，会自动提交缓存当中的Cookie
- 服务器接收到Cookie，验证该Cookie的name确实是：JSESSIONID，然后获取该Cookie的value
- 通过Cookie的value去session列表中检索对应的HttpSession对象。
和HttpSession对象关联的这个Cookie的name是比较特殊的，在java中就叫做：jsessionid
- 浏览器禁用Cookie，则浏览器缓存中不再保存Cookie
- 导致在同一个会话中，无法获取到对应的会话对象
- 禁用Cookie之后，每一次获取的会话对象都是新的
浏览器禁用Cookie之后，若还想拿到对应的Session对象，必须使用URL重写机制,怎么重写URL:
http://localhost/prj-servlet-21/user/accessMySelfSession;jsessionid=D3E9985BC5FD4BD05018BF2966863E94
重写URL会给编程带来难度/复杂度，所以一般的web站点是不建议禁用Cookie的。建议浏览器开启Cookie
- 浏览器关闭之后，服务器不会销毁session对象
- 因为B/S架构的系统基于HTTP协议，而HTTP协议是一种无连接/无状态的协议
- 什么是无连接/无状态?
* 请求的瞬间浏览器和服务器之间的通道是打开的，请求响应结束之后，通道关闭
* 这样做的目的是降低服务器的压力。
session对象在什么时候被销毁?
- web系统中引入了session超时的概念。
- 当很长一段时间（这个时间可以配置）没有用户再访问该session对象，此时session对象超时，web服务器自动回收session对象。
- 可配置:web.xml文件中，默认是30分钟
<session-config>
<session-timeout>120</session-timeout>
</session-config>
一般多数情况下，是这样描述的：用户打开浏览器，在浏览器上进行一些操作，然后将浏览器关闭，表示一次会话结束。
- 本质上的描述：从session对象的创建，到最终session对象超时之后销毁，这个才是真正意义的一次完整会话。
ServletContext、HttpSession、HttpServletRequest接口的对比：
以上都是范围对象:
ServletContext application; 是应用范围
HttpSession session; 是会话范围
HttpServletRequest request; 是请求范围
三个范围的排序：
application > session > request
application完成跨会话共享数据、
session完成跨请求共享数据，但是这些请求必须在同一个会话当中、
request完成跨Servlet共享数据，但是这些Servlet必须在同一个请求当中【转发】
使用原则：有小到大尝试，优先使用小范围。
例如：登录成功之后，已经登录的状态需要保存起来，可以将登录成功的这个状态保存到session对象中。
登录成功状态不能保存到request范围中，因为一次请求对应一个新的request对象。
登录成功状态也不能保存到application范围中，因为登录成功状态是属于会话级别的，不能所有用户共享。
---------------------------------------------------------------------------------------------------------------------------------------------
web.xml：
web.xml文件在服务器启动阶段被解析，若web.xml文件编写有错误，启动Tomcat服务器的时候，当前webapp启动失败。
修改web.xml文件并保存之后，Tomcat服务器会自动重新解析web.xml文件，这个时候，就相当于项目重新部署了。
当前web站点没有设置任何欢迎页面的话，欢迎页面是：index.html、index.htm、index.jsp，
因为在CATALINA_HOME/conf/web.xml文件中有全局配置，在当前webapp中配置的欢迎页面属于局部配置，局部优先(就近原则)
注意：
欢迎页面可以设置多个，第一个优先级最高，以此类推
欢迎页面路径问题：不需要以“/”开始，但是从WebRoot作为起点
欢迎页面也可以是一个Servlet
web.xml文件中的标签：
#上下文参数，这些配置信息自动被封装到ServletContext对象中
<context-param>
<param-name>xxx</param-name>
<param-value>xxx</param-value>
</context-param>
<servlet>
<servlet-name>xxx</servlet-name>
<servlet-class>xxx.xxx.xxx.xxx</servlet-class>
#该标签表示在服务器启动阶段加载Servlet，完成实例化和初始化。数字越小，优先级越高
<load-on-startup>0</load-on-startup>
#初始化参数可以被自动封装到ServletConfig对象中
<init-param>
<param-name>xxx</param-name>
<param-value>xxx</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>xxx</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>120</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>xxx.html</welcome-file>
<welcome-file>xxx/xxx.html</welcome-file>
<welcome-file>(url-pattern)</welcome-file>
</welcome-file-list>