侵入式、状态管理

一、什么是侵入式和非侵入式编程？

侵入式：引入了框架，对现有的类的结构有影响，需要实现框架的某些接口或者某些特定的类。是用户的代码对框架产生了依赖，不利于代码的复用性，将框架去除后，程序无法运行。好处是使用户代码与框架更好的结合，充分利用了框架提供的功能。

非侵入式：引入框架，对现有的类的结构没有影响，不需要实现某些接口和特定类。移出框架程序也可正常运行。缺点与用户代码互动的方式可能比较复杂；优点没有过多的依赖，能够很方便的迁移到其他地方。

二、状态管理介绍

1.首先要了解什么状态管理？

WEB应用中的会话是指一个客户端浏览器与WEB服务器之间连续发生的一系列请求和响应过程。 WEB应用的会话状态是指WEB服务器与浏览器在会话过程中产生的状态信息，借助会话状态，WEB服务器能够把属于同一会话中的一系列的请求和响应过程关联起来并达成数据共享。

2.为什么需要状态管理？

HTTP协议是无状态的，不能保存每次提交的信息，即当服务器返回与请求相对应的应答之后，这次事务的所有信息就丢掉了。 如果用户发来一个新的请求，服务器无法知道它是否与上次的请求有联系。 对于那些需要多次提交数据才能完成的Web操作，比如登录来说，就成问题了。通俗一点的例子就是，我们登录了在Github页面登录了，关闭页面之后，再次打开页面是不是发现你的Github还是保持你的账号登录的状态呢？这就是状态管理的作用！

3.状态管理的两种常见模式

客户端状态管理技术：将状态保存在客户端。代表性的是Cookie技术。

服务器状态管理技术：将状态保存在服务器端。代表性的是Session技术（服务器传递SessionID时需要使用Cookie的方式）。

（1） 什么是Cookie

​ Cookie是在浏览器访问WEB服务器的某个资源时，由WEB服务器在HTTP响应消息头中附带传送给浏览器的一小段数据，WEB服务器传送给各个客户端浏览器的数据是可以各不相同的。​ 一旦WEB浏览器保存了某个Cookie，那么它在以后每次访问该WEB服务器时，都应在HTTP请求头中将这个Cookie回传给WEB服务器。​ WEB服务器通过在HTTP响应消息中增加Set-Cookie响应头字段将Cookie信息发送给浏览器，浏览器则通过在HTTP请求消息中增加Cookie请求头字段将Cookie回传给WEB服务器。​ 一个Cookie只能标识一种信息，它至少含有一个标识该信息的名称（NAME）和设置值（VALUE）。​ 一个WEB站点可以给一个WEB浏览器发送多个Cookie，一个WEB浏览器也可以存储多个WEB站点提供的Cookie。​ 浏览器一般只允许存放300个Cookie，每个站点最多存放20个Cookie，每个Cookie的大小限制为4KB。但是要知道现在的技术可以传输数据的方式有很多，而且浏览器也可以对Cookie存放的最大数量做扩容机制，所以改限制不是一成不变的！

 Cookie的共享范围：

cookie 一般都是由于用户访问页面而被创建的，可是并不是只有在创建 cookie 的页面才可以访问这个cookie。在默认情况下，出于安全方面的考虑，只有与创建 cookie 的页面处于同一个目录或在创建cookie页面的子目录下的网页才可以访问。那么此时如果希望其父级或者整个网页都能够使用cookie，就需要进行路径的设置。

关于Cookie的共享范围，默认是同一项目下。而设置"/"可以在同意服务器下共享

 发送Cookie的条件：

浏览器在发送请求之前，首先会根据请求url中的域名在cookie列表中找所有与当前域名一样的cookie，然后再根据指定的路径进行匹配，如果当前请求在域匹配的基础上还与路径匹配那么就会将所有匹配的cookie发送给服务器。

Cookie的优缺点：

优点：

• 可配置到期规则： Cookie 可以在浏览器会话结束时到期，或者可以在客户端计算机上无限期存在，这取决于客户端的到期规则，不需要任何服务器资源，Cookie 存储在客户端并在发送后由服务器读取。
• 简单性： Cookie 是一种基于文本的轻量结构，包含简单的键值对。
• 数据持久性： 虽然客户端计算机上 Cookie 的持续时间取决于客户端上的 Cookie 过期处理和用户干预，Cookie 通常是客户端上持续时间最长的数据保留形式。

缺点：

