[转]httpSession的正确理解

关于HttpSession的误解实在是太多了，本来是一个很简单的问题，怎会搞的如此的复杂呢？下面说说我的理解吧： 
一个session就是一系列某用户和服务器间的通讯。服务器有能力分辨出不同的用户。一个session的建立是从一个用户向服务器发第一个请求开始，而以用户显式结束或session超时为结束。 
其工作原理是这样的： 
1.当一个用户向服务器发送第一个请求时，服务器为其建立一个session，并为此session创建一个标识号； 
2.这个用户随后的所有请求都应包括这个标识号。服务器会校对这个标识号以判断请求属于哪个session。 
这种机制不使用IP作为标识，是因为很多机器是通过代理服务器方式上网，没法区分每一台机器。 
对于session标识号（sessionID），有两种方式实现：cookies和URL重写。 

HttpSession的使用 
我们来看看在API中对session是如何定义和操作的。 
当需要为用户端建立一个session时，servlet容器就创建了一个HttpSession对象。其中存储了和本session相关的信息。所以，在一个servlet中有多少个不同用户连接，就会有多少个HttpSession对象。 
使用的机理是： 
1.从请求中提取HttpSession对象； 
2.增加或删除HttpSession中的属性； 
3.根据需要关闭HttpSession或使其失效。 

在请求中有两个重载的方法用来获取HttpSession对象。 
HttpSession getSession(boolean create)/getSession();作用是提取HttpSession对象，如果没有自动创建。 

获取到HttpSession对象后，我们就需要使用HttpSession的某些方法去设置和更改某些参数了。如： 
void setAttribute(String name, Object value); 
Object getAttribute(String name); 
void removeAttribute(String name); 

在javax.servlet.http包里一共定义了四个session监听器接口和与之关联的两个session事件。分别是： 
HttpSessionAttributeListener and HttpSessionBindingEvent; 
HttpSessionBindingListener and HttpSessionBindingEvent; 
HttpSessionListener and HttpSessionEvent; 
HttpSessionActivationListener and HttpSessionEvent. 

他们的继承关系是： 
所有四个接口的父类是java.util.EventListener; 
HttpSessionEvent扩展java.util.EventObject; 
而HttpSessionBindingEvent又扩展了HttpSessionEvent。 

以下分别详述： 
HttpSessionAttributeListener 
当session中的属性被添加，更改，删除时得到通知。这个接口上节讲过，主要看其它三个。 

HttpSessionBindingListener 
当一个实现了HttpSessionBindingListener的类被加入到HttpSession中（或从中移出）时，会产生HttpBindingEvent事件，而这些事件会被它本身接收到。 
本接口定义了两个方法： 
void valueBound(HttpSessionBindingEvent e); 
void valueUnbound(HttpSessionBindingEvent e); 
当多个实现了HttpSessionBindingListener的类被加入到HttpSession中时，各类的方法只对本类感兴趣，不会去理会其它类的加入。 
即使是同一类的不同实例间，也是互不关心的（各扫门前雪）。 

我们可以看到前两个接口都对HttpSessionBindingEvent事件做出反应，但机理不同。 
HttpSessionAttributeListener是在web.xml中登记的，servlet容器仅创建一个实例，来为任何在session中增加属性的servlet服务。触发事件的对象是所有可以转换为Object的实例。 
HttpSessionBindingListener不用在web.xml中登记，在每个servlet中用new创建实例，且仅对本实例向session中的加入（或移出）感兴趣。触发事件的对象仅仅是自己。 

HttpSessionListener 
对于session的创建和取消感兴趣。需要在web.xml中登记。 
共有两个方法： 
void sessionCreated(HttpSessionEvent se); 
void sessionDestroyed(HttpSessionEvent se); 
使用它我们可以容易的创建一个类来对session计数。 


也许我们会简单的考虑使用sessionDestroyed方法来在session结束后做一些清理工作。但是，请注意，当这个方法被调用的时候，session已经结束了，你不能从中提取到任何信息了。因此，我们要另辟蹊径。 


一种通常采用的方法是使用HttpSessionBindingListener接口。在session创建时增加一个属性，而在session结束前最后一件事将这个属性删除，这样就会触发valueUnbound方法，所有对session的清理工作可以在这个方法中实现。 

HttpSessionActivationListener 
当session在分布式环境中跨JVM时，实现该接口的对象得到通知。共两个方法： 
void sessionDidActivate(HttpSessionEvent se); 
void sessionWillPassivate(HttpSessionEvent se); 


