app后端抛弃session利用token来启用自己的会话管理

为什么要放弃session

1. 现在的互联网环境中，集群是后台比较常见的情况，众所周知，session其实是一个jvm内的用户副本，如果我们要把一个集群中的用户session做共享处理还是比较麻烦的。
2. 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 context =
        new ThreadLocal();

    private UserInfo userInfo;
    private Map params;

    private InvocationContext(Map params) {
        this.params = params;
    }

    private InvocationContext(UserInfo userInfo) {
        this.userInfo = userInfo;
    }

    public static InvocationContext getContext() {
        return context.get();
    }

    public static void initContext(Map params) {
        context.set(new InvocationContext(params));
    }

    public static void clear() {
        context.set(null);
        context.remove();
    }


    public Map getParams() {
        return params;
    }

    public void setParams(Map 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了