简直骚操作，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); }
如果你的业务场景不允许有缓存的话，上面这个方法就不能用了。那么是不是还得改代码，将需要的信息一层层往下传递呢？自定义线程内的缓存
我们总结下目前的问题：同一次请求内，多次相同的查询获取 RPC 等的调用。数据实时性要求高，不适合加缓存，主要是加缓存也不好设置过期时间，除非采用数据变更主动更新缓存的方式。只需要在这一次请求里缓存即可，不影响其他地方。不想改动已有代码。
总结后发现这个场景适合用 ThreadLocal 来传递数据，对已有代码改动量最小，而且也只对当前线程生效，不会影响其他线程。public void xxx(int goodsId) { Goods goods = ThreadLocal.get(); if (goods == null) { goods = goodsService.get(goodsId); } ..... }
上面代码就是使用了 ThreadLocal 来获取数据，如果有的话就直接使用，不用去重新查询，没有的话就去查询，不影响老逻辑。
虽然能实现效果，但是不太好，不够优雅。也不够通用，如果一次请求内要缓存多种类型的数据怎么处理? ThreadLocal 就不能存储固定的类型。还有就是老的逻辑还是得改，加了个判断。
下面介绍一种比较优雅的方式：自定义缓存注解，加在查询的方法上。定义切面切到加了缓存注解的方法上，第一次获取返回值存入 ThreadLocal。第二次直接从 ThreadLocal 中取值返回。ThreadLocal 中存储 Map，Key 为某方法的某一标识，这样可以缓存多种类型的结果。在 Filter 中将 ThreadLocal 进行 remove 操作，因为线程是复用的，使用完需要清空。
注意：ThreadLocal 不能跨线程，如果有跨线程需求，请使用阿里的 ttl 来装饰。
注解定义@Target({ ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) public @interface ThreadLocalCache { /** * 缓存key，支持SPEL表达式 * @return */ String key() default ＂＂; }存储定义/** * 线程内缓存管理 * * @作者 尹吉欢 * @时间 2020-07-12 10:47 */ public class ThreadLocalCacheManager { private static ThreadLocal