在springcache缓存初探中我们研究了如何利用spring cache已有的几种实现快速地满足我们对于缓存的需求。这一次我们有了新的更个性化的需求，想在一个请求的生命周期里实现缓存。
需求背景是：一次数据的组装需要调用多个方法，然而在这多个方法里又会调用同一个io接口，此时多浪费了一次io的资源。首先想到的解决方案是将这次io接口提出来调用，然后将结果作为参数传递到多个方法中，但是这样一来，每个调用这些方法的地方都得添加额外的代码。那么第二个方案就是，我们还是分别调用，只不过将这个结果缓存起来，就像我们之前做的那样。
这时候问题来了，这个数据结果我们希望尽可能实时，即使只缓存了一秒，导致在不同的请求里用了同一份数据也不太好。看来不得不自己实现一个只保持在一次请求过程中的缓存了。
要将数据缓存在一次请求周期内，那我们先得区分是什么环境下的请求，以分析我们如何存储数据。
web环境下的有个绝佳的数据存储位置 httpservletrequest的attribute 。调用setattribute和getattribute方法就能轻易地将我们的数据用key-value的形式存储在请求上，而且每次请求都自动拥有一个干净的request 。想要获取到httpservletrequest 也非常简单，在web请求中随时随地调用((servletrequestattributes) requestcontextholder.getrequestattributes()).getrequest() 即可。
我司所使用的rpc框架是基于finagle自研的，对外提供服务时使用线程池进行处理请求，即对于一次完整的请求，会使用同一个线程进行处理。首先想到的办法还是改动这个rpc框架服务端，增加一个可以对外暴露的、可以key-value存储的请求上下文。为了能在方便的地方获取到这个请求上下文，得将其存储在threadlocal中。
综合这两种环境考虑，我们最好还是实现一个统一的方案以减少维护和开发成本。spring的requestcontextholder.getrequestattributes()其实也是使用threadlocal来实现的，那我们可以统一将数据存到threadlocal<map<object,object>>，自己来维护缓存的清理。
存储位置有了，接下来实现springcache思路就比较清晰了。
要实现springcache需要一个cachemanager，接口定义如下
xxxxxxxxxx
我要评论public interface cachemanager {
cache getcache(string name);
collection<string> getcachenames();
}
可以看到其实只需要实现cache接口就行了。 在上一篇文章中提到的simplecachemanager，它的cache实现concurrentmapcache内部的存储是依赖concurrentmap<object, object>。我们的实现跟它非常类似，最主要的不同是我们需要使用threadlocal<map<object, object>> 下面给出几处关键的实现，其他部分简单看下concurrentmapcache就能明白。
我们选择不直接继承cache而是abstractvalueadaptingcache，其被大多数缓存实现所继承，它的作用主要是包装value值以区分是没有命中缓存还是缓存的null值。
xxxxxxxxxx
private final threadlocal<map<object, object>> store = threadlocal.withinitial(() -> new hashmap<>(128));
我们的缓存数据存储的地方，threadlocal保证缓存只会存在于这一个线程中。同时又因为只有一个线程能够访问，我们简单地使用hashmap即可。
xxxxxxxxxx
public <t> t get(object key, callable<t> valueloader) {
return (t) fromstorevalue(this.store.get().computeifabsent(key, r -> {
try {
return tostorevalue(valueloader.call());
} catch (throwable ex) {
throw new valueretrievalexception(key, valueloader, ex);
}
}));
}
至此我们即将大功告成，只差一个步骤，threadlocal的清理：使用aop实现即可。
xxxxxxxxxx
@after("bean(server)")
public void clearthreadcache() {
threadcachemanager.clear();
}
记得将cache的clear方法通过我们自定义的cachemanager暴露出来。同时也要确保切面能覆盖每个请求的结束。
从以上一个简单的threadlocalcachemanager实现，我们对cachemanager又有了更多的理解。
同时可能也会有更多的疑问。
再回顾spring cache为我们提供的@cacheable中的sync的注释，它提到此功能的作用是: 同步化对被注解方法的调用，使得多个线程试图调用此方法时，只有一个线程能够成功调用，其他线程直接取这次调用的返回值。同时也提到这仅仅只是个hint，是否真的能成还是要看缓存提供者。
我们找到spring cache处理缓存调用的关键方法org.springframework.cache.interceptor.cacheaspectsupport#execute(org.springframework.cache.interceptor.cacheoperationinvoker, java.lang.reflect.method, org.springframework.cache.interceptor.cacheaspectsupport.cacheoperationcontexts) (spring-context-5.1.5.release)
经过分析，当sync = true 时, 只会调用如下代码
xxxxxxxxxx
return wrapcachevalue(method, cache.get(key, () -> unwrapreturnvalue(invokeoperation(invoker))))
即我们上文实现的t get(object key, callable<t> valueloader) 方法，回头一看一切都清晰了。 只要我们的this.store.get().computeifabsent是同步的，那这个sync = true就起作用了。 当然我们这里使用的hashmap不支持，但是我们如果换成concurrentmap就能够实现同步化的功能。另外简单粗暴地让方法同步也是可以的（rediscache就是这样做的）。
当sync = false时，会组合cache中其他的方法进行缓存的处理。逻辑较为简单清晰，自行阅读源码即可。
异步操作分两种情况，直接创建线程或者使用线程池。对于第一种情况我们可以简单地使用java.lang.inheritablethreadlocal 来替代threadlocal，创建的子进程会自然而然地共享父进程的inheritablethreadlocal；第二种情况就相对比较复杂了，建议可以参考 ，它实现了线程池下的threadlocal值传递功能。
如对本文有疑问， 点击进行留言回复！！
网友评论