1、HTTP协议本身是“连接-请求-应答-关闭连接”模式的，是一种无状态协议（HTTP只是一个传输协议）； 
2、Cookie规范是为了给HTTP增加状态跟踪用的（如果要精确把握，建议仔细阅读一下相关的RFC），但不是唯一的手段； 
3、所谓Session，指的是客户端和服务端之间的一段交互过程的状态信息（数据）；这个状态如何界定，生命期有多长，这是应用本身的事情； 
4、由于B/S计算模型中计算是在服务器端完成的，客户端只有简单的显示逻辑，所以，Session数据对客户端应该是透明的不可理解的并且应该受控于服务端；Session数据要么保存到服务端（HttpSession），要么在客户端和服务端之间传递（Cookie或url rewritting或Hidden input）； 
5、由于HTTP本身的无状态性，服务端无法知道客户端相继发来的请求是来自一个客户的，所以，当使用服务端HttpSession存储会话数据的时候客户端的每个请求都应该包含一个session的标识(sid, jsessionid 等等)来告诉服务端； 
6、会话数据保存在服务端（如HttpSession）的好处是减少了HTTP请求的长度，提高了网络传输效率；客户端session信息存储则相反； 
7、客户端Session存储只有一个办法：cookie(url rewritting和hidden input因为无法做到持久化，不算，只能作为交换session id的方式，即a method of session tracking)，而服务端做法大致也是一个道理：容器有个session管理器（如tomcat的org.apache.catalina.session包里面的类），提供session的生命周期和持久化管理并提供访问session数据的api； 
8、使用服务端还是客户端session存储要看应用的实际情况的。一般来说不要求用户注册登录的公共服务系统（如google）采用cookie做客户端session存储（如google的用户偏好设置），而有用户管理的系统则使用服务端存储。原因很显然：无需用户登录的系统唯一能够标识用户的就是用户的电脑，换一台机器就不知道谁是谁了，服务端session存储根本不管用；而有用户管理的系统则可以通过用户id来管理用户个人数据，从而提供任意复杂的个性化服务； 
9、客户端和服务端的session存储在性能、安全性、跨站能力、编程方便性等方面都有一定的区别，而且优劣并非绝对（譬如TheServerSide号称不使用HttpSession，所以性能好，这很显然：一个具有上亿的访问用户的系统，要在服务端数据库中检索出用户的偏好信息显然是低效的，Session管理器不管用什么数据结构和算法都要耗费大量内存和CPU时间；而用cookie，则根本不用检索和维护session数据，服务器可以做成无状态的，当然高效）； 

10、所谓的“会话cookie”简单的说就是没有明确指明有效期的cookie，仅在浏览器当前进程生命期内有效，可以被后继的Set-Cookie操作清除掉.

Java中的Session和作用域

几乎所有的Web开发语言都支持Session功能，Servlet也不例外。 Servlet/JSP中的Session功能是通过作用域(scope)这个概念来实现的。 

作用域分为四种，分别为： 

page 在当前页面有效(仅用于JSP中) 
request 在当前请求中有效 
session 在当前会话中有效 
application 在所有应用程序中有效 

是不是看不太明白？page因为仅用于JSP中，这里只讲述其他三种作用域。首先要声明的一点，所谓“作用域”就是“信息共享的范围”，也就是说一个信息能够在多大的范围内有效。 

话说武松一日来到景阳岗，见一旗帜迎风飘扬，旗子上书五个大字“三碗不过岗”。武松叫道：“店家，拿三碗酒来，再切两斤熟牛肉！”店小二应声道：“三碗好酒，二斤熟牛肉啰～～”里面厨师赶忙当当当当切好牛肉，店小二倒上三碗酒，店小二端上前来。 

武松咕咚咕咚连干三碗，叫一声“好酒！店家，再来三碗！”小二忙又倒上三碗好酒，武松一饮而尽。就这样前前后后武松一共喝了十八大腕。付了帐刚要走，店小二道： “客官，这前面山上有大虫，客官刚刚喝完十八碗酒恐怕过不得岗，不如在小店暂住一夜，待明天和猎户一同过岗岂不是好？” 

之后武松说什么就留待各位看官自己去回忆啦。在这段武松打虎中，大家有没有看到些熟悉的东西？ 

