一、session的概念及特点
　　session概念:在计算机中，尤其是在网络应用中，称为“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息。说白了session就是一种可以维持服务器端的数据存储技术。session主要有以下的这些特点：session保存的位置是在服务端session一般来说要配合cookie使用，如果用户浏览器禁用了cookie，那么只能使用URL重写来实现session的存储功能单纯的使用session来存储用户回话信息，那么当用户量较多时，session文件数量会很多，会存在session查询慢的问题本质上：session技术就是一种基于后端有别于数据库的临时存储技术二、为什么要使用session　　我们目前使用的互联网应用层协议基本上都是基于 HTTP 和 HTTPS 的，它们的本身是无状态的， 只负责请求和响应。 我告诉服务器我需要什么，服务器返回给我相应的资源。 如果没有额外处理的话， 服务器是不知道你是谁，更无法根据你是谁给你展现和你相关的内容了。HTTP 协议一开始被设计成这样还是有一些历史原因的，当时的互联网多用于学术交流，只用于文章信息的展现之类的事情，远没有现在这么丰富多彩。所以在当时的背景下 HTTP 协议被设计成这样其实也是很符合它的场景的。但随着互联网应用越来越广泛，应用的形式也变得越来越多，我们的 Web 应用不只限于提供简单的信息展现了，还需要用户能够登录，可以在论坛发帖子，在购物网站买东西等等。 这就需要 HTTP 协议能够记录用户的状态。也就是我们现在熟悉的 Session 由来。三、session的工作原理用户第一次请求服务器时，服务器端会生成一个sessionid服务器端将生成的sessionid返回给客户端，通过set-cookie客户端收到sessionid会将它保存在cookie中，当客户端再次访问服务端时会带上这个sessionid当服务端再次接收到来自客户端的请求时，会先去检查是否存在sessionid，不存在就新建一个sessionid重复1,2的流程，如果存在就去遍历服务端的session文件，找到与这个sessionid相对应的文件，文件中的键值便是sessionid，值为当前用户的一些信息此后的请求都会交换这个 Session ID，进行有状态的会话。四、session的生命周期Session何时生效：Sessinon在用户访问第一次访问服务器时创建，需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session,可调用request.getSession(true)强制生成Session。Session何时失效：1.服务器会把长时间没有活动的Session从服务器内存中清除，此时Session便失效。Tomcat中Session的默认失效时间为20分钟。从session不活动的时候开始计算，如果session一直活动，session就总不会过期。从该Session未被访问,开始计时; 一旦Session被访问,计时清0;2.调用Session的invalidate方法HttpSession session = request.getSession();session.invalidate();//注销该request的所有session4.设置session的失效时间a)web.xml中30b)在程序中手动设置session.setMaxInactiveInterval(30 * 60);//设置单位为秒，设置为-1永不过期request.getSession().setMaxInactiveInterval(-1);//永不过期c)tomcat也可以修改session过期时间，在server.xml中定义context时采用如下定义：5.关闭浏览器，session就会失效五、session的性能瓶颈　　另外一个要聊聊的就是 Session 数据的存储。 通常情况下，如果你不明确的设置， 大多数 Web 框架会把 Session 数据存放到内存中。如果你的 Web 应用用户量不大的话，这也不成问题。 但如果你的用户数比较大的话，就可能发生一个事情 — 内存不够用了。这很正常，内存容量是非常宝贵的，假设每个用户的 Session 数据是 100K， 1万个用户就会大概占用 1G 的存储空间，如果你的 Session 数据清理机制也恰巧比较慢的话，内存非常容易被占满。这就需要你在设计比较大并发量的站点时，要考虑 Session 的存储方式，比如把它们保存到硬盘文件系统中，或者数据库中。 所以你在开发一个 Web 应用的时候，如果你的用户量很大，你需要有这个意识。另外 Session 放到内存中还有一个弊端，如果你的 Web 服务器发生重启，那么所有的 Session 状态都会被情况，会在一定程度上影响用户体验。(引用自网络)

session与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操作清除掉