简直骚操作，ThreadLocal还能当缓存用

背景说明

有朋友问我一个关于接口优化的问题，他的优化点很清晰，由于接口中调用了内部很多的 service 去组成了一个完成的业务功能。每个 service 中的逻辑都是独立的，这样就导致了很多查询是重复的，看下图你就明白了。

上层查询传递下去

对于这种场景最好的就是在上层将需要的数据查询出来，然后传递到下层去消费。这样就不用重复查询了。

如果开始写代码的时候是这样做的没问题，但很多时候，之前写的时候都是独立的，或者复用的老逻辑，里面就是有独立的查询。

如果要做优化就只能将老的方法重载一个，将需要的信息直接传递过去。

public void xxx(int goodsId) {
    Goods goods = goodsService.get(goodsId);
    .....
}
public void xxx(Goods goods) {
    .....
}

加缓存

如果你的业务场景允许数据有一定延迟，那么重复调用你可以直接通过加缓存来解决。这样的好处在于不会重复查询数据库，而是直接从缓存中取数据。

更大的好处在于对于优化类的影响最小，原有的代码逻辑都不用改变，只需要在查询的方法上加注解进行缓存即可。

public void xxx(int goodsId) {
    Goods goods = goodsService.get(goodsId);
    .....
}
public void xxx(Goods goods) {
    Goods goods = goodsService.get(goodsId);
    .....
}
class GoodsService {
    @Cached(expire = 10, timeUnit = TimeUnit.SECONDS)
    public Goods get(int goodsId) {
        return dao.findById(goodsId);
    }
}

如果你的业务场景不允许有缓存的话，上面这个方法就不能用了。那么是不是还得改代码，将需要的信息一层层往下传递呢？

自定义线程内的缓存

我们总结下目前的问题：

1. 同一次请求内，多次相同的查询获取 RPC 等的调用。
2. 数据实时性要求高，不适合加缓存，主要是加缓存也不好设置过期时间，除非采用数据变更主动更新缓存的方式。
3. 只需要在这一次请求里缓存即可，不影响其他地方。
4. 不想改动已有代码。

总结后发现这个场景适合用 ThreadLocal 来传递数据，对已有代码改动量最小，而且也只对当前线程生效，不会影响其他线程。