武松: 浏览器。 
酒馆: 服务器。 
店小二、厨师: Servlet或者JSP。 
来三碗好酒！: 浏览器向服务器发出HTTP请求。 
店小二上酒: 服务器的响应。 
武松从进店到离开: 一个HTTP对话。 
我们可以看到，Web交互的最基本单位为HTTP请求(武松点菜)。每个用户从进入网站到离开网站这段过程称为一个HTTP会话 (武松进店到出店)，一个服务器的运行过程中会有多个用户访问，就是多个HTTP会话(酒馆当然不可能只接待武松一个客人)。那么作用域就可以理解为： 

request HTTP请求开始到结束这段时间 
session HTTP会话开始到结束这段时间 
application 服务器启动到停止这段时间 

request 

一个HTTP请求的处理可能需要多个Servlet合作(武松点菜时店小二就要吩咐厨房做菜)，几个Servlet之间可以通过某种方式传递信息(店小二就用吆喝的方式通知厨房)，但这个信息在请求结束后就无效了(厨房在做完菜之后就不用再管这道菜的事儿了)。 

Servlet之间的信息共享是通过HttpServletRequest接口的两个方法来实现的： 

void setAttribute(String name, Object value) 
将对象 value 以 name 为名称保存到request作用域中。 
Object getAttribute(String name) 
从request作用域中取得指定名字的信息。 
doGet()、doPost()函数的第一个参数就是 HttpServletRequest 对象，使用这个对象的 setAttribute 即可传递信息。 

那么设置好信息之后，如何将信息传给其他Servlet？这就要用到 RequestDispatcher 接口的 forward 方法，将请求转发给其他Servlet。 

RequestDispatcher ServletContext.getRequestDispatcher(String path) 
取得Dispatcher以便转发。path为转发的目的Servlet。 
void RequestDispatcher.forward(ServletRequest request, ServletResponse response) 
将request和response转发。 
因此，只要在当前Servlet中先 setAttribute，然后forward，最后在forward到的Servlet中 getAttribute即可实现信息传递。 

PHP的程序员可能不太好理解这一段，因为PHP中没有转发的概念，一个请求只能由一个PHP文件来处理，所以PHP中根本没有request作用域的概念。而Servlet则不同，请求可以在应用程序中任意转发，所以用request作用域在不同Servlet之间传递信息。需要注意两点： 

转发不是重定向，转发是在Web应用内部进行的。PHP支持重定向但没有转发。 
转发对浏览器是透明的，也就是说，无论在服务器上如何转发，浏览器地址栏中显示的仍然是最初那个Servlet的地址。 
session 

session作用域比较容易理解，同一浏览器访问多次，在这多次访问之间传递信息，就是session作用域。 ('''武松每次点菜帐房先生都要记一笔账，等武松走之前结帐用。这笔帐在武松吃饭过程中始终有效，即位于session作用域中''') 

session是通过HttpSession接口实现的。 

Object HttpSession.getAttribute(String name) 
从session中获取信息 
void HttpSession.setAttribute(String name, Object value) 
向session中保存信息 
而通过HttpServletRequest.getSession()方法可以获得HttpSession对象。 

HttpSession HttpServletRequest.getSession() 
获取当前请求所在的session的对象。 
session的开始容易判断(浏览器发出第一个HTTP请求即可认为会话开始)，但结束就不好判断了(因为浏览器关闭时不会通知服务器“我关了，会话可以结束了”)，所以只能通过这种方法判断：如果一定的时间内客户端没有反应，则认为会话结束。 Tomcat的默认值为120分钟，但这个值也可以通过 HttpSession 的 setMaxInactiveInterval 方法来设置。 

void setMaxInactiveInterval(int interval) 
设置绘画的超时值。 
如果想主动让会话结束，如用户单击“注销”的时候，可以使用 HttpSession 的 invalidate 方法： 

vooid invalidate() 
强制结束当前session。 
application 

application作用域就是服务器启动到关闭的整段时间，在这个作用域内设置的信息可以被所有应用程序使用。 (餐馆打烊后结帐，用到的即是开张到打烊之间的所有信息。) 

还记得上一节提到的ServetContext吗？ application作用域上的信息传递就是通过ServetContext实现的。 

Object getAttribute(String name) 
从application中获取信息。 
void setAttribute(String name, Object value) 
向application作用域中设置信息。 
总结 

可以看到，每个作用域除了实现接口不同、意义不同之外，它们的使用方法和作用都是相同的，都是通过 getAttribute 和 setAttribute 方法进行信息传递。 

作用域 意义 实现接口 
request HTTP请求内 HttpServletRequest 
session HTTP会话内 HttpSession 
application 服务器生命周期内 ServletContext