javaWeb：
1、继承关系：HttpServlet(实现类) -> GenericServlet(抽象类) -> Servlet(接口)
Servlet中的核心方法：innit()，service()，destroy()
2、服务方法service()：
1) 当有请求过来时，service方法会自动响应(其实是tomcat容器调用的)
2) 之后HttpServlet会分析请求的方式：到底是get、post、head还是delete等等
3) 然后决定调用的是哪个do开头的方法
4) 如果在调用继承HttpServlet的类的某do开头的方法时没有，则自动调用HttpServlet中
的某do开头的方法，然而HttpServlet中所有do开头的方法都会抛出一个405的错误
5) 因此，我们在新建Servlet时，我们才会去考虑请求方法，从而决定重写哪个do方法
3、Servlet的生命周期：
1) 生命周期：从出生到死亡的过程就是生命周期。对应Servlet中的三个方法：init()，service()，destroy()
2) 默认情况下：
1.第一次接收请求这个Servlet会进行实例化(tomcat调用构造方法)、初始化(调用init())、然后服务(调用service())
2.从第二次请求开始，每一次接收请求都只执行服务
3.当tomcat容器关闭时，其中的所有的servlet实例化会被销毁，调用销毁方法
3) 通过案例发现：
1.Servlet实例，tomcat只会创建一个，所有的请求都是这个实例去响应
2.默认情况下，第一次请求时，tomcat才回去实例化，初始化，再服务
3.默认的Servlet实例都是在tomcat容器配置后进行，但是我们可以通过在xml文件中
的<servlet>中添加<load-on-startup>填写数字最小为0</load-on-startup>
4.这样可以在tomcat容器配置好前将Servlet实例好
4) Servlet在容器中是单例的、线程不安全的
1.单例：所有的请求都是同一个实例去响应
2.线程不安全：共享资源出现覆写问题
3.启发：尽量不要在servlet中定义成员变量，如果不得不定义，则不要去修改或者用来逻辑判断
4、Http协议：
1) Http称之为超文本传输协议
2) Http是无状态的
3) Http请求响应包含两个部分：请求和响应
1.请求包含三个部分：
请求行：包含请求的方式、请求的文件地址、请求的协议(一般都是HTTP1.1)
请求信息头：包含很多浏览器需要告诉服务器的信息，比如：我的浏览器型号、版本、我能接收的
内容的类型等
请求体：三种情况
get方式，没有请求体，但是有一个queryString
post方式，有请求体，form data
json格式(前后端分离会用到)，有请求体，request payload
2.响应包含三个部分：
相应行：协议、响应状态码、响应状态
响应头：包含了服务器的信息，服务器发送给浏览器的信息(内容的媒体类型、编码、内容长度等)
响应体：响应的实际内容(比如请求add.html页面时，响应的内容就是<html>...)
5、会话：
1) Http是无状态的：
1.HTTP无状态：服务器无法判断两次请求是否是同一个客户端发送过来的；
2.无状态带来的现实问题：第一次请求是添加商品到购物车，第二次请求是结账，如果不能识别两次请求
是否是同一个客户端发出则会产生巨大问题
3.通过会话跟踪结束来解决无状态的问题
2) 会话跟踪技术：
1.客户端第一次发请求给服务器，服务器获取session，获取不到，则创建新的，然后响应给客户端；
2.下次客户端给服务器发请求时，会把sessionID带给服务器，服务器进行识别
3.常用的API：
request.getSession() -> 获取当前的会话，没有则创建一个新的会话
request.getSession(true) -> 效果和不带参数相同
request.getSession(false) -> 获取当前会话，没有则返回null，不会创建新的
request.getId() -> 获取sessionID
request.isNew() -> 判断当前session是否是新的
request.getMaxInactiveInterval() -> session的非激活间隔时长 默认1800秒，
意思就是不操作半小时需要重新连接
request.setMaxInactiveInterval()
session.invalidate() -> 强制性会话立即失效
3) session保存作用域：作用域里保存着客户端上传到作用域里的数据
1.每一个客户端都有专门的session作用域，且每个客户端只能访问自己的作用域
2.常用的API：
void session.setAttribute(k,v)
object session.getAttribute(k)
void removeAttribute(k)
6、服务器内部转发以及客户端重定向：
1) 服务器内部转发：request.getRequestDispatcher("组件二(xml中servlet-mapping的url-pattern值)").forward(request,response)
1.客户端发请求到服务器中的组件1
2.之后组件1调用该方法后会发请求给服务器中的组件2
3.最后组件2执行完处理后发响应给客户端
4.浏览器地址不变，客户端依旧认为是组件1执行的需求
2) 客户端重定向：response.sendRedirect("组件二(xml中servlet-mapping的url-pattern值)")
1.客户端发请求到服务器中的组件1
2.之后组件1调用该方法后会发带有组件2的信息的响应给客户端
3.客户端收到组件1的响应后立即发请求给组件2
4.最后组件2执行完处理后发响应给客户端
5.浏览器地址栏会从组件1改为组件2的地址，客户端知道是组件2执行的需求
7、转发 & 重定向
1)转发：转发的就是一个请求处理了一部分功能，然后开始另一个请求处理剩下的功能. 其本质就是一个请求，转发是共享request， response对象 ，因此可以把需要转发的数据保存在request对象中。浏览器的地址栏地址保存不变。(显示第一个请求的地址)
2)重定向：重定向是一个请求的功能完成了，然后开启另一个请求，做另一个功能。 本质是两个请求。（第一个请求是我们主动发的， 第二个请求是浏览器收到302代码和重定向的url地址， 然后浏览器主动发送的请求。）重定向因为是两个不同的请求，所以是两个不同的request对象，因此不能共享数据。浏览器地址栏的地址是显示重定向的地址。（显示第二个请求的地址）
8、cookie的使用：
1)cookie: 用于保存客户端的状态的计数。 当我们有多次请求的时候，这个多次请求被看做一个整体，这个整体中有些数据需要保存的时候，可以使用cookie，把数据保存在浏览器中。
2)cookie使用的方式：
服务器端代码中，创建cookie对象，在response中添加cookie客户端访问服务器的时候，会将把当前访问路径有关的cookie发送到服务器端服务器端可以在request中获取到cookie数据，然后对这些数据进行使用浏览器可以设置禁用cookie，或者用户可以删除cookie数据，用户可以查看到cookie数据，所以重要数据不能直接保存在cookie中。cookie中存储的是string ， 并且存储的数据大小也有限。cookie 可以设置有效期，过期之后，cookie会被浏览器清除掉。
Thymleleaf：
1、渲染(render)：在HTML页面加载java内存中的数据，这个过程称之为渲染
2、Thymeleaf：是用来帮助我们做视图渲染的一个技术
3、Thymeleaf使用方法：
1) 添加thymeleaf的jar包
2) 新建一个Servlet类——ViewBaseServlet
3) 在web.xml文件中添加配置
1.配置前缀：view-prefix
2.配置后缀：view-suffix
4) 使得我们的Servlet继承ViewBaseServlet
5) 根据逻辑视图名称得到物理视图名称
// 此处的视图名称是index
// 那么thymeleaf会将这个逻辑视图名称对应到物理视图名称上去
// 逻辑视图名称：index
// 物理视图名称：view-prefix + 逻辑视图名称 + view-suffix
// 所以真实的视图名称是：/index.html
4、在这个项目中出现了一个很神奇的bug，点击新增后页面不跳转，经过反复测试得出：
在add.html的form表单中，使用
<form th:action="@{/edit.flush}" method="post">不能使用
<form action="edit.flush" method="post">才行。
是因为thymeleaf不能作用于静态页面，也就是没有引用后端数据的html，
而这里的add.html刚好就是没用引用后端数据的页面，不能用action跳转
本文详细介绍了Servlet的继承结构、核心方法、生命周期、会话管理以及Http协议的特点。强调了Servlet的单例与线程不安全性质，并讨论了会话跟踪技术解决无状态问题的方法。同时，讲解了服务器内部转发与客户端重定向的区别。此外，还探讨了Thymeleaf在视图渲染中的作用，以及在实际项目中遇到的神奇bug及其解决方案。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
