为什么要放弃session
- 现在的互联网环境中，集群是后台比较常见的情况，众所周知，session其实是一个jvm内的用户副本，如果我们要把一个集群中的用户session做共享处理还是比较麻烦的。
- app的客户端对session的支持会比较麻烦
基于上面的两点，我们才会想自己来管理这一个会话。
ThreadLocal
在提到会话管理这个之前我们需要先了解一个东西ThreadLocal.
那么ThreadLocal是什么呢？
JDK 1.2的版本中就提供java.lang.ThreadLocal，ThreadLocal为解决多线程程序的并发问题提供了一种新的思路。使用这个工具类可以很简洁地编写出优美的多线程程序，ThreadLocal并不是一个Thread，而是Thread的局部变量。
那么我们这个ThreadLocal一般用来做什么事呢?
首先，ThreadLocal 不是用来解决共享对象的多线程访问问题的，一般情况下，通过ThreadLocal.set() 到线程中的对象是该线程自己使用的对象，其他线程是不需要访问的，也访问不到的。各个线程中访问的是不同的对象。
另外，说ThreadLocal使得各线程能够保持各自独立的一个对象，并不是通过ThreadLocal.set()来实现的，而是通过每个线程中的new 对象 的操作来创建的对象，每个线程创建一个，不是什么对象的拷贝或副本。通过ThreadLocal.set()将这个新创建的对象的引用保存到各线程的自己的一个map中，每个线程都有这样一个map，执行ThreadLocal.get()时，各线程从自己的map中取出放进去的对象，因此取出来的是各自自己线程中的对象，ThreadLocal实例是作为map的key来使用的。
如果ThreadLocal.set()进去的东西本来就是多个线程共享的同一个对象，那么多个线程的ThreadLocal.get()取得的还是这个共享对象本身，还是有并发访问问题。
看了上面的描述，你应该能很清晰的明白了ThreadLocal的定义。对，他就是用Thread作为key来存储对应的线程副本变量的。
如何用ThreadLocal来达到我们的效果
大家应该知道，我们部署在tomcat容器下的jersey服务，每次请求都会对应着一个新开启的用户线程。
这样也就意味着我们的每次请求都是一个会话开启到结束的过程，那么从我们会话开启的过程中，如何在我们的前置请求中去拦截我们的用户请求，达到一个验证是否是我们的用户，然后如果是我们的用户的话，那么他对应的是哪个用户呢？
带着这样的疑问，我们想到了之前我写的那篇文章jersey利用filter和Dynamic binding来实现token拦截过滤请求.
在我们的fifter中的请求拦截的时候，我们会找到我们的token，根据token来判断是否是我们的用户。
那么在我们fifter中我就可以做这样的一件事。我们利用在fifter时候拦截token的用户鉴别来吧用户信息存储到一个中间介质的ThreadLocal变量中，在我们的下游api层的时候就可以直接去ThreadLocal中取得是哪一个用户来进行的请求。
但是这其中有一个问题，那就是我们的fifter和下游的api层是不是同一个线程呢？因为ThreadLocal变量的介质如果不是同一个线程就会取不到值。但是很幸运，我们的fifter和下游的api层是在我们的jersey中是同一个线程。
那ok，我们的所有规划都已完成，那具体的ThreadLocal实现是什么样子的呢？
public class InvocationContext {
private static final ThreadLocal<InvocationContext> context =
new ThreadLocal<InvocationContext>();
private UserInfo userInfo;
private Map<String, String> params;
private InvocationContext(Map<String, String> params) {
this.params = params;
}
private InvocationContext(UserInfo userInfo) {
this.userInfo = userInfo;
}
public static InvocationContext getContext() {
return context.get();
}
public static void initContext(Map<String, String> params) {
context.set(new InvocationContext(params));
}
public static void clear() {
context.set(null);
context.remove();
}
public Map<String, String> getParams() {
return params;
}
public void setParams(Map<String, String> params) {
this.params = params;
}
public String getParam(String param) {
return params.get(param);
}
public String getUserId() {
return userInfo == null ? "" : userInfo.getId();
}
public UserInfo getUserInfo() {
return userInfo;
}
public void setUserInfo(UserInfo userInfo) {
this.userInfo = userInfo;
}
/**
* 设置会话级别的session元素值
* @param userInfo
*/
public static void initThreadContext(UserInfo userInfo) {
context.set(new InvocationContext(userInfo));
}
}
具体怎么使用我们这一块的InvocationContext呢？
首先在fifter的token拦截鉴别用户成功之后调用initThreadContext方法传递userInfo的信息，然后在我们的整个api会话层的下游的只需要调用InvocationContext.getContext().getUserInfo()方法就能获取本次请求的userInfo的信息了。
那么请注意的一点ThreadLocal是可能引起内存泄露的。
解决ThreadLocal的内存泄露
那么ThreadLocal的内存泄露是由什么原因引起的呢？
threadlocal里面使用了一个存在弱引用的map,当释放掉threadlocal的强引用以后,map里面的value却没有被回收.而这块value永远不会被访问到了. 所以存在着内存泄露. 最好的做法是将调用threadlocal的remove方法.
每个thread中都存在一个map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例. 这个Map的确使用了弱引用,不过弱引用只是针对key. 每个key都弱引用指向threadlocal. 当把threadlocal实例置为null以后,没有任何强引用指向threadlocal实例,所以threadlocal将会被gc回收. 但是,我们的value却不能回收,因为存在一条从current thread连接过来的强引用. 只有当前thread结束以后, current thread就不会存在栈中,强引用断开, Current Thread, Map, value将全部被GC回收.
所以得出一个结论就是只要这个线程对象被gc回收，就不会出现内存泄露，但在threadLocal设为null和线程结束这段时间不会被回收的，就发生了我们认为的内存泄露。其实这是一个对概念理解的不一致，也没什么好争论的。最要命的是线程对象不被回收的情况，这就发生了真正意义上的内存泄露。比如使用线程池的时候，线程结束是不会销毁的，会再次使用的。就可能出现内存泄露。
PS.Java为了最小化减少内存泄露的可能性和影响，在ThreadLocal的get,set的时候都会清除线程Map里所有key为null的value。所以最怕的情况就是，threadLocal对象设null了，开始发生“内存泄露”，然后使用线程池，这个线程结束，线程放回线程池中不销毁，这个线程一直不被使用，或者分配使用了又不再调用get,set方法，那么这个期间就会发生真正的内存泄露。
看了上面的解释之后，我们知道在本次线程会话结束后需要设置threadlocal的set方法为null。并且调用remove方法就可以解决threadlocal的内存泄露问题。
大家应该也注意到我上面InvocationContext代码中的clear方法了，那么什么时候该调用clear方法呢。
我们是选择在一次serverlet请求结束的时候调用该方法。具体代码如下：
public class HttpServletRequestListener implements ServletRequestListener {
/**
* 销毁会话session,防止内存泄露
* @param sre
*/
@Override
public void requestDestroyed(ServletRequestEvent sre) {
InvocationContext.clear();
}
@Override
public void requestInitialized(ServletRequestEvent sre) {
}
}
然后在我们的项目中的Clearweb.xml文件中声明这个listener`就ok了
