申明：本文摘抄自公众号【看点代码再下班】。
目录
Spring Cache “错用”
错在哪里？
从Spring Cache原理解释为什么公有办法不能加缓存
从Spring AOP原理解释为什么公有办法上不能加缓存
类外部办法调用不反对加缓存
结语
大家好，我是tin，这是我的第12篇原创文章
Spring Cache “错用”
背景是这样的， 一个共事开发的一个功能模块代码，大略是查问一个上游的内容接口，查问到数据并转发给端侧接口。这个功能模块流量十分大，上游的内容接口的内容数据量也无限（内容id数无限，量级在几个w），共事也意识到了须要在本人服务内对上游内容接口加本地缓存。做法和上面图截然不同：
这个代码公布到线上，当端侧拜访入口凋谢时，咱们后端服务就开始疯狂告警，都是内容接口不负重压、响应超时的告警。
而后咱们先去看的调用链，发现内容接口QPS曾经飙升到10W！
为什么？明明曾经加了接口缓存，按咱们加缓存的预期，很多申请应该打到缓存上，而不应该再查上游内容接口才对啊？或者很多人都这么认为，但错了就是错了。
像上图的谬误是很“低级”的，如果都这么应用，对于略微不强壮的上游零碎，将是劫难，如果真到那样子，往年的绩效也就好不到哪了。
错在哪里？
上述代码对spring cache应用，总结来说有上面的谬误：
- 1、在公有办法上加缓存
- 2、类外部办法调用加缓存
这些问题都是比拟致命的，咱们很多应用缓存的敌人基本不晓得也不分明不能这么应用。上面我把问题一一地剖析透了。
从Spring Cache原理解释为什么公有办法不能加缓存
Spring Cache通过注解，并借助Spring AOP实现缓存。关上源码包，定位到咱们的@Cacheable注解地位：
cache的实现都在context的org.springframework.cache包下。我的spring版本是5.3.14，其余版本也根本一样。
matches办法判断类或者办法中有没有cache相干的缓存注解，这个是怎么判断的呢？咱们一路跟进去，cas.getCacheOperations(method, targetClass))，到了AbstractFallbackCacheOperationSource类的getCacheOperations办法：
attributeCache是一个ConcurrentHashmap，只是把computeCacheOperations(method, targetClass)计算失去的后果缓存一下，下次再进来就不必耗费cpu从新计算获取。
computeCacheOperations办法中，真正解析办法上cache注解的中央在findCacheOperations办法：
一路跟进去，当咱们看到SpringCacheAnnotationParser类的parseCacheAnnotations办法时，就到看了spring把cache的相干注解进行解析，并把注解包装为CacheOperation类
看到这里就明确了吧，spring把类和办法上的cache注解包装起来并放到一个汇合Collection中，在aop切面上通过判断是否有CacheOperation作为切入点。
而后，到这里我想重点说一下的是，spring cache曾经做了判断，不反对非public办法上的缓存注解，逻辑在哪里呢？仔细的能够发现：
很显然的不反对非public办法，即便是protected办法都不行，更不用说private了！
这里再多说一下，看完cache的切入点代码，咱们也很容易找到办法拦截器：
咱们从execute办法一路跟进去，能够看到最初是在CacheAspectSupport类的execute办法实现对接缓存的读取或者更新。
如果咱们引入了三方的cache，比方Caffeine，那么，底层就是应用Caffeine.Cache来存储的。
如果想晓得如何应用三方缓存工具，能够看我另外一篇文章：
《人人都说好的Spring Cache！用起来！【文末送书】》
论断：
spring cache通过
AbstractFallbackCacheOperation#computeCacheOperations办法显式地不反对非public办法的注解缓存。
从Spring AOP原理解释为什么公有办法上不能加缓存
下面讲到了spring cache本人做了一层限度，不反对非public办法加缓存注解，那么，spring cache为什么这么做？如果只是看spring cache源码的逻辑，不加这个限度，不也一样是能够“走得通”么？
要解释这个问题，那就要从Spring AOP原理说起了。
咱们先把BookService的缓存注解地位调整一下，让办法可能失常走缓存逻辑：
启动咱们的spring容器，断点到咱们业务代码bookService.findByBookNameWithSpringCache(bookName)的中央：
看到了没，BookService援用是一个代理类，这也侧面阐明spring cache借用了aop的能力。
问题来了，为什么是cglib代理？
在咱们的常识外面，spring aop默认都是采纳java的动静代理，其次才会应用cglib代理。从spring官网文档也能够证实：
em……我没有应用接口，所以采纳了cglib代理。这个解释也只算对一半吧。（因为即便你换成了接口实现，最初还是没能如你所愿，还是cglib代理，感兴趣的敌人自行尝试）
还是说下为什么咱们运行始终都是cglib代理的起因吧。
这是spring boot搞的鬼，在咱们的启动类上有一个@SpringBootApplication注解，这是一套组合注解，咱们顺着这个注解外部的定义，找到@EnableAutoConfiguration，再找到@Import(AutoConfigurationImportSelector.class)
AutoConfigurationImportSelector类的process办法：
这外面有很多主动拆卸信息，依据AopAutoConfiguration（这个类定义在spring-boot下而不是spring-context下）的定义：
AopAutoConfiguration类的次要工作是依据配置参数应用注解@EnableAspectJAutoProxy，正文也有阐明：
该类启用的条件是：配置参数spring.aop.auto值不为false，咱们的spring-configuration-metadata.json中有配置：
AopAutoConfiguration又蕴含了如下两个内置配置类，别离对应配置参数spring.aop.proxy-target-class=true/false两种状况 :
当spring.aop.proxy-target-class缺省配置时默认也是true，咱们的spring-boot外面默认就是true，所以默认应用aop的cglib代理。
到这里，咱们就根本晓得spring-cache中应用到的aop为何始终应用cglib代理的起因。
说完cglib，终于能够回到主题上了，“为何不能在公有办法上应用cache注解”，如果从aop的角度去剖析，那么答案就是：因为cglib。
cglib实现动静代理，其底层采纳了ASM字节码生成框架，间接对须要代理的类的字节码进行操作，生成这个类的一个子类，并重写了类的所有能够重写的办法。
因为cglib的代理类应用的是继承，这也就意味着cglib不能代理final类，同时也不能对private办法进行代理！子类无奈重写private办法啊！
至于cglib是如何生成代理类的，这里不开展说了，前面有机会再专门出一个文章写一写，咱们到这里只有晓得，spring cache的实现应用了aop性能，而aop不反对对private公有办法的拦挡，所以也就不反对公有办法上的spring cache注解。
类外部办法调用不反对加缓存
通过下面的剖析，spring cahe的缓存性能是因为应用了aop，如此可知咱们的类是被cglib从新加强代理过的类。
如果是类外部办法调用，为什么就不能失效？
这个问题很简略，咱们在外部调用办法的中央打个断点，一看便知：
是吧，没有走代理，怎么可能应用得上缓存性能呢？
结语
我是tin，一个在致力让本人变得更优良的一般攻城狮。本人经历无限、学识肤浅，如有发现文章不妥之处，十分欢送加我提出，我肯定仔细斟酌加以批改。
保持创作不容易，你的正反馈是我保持输入的最弱小能源，谢谢！
最初！⏬⏬⏬
发表回复