JSP内置对象——session对象

举个购物流程的例子：

这整个购物过程，它是属于一次回话。那么这个session是保存在服务器内存当中，并且它保存着不同用户对应的session，一个用户对应一个session。看下面这幅图：

从图中可以看出，我们的session是保存在服务器当中的，保存着3个session，这三个session对象跟用户客户端是以一一对应的。

接下来再看一下session对象的一些相关说明：

Session对象呢，也是我们JSP的一个内置对象，它在用户第一次访问JSP页面的时候，就会自动创建，完成一次客户端与服务器之间的会话管理。那么这个Session的生命周期呢，从用户打开浏览器开始和服务器的一个会话，到关闭浏览器，那么整个这个期间都会称为叫做一个会话，那么当用户访问服务器的时候，可能会在多个页面切换，那么服务器就需要有一种办法去保存用户的状态，这个时候就可以使用Session对象，那么也就是说，Session对象是保存用户状态的一种机制。然后看一下Session对象有哪些常用的方法：

下面通过一个具体的实例来说明下，这些方法的如何使用：

运行结果：

ok，没有问题，这些参数都获取得到了。接下来我在session_page1.jsp中做一个超链接，跳到session_page2.jsp页面。代码如下：

sesson_page1.jsp：

sesson_page2.jsp：

运行结果：

也没问题，从session_page1.jsp页面和session_page2.jsp页面的Session的ID可以看出，这两个页面是属于同一个Session。也就是说，这个Session它从客户端打开浏览器就建立了和服务器的一个会话，直到用户把本次会话相关的所有的浏览器都关闭了，才代表它本次会话结束了。当然了，一个Session也有它自己的生存周期，比方说用户停留在一个页面长时间没有任何的操作，它就会提示这个页面已经过期了，同样也就意味着这个会话结束了。

再来看下另一个方法：getValueNames()：

先在session_page1中多设置几个属性：

getValueNames()方法是返回一个所有Session属性名称的数组，所以这里通过遍历的形式进行了打印，运行结果如下：

ok，也没有问题。同样，我们可以设置这个Session的生存期限，我们可以使用setMaxInactiveInterval()方法去设置，（单位是秒），比如我们设置10秒，那么这个Session过10秒就过期了，当这时候再打开一个页面呢，实际上就创建了一个新的Session。

比如说我们在session_page1.jsp当中加上一句代码，如下：

运行结果：

可以看到，当session_page1.jsp页面打开后，停留10秒钟后再点击，跳转到的session_page2.jsp页面后，Session的ID已经不一样了，也就是说之前的Session已经过期了，已经被创建了一个新的Session。因为是创建爱的新的Session，所以从上个页面Session保存的用户名和属性，也已经也获取不到了。

Session的生命周期经过以下几个阶段如下：

接下来，举一些实例来讲下这个Session生命周期的这三个阶段。

现在我们有“session_page1.jsp”和“session_page2.jsp”两个界面如下：

session_page1.jsp：

session_page2.jsp：

运行：

现在找到我们在浏览器输入“http://localhost:8080/manager/html”进入Tomcat后台管理，没有Tomcat账号密码的，需要先到tomcat安装目录“conf”文件夹下的tomcat-users.xml文件里添加一个账号和密码，例如以下所示：

进入后找到我们部署的项目：

这上面可以看到，我们活动的会话，点击这个“3”数字，

发现，这个Session Id跟我们之前session_page1.jsp页面获取到的ID一模一样，那现在我先来测试第一种情况“在某次会话中通过超链接打开的新页面属于同一次会话”。操作如下：

发现这个session id 是完全相同的，符合这种情况。

还有一种情况，现在我测试“当前会话界面没有完全关闭，重新打开新的浏览器窗口访问同一项目资源时，属于同一次会话”，操作如下：

我现在把刚刚打开的session_page2.jsp页面关了，重新打开一个浏览器，还是单独输入访问session_page2界面。输入“http://localhost:8080/session_page2.jsp”后发现，显示的SessionID仍然不变。

第三种情况是“本次会话的所有页面都关闭的情况下，再重新访问某个JSP或者Servlet时会创建新的会话。”

注意：原有会话仍存在，但只是这个旧的SessionId仍存在于服务器端，但再也没有客户端会携带它然后交予服务器端去校验了。