这篇文章我会说的很多，很杂，但主要还是关于session过期的问题
本文针对session过期但是由于项目情况比较特殊，一般判断无法解决，所以我会阐述几种我用过的方式。
1. session过期情况---这是最简单的一种，前台是一个在无点击的情况下不会产生前后交互的界面
这种情况下最简单的方式就是首先设置session失效时间，其次设置过滤器（拦截器），拦截所有请求，
如果过了session失效时间，前台用户进行操作，可以在过滤器中直接进行重定向。
注意：
这里我要说个小问题：很多人说遇到过 Cannot forward after response has been committed 问题，
这问题是在response发送关闭后有发送一次。很多说在response.redirect 后边加return就可以解决了，
不错这是解决办法，但在filter的dofilter中一定注意一点，filter的super.doFilter 和 filterChain.doFilter
一定要和你的重定向语句不能串行化执行，用判断分开执行，只要保证重定向之后没有了response的操作
就不会出现该问题了。
2. session过期情况 --- 前台定时ajax (但使用的地方不多，一个界面也就1-2个，主要供server推送或者是显
示最热物品之类的)这种情况是最好的(我最喜欢的)， 这种情况下我基本使用方式：
1. 在过滤器（拦截器）中进行处理，当用户第一次访问时候，把当前系统时间放到session中oldtime(long
值即可)，之后每次有请求经过时候，判断当前的请求是不是ajax请求，如果是则把当前系统存session
中newtime，如果不是则把当前时间放到oldtime中，这样只要new-old > 一个值 ，就证明用户在多长时
间没操作，这时候我们可以手动让session失效，并让前台进行跳转。（就是记录用户第一次时间和最
后一次时间，做差）
后台：
HttpSession session = request.getSession();
long now = System.currentTimeMillis()
session.setAttribute("newtime", now);
if("XMLHttpRequest".equals(request.getHeader("x-Requested-With"))){
if(now - (Long)session.getAttribute("oldtime") > 30000000){
response.getWriter().write(
"<script>window.location.href='login.html'</script>");
return;
}
}
session.setAttribute("oldtime", now);
chain.doFilter(request,response);
前台：
$(function(){
setInteval(function(){
$.post("getMessage", function(data){
//判断是不是过期，如果过期可以返回的js
//<script>window.location.href='login.html'</script>
//通过$("html").html("*****上边的串*****");进行跳转
//如果没过期，就该干嘛干嘛。
},"text");
}, 300000);
});
注意：这种方式有很大局限性, 主要是前台编写不可以应用大量的ajax，否则不能判断是不是用户操作。
3. session过期情况----前台有大量ajax(就类似我现在做的项目，前台95%是利用ajax)其实我现在项目中有很
多是实时更新的，一个见面中一个模块是每过3秒更新一次，另一个是每过5分钟更新一次而且大部分的点
击事件都是ajax，因为前台需要异步形式。（其实我都快泪奔了......）这时候session本质来讲是永远不会
过期的，除非session丢了。这种情况只能在某个时间点让前台把所有定时器关掉，比如说1小时定时器全
关，在利用web.xml把session超时时间设置成10分钟，如果在十分钟内没请求，session失效，但是如何
让前台自动跳转哪？
其实还是需要一个定时器，（当然如果用长连接也可以，但是我不怎么会使），每过1小时零20分钟访问
后台一次判断session(一定要在session预定失效时间后请求)。来进行跳转。
毕竟没有请求，前台自动跳转，这实在是不符合基本的业务逻辑。
最后我说一下 HttpSessionListener这个接口有两个函数，一个是在监听session创建一个是监听session销毁的
该接口主要还是功能还是判断当前在线人数的， 监听器这种东西主要还是针对与某个动作触发后应该作什么反映。
在web中请求和响应这套业务逻辑中，listener在我看来并不应该属于这里。
亲们，如果谁有好的建议，改进措施，我的内容写错，请及时提出哈！另外有什么别的办法，请回复给我。
iteye发表工具真应该重做了，不太智能，呵呵