Session的线程安全问题及有效性问题

1、线程安全问题

Session接口的相关实现由Tomcat容器提供，本身保证线程安全。但Session中保存的对象，其线程安全当然要由开发者保证。线程安全问题隐蔽、偶发，出了问题不好定位修正，一定要注意线程安全问题。通常，通过如下代码创建或者取得Session引用：

HttpSession session = request.getSession(true);                  // 这个方法是线程安全的。

通过如下方法为session设置属性：

session.setAttribute("user", new user("name"));                     // 这个方法也是线程安全的。

通过如下方法从session获取属性：

User u = session.getAttribute("user");                                      // 这个方法也是线程安全的

接下来，从u读取属性或者设置属性：

u.getName();

u.setName("NewName");

以上两个方法，是不是线程安全，取决于User类的实现，为了保证线程安全，需要在getName与setName方法的实现中加上线程同步机制，也就是说要保证User类本身是线程安全的。如果User类不保证线程安全，就由使用者来保证线程安全，代码应该这样：

synchronized(u) {

    u.getName();

    u.setName("NewName");

}

在User类不保证线程安全的情况下，也可以这样子操作，不试图修改从session取回的对象的属性，只是读。如果写的话，就New一个新对象，再设置到Session里边去，替换掉旧的，如：

u.getName();                                                                                 // 这个只是读

// u.setName("NewName");                                                           // 不要这样子，线程不安全

session.setAttribute("user", new User("NewName"));                   // 这个就线程安全，当然它会占用更多内存资源

2、Session的有效性问题

Session占用服务端存储资源，为了避免资源耗尽，服务端会定期(清理频率也可能与内存负荷相关)清理失效Session。每个Session保持最后访问时间及超时时间。如果当前时间减去最后访问时间的值大于超时时间，那Session就失效了。

Session的生命周期大概是这样子的：

创建------>(长时间不交互）失效------>服务器定期清理掉失效session

需要注意的是失效并不代表Session会立刻从系统消失，清理失效Session并不是实时的。看下边的代码：

HttpSession session = request.getSession(); 

上边的方法返回刚才创建好的Session，这个方法不会更新Session的最后访问时间。需要注意它可能返回null，因为Session过期失效并且被系统回收了。
也有可能不为空，但返回的session有可能已经过期失效，只不过系统还没有来得及回收。

接下来读或者写这个session实例的属性：

session.setAttribute("user", new User("name")); 

在拿到session引用并操作它的时候，每一次操作都会首先检查Session是否过期失效，如果没有则更新最后访问时间并执行读写操作。如果恰好过期，则会抛出“IllegalStateException”异常，表示现在这个Session失效了，状态处于不可控状态，不能再使用了。需要重新为用户分配SessionId及创建Session。

还有一个session方法:

session.invalidate()方法，这个是强制让session失效，即使它还没有过期，注意这个不是销毁session。当然随后回收session的线程定期检查（检查的频率也可能与内在的负荷相关）时发现它失效了，就会回收，这个才是彻底销毁。