• 大小受到限制： 大多数浏览器对 Cookie 的大小有 4096 字节的限制，尽管在当今新的浏览器和客户端设备版本中，支持 8192 字节的 Cookie 大小已愈发常见。
• 用户配置为禁用： 有些用户禁用了浏览器或客户端设备接收 Cookie 的能力，因此限制了这一功能。
• 潜在的安全风险： Cookie 可能会被篡改。用户可能会操纵其计算机上的 Cookie，这意味着会对安全性造成潜在风险或者导致依赖于Cookie 的应用程序失败。

（2）什么是Session

Session用于跟踪客户端的状态。Session指的是在一段时间内，单个客户与Web服务器的一连串相关的交互过程。 在一个Session中，客户可能会多次请求访问同一个网页，也有可能请求访问各种不同的服务器资源。

工作原理：

session被用于表示一个持续的连接状态，在网站访问中一般指代客户端浏览器的进程从开启到结束的过程。session其实就是网站分析的访问（visits）度量，表示一个访问的过程。

​ session的常见实现形式是cookie（session cookie），即未设置过期时间的cookie，这个cookie的默认生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。实现机制是当用户发起一个请求的时候，服务器会检查该请求中是否包含sessionid，如果未包含，则Tomcat会创造一个名为JSESSIONID的输出 cookie返回给浏览器(只放入内存，并不存在硬盘中)，并将其以HashTable（键值对）的形式写到服务器的内存里面；当已经包含sessionid时，服务端会检查找到与该session相匹配的信息，如果存在则直接使用该sessionid，若不存在则重新生成新的 session。这里需要注意的是session始终是由服务端创建的，并非浏览器自己生成的。　

 删除Session发生的现象：

注意：Session对象删除之后，查看浏览器Cookie，Session并没有一下子删除消失掉，得等一段时间浏览器才会显示没有的！如果想验证Session是否被删除，你可以在项目中获取一下Session对象，查看是否为空！

 什么是session超时？

HttpSession的最后一次访问时间和当前时间的差距大于了指定的最大空闲时间，这时服务器就会销毁Session对象。默认的空闲时间为30分钟。（生命周期结束）

session的几种失效情况

1. 超过了设置的超时时间
2. 主动调用了删除Session的方法invalidate()
3. 服务器主动或异常关闭

注意：浏览器关闭并不会让Session失效！

当我们在测试的时候，获取并查看当前SessionID。关闭浏览器后，重新发起请求，则看到再一次获取的SessionID变了！到看到发生的这一幕的时候，你们是不是会质疑这个结论呢？怎么浏览器关闭并不会让Session失效呢？它不是已经变了吗？那就让我来回答这个问题，我感觉这个问题还是有必要去说一下的！

我们第一次在浏览器发起请求，获取一个SessionID，我们在这里用①表示。这时候关闭浏览器，重新打开浏览器重新发起请求，在获取当前SessionID，我们在这里获取的是②。大家有没有发现①并不是和我们的②是同一个对象呢？Sesssion对象是存储再服务器中的，第一次发起请求获得①，关闭后重新发起请求获得②，这时候就有聪明的小伙伴发现了我两次加重标记了重新发起请求这几个字，你是不是找出其中的端倪了呢？（找不出也没事，我来给你答案！）

答案： 浏览器关闭并不会让Session失效，这里所指的Session对象是服务器端的Session对象没有失效！你想我们第一次发起请求获得一个Session对象，而当我们关闭浏览器重新发起请求时，这就是一个新的请求（Request），它会创建一个新的Session对象，所以我们看到的表面现象是改变的。而我们看不到的服务器内的Session对象是没有发生改变的！

浏览器禁用Cookie的后果

 如果浏览器禁用Cookie，session还能用吗？ 答：不能，但有其他的解决方案 服务器在默认情况下，会使用Cookie的方式将sessionID发送给浏览器，如果用户禁止Cookie，则sessionID不会被浏览器保存。此时，服务器可以使用如URL重写这样的方式来发送sessionID。

状态管理具体详情

三、了解什么是无状态和有状态 

有状态：至于有状态，我们就可以得知它有什么状态，说明session保留了该服务状态。众所周知，session是保存在浏览器本地的Cookie中的，也就是它可以维持一个会话管理的状态，将该状态保存在本地浏览器Cookie中，所以有状态Session可以控制时间来保存会话状态，用做处理。

无状态：至于无状态，它不能维持一个调用客户的状态，当方法执行完毕后，状态不会被保持。比如：token，我们可以通过Request对象来在请求中传递一次性token，这样各个请求对于服务器来说同意无差别处理，请求对象自身携带了所有服务端所需要的所有参数。