不要使用全局变量, ThreadLocal也不行

不要使用全局变量的道理大家都懂，基本上在大家学习编程过程中很早就会被教育到，但是有时候我们也会禁不住诱惑用到一些似非实是的全局变量，只不过这些全局变量会穿上马甲，让你不会一下看穿它的巨大危害，这里就讲一下我们的故事。

初上贼船

我们的系统是一个插件化的体系，开发同学在开发一种新的插件的时候可以通过自定义PluginHook对插件生命周期中插入一些自定义的逻辑，而在PluginHook里面会需要知道当前用户是谁? 是谁在操作数据? 因此我们搞了一个CurrentUserFilter , 里面的逻辑会把当前用户设置到一个叫做 UserHolder类的 ThreadLocal变量里面去，伪代码如下:

    // ===== 这里的代码只是为了说明问题的伪代码，只是真实实现的粗略模仿 =====
    // CurrentUserFilter.java
    protected void doneFilterInternal(HttpServletRequest request, HttpServletResponse response,
                                      FilterChain filterChain)
            throws ServletException, IOException {
        try {
            UserHolder.setCurrentUser(getLoginUserFromSession(request));
            filterChain.doFilter(request, response);
        } finally {
            UserHolder.clearCurrentUser();
        }
    }

    // UserHolder.java
    private static final ThreadLocal userThreadLocal = new ThreadLocal<>();

    public static User getCurrentUser() {
        return userThreadLocal.get();
    }

    public static void setCurrentUser(User user) {
        userThreadLocal.set(user);
    }

    public static void clearCurrentUser(User user) {
        userThreadLocal.set(null);
    }

这里的 UserHolder 里面的 userThreadLocal 粗看起来不是全局变量，它只在当前线程、当前请求生命周期内有效，因为 CurrentUserFilter 在请求结束的时候会调用UserHolder.clearCurrentUser()把这个状态清除掉。

而且带来的便利性很大: 开发同学在PluginHook里面就可以通过UserHolder.getCurrentUser() 拿到当前用户了, 而不用把当前用户从上传到下。只要大家不要到处滥用UserHolder, 应该没有问题。UserHolder加入之后为了防止大家滥用，我们也没有大肆宣传这个东西。

但是鲁迅先生曾经说过:

你担心大家会滥用的代码，大家(包括你自己)一定会滥用。

                                              -- 鲁迅。

我们很快发现这个类还是很快占领了我们很多代码模块。

这条记录是谁修改的?

首先我们发现我们很多表里面记录最后操作者的字段都是NULL，

user_table
  |- id
  |- name
  |- createor_id
  |- modifier_id -- 这个字段是NULL

而原因很简单，是开发更新数据的时候忘记设置了，要确保每个地方都设置好最后操作者也确实是个很繁琐的事情。咦，我们不是有UserHolder么？ 我们可以在DAO的update方法里面自动设置呀，而且就不用代码把当前用户一层层传到DAO层了，好，用上。

public void updateUser(User user) {
    // 其它业务逻辑
    balabala

    // 自动设置当前用户
    user.setModifierId(UserHolder.getCurrentUser().getId());
}

这样底层DAO就依赖上这个全局变量。

让UserHolder可以跨线程生效

在一些代码里面我们UserHolder.getUser()拿不到用户信息，

然后我们发现我们表里面有些记录的modifier_id还是NULL， 仔细查过之后发现这些记录是由异步线程写入数据库的，而这些异步线程里面没有人去设置这个User ThreadLocal, 那么自然就拿不到了。于是我们又写了一段很厉害的代码在线程切换之前把这个UserUtils.getUser()传播过去，并且在这个线程退出的时候把用户信息清除掉。

// ===== Again: 这里的代码只是为了说明问题的伪代码，只是真实实现的粗略模仿 =====

// 把当前用户拿出来传给新线程
Thread thread = new AsyncThread(UserHolder.getCurrentUser());
class AsyncThread {
    private User currentUser;
    public void run() {
        try {
            // 在真正业务代码开始之后设置这个新线程的User
            UserHolder.setCurrentUser(currentUser);
            // 下面是业务代码
        } finally {
            // 把User清理掉
            UserHolder.clearCurrentUser();
        }
    }
}

很棒，我们的 UserHolder 开始跨线程了。。

OpenAPI: 来自非浏览器的请求

再后来我们要暴露OpenAPI给其他系统调用了，我们发现从OpenAPI调用的请求会出错，原因跟上面的原因类似，因为底层的DAO代码又拿不到当前用户了。当然拿不到了，因为OpenAPI的请求不是来自用户的请求，不会进入我们的 CurrentUserFilter , 自然也就不会设置这个当前用户了。但是经过上面两节的改造，我们的代码已经深深依赖上了这个UserHolder.getCurrentUser(), 难道每次调用OpenAPI之前我们手动设置一下UserHolder么? 情况已经有点失控了，我们仿佛上了一条贼船。

为了避免问题进一步扩大，我们决定把这个UserHolder彻底干掉，所有需要用到当前用户的地方都手动把参数传下去，这样虽然代码看起来有点繁琐，有点累赘，但是不用担心全局变量的设置问题了。

总结

全局变量不能用，当全局变量穿上马甲比如ThreadLocal之类的，也要能识破它，拒绝它。