aop cache再讨论

还不如用JCS!

软件开发中,没有最好,只有最合理... 谢谢

个人观点：只不过是一种解决方法吧，其实大的系统要优化核心的频率最大的指令，全部都cache的概念听起来不错，但是不太好用，容易导致oom。我们现在的项目使用的是memorycache，不影响jvm的稳定性，出现问题容易定位。一种方法对一类问题是比较适合的，企业架构和互联网架构，电信架构是不一样的，关键看需求。

inteceptor 内部不应该关注 Pointcut, 应该用 AnnotationMethodMatcher 控制切入点

哦,理解了,3x

用在methodcache上没有问题,如果用到objectcache上好像不行

修改:看来要自己写AnnotationClassMatcher才行了



你说的方法确实是一种方案,也许可以这样,如果没有key的情况就使用类+方法名+参数,如果有key的情况,则用key.

不过我还是没有想到这样做到底有什么特别的优点,因为如果向上面这样实现,大多数程序员估计不喜欢用key的方式

为什么大多数程序员不喜欢用key的方式？我怎么觉得这个比默认的key策略（类+方法名+参数）灵活、实用呢？

问了一下身边的同事,都比较认同使用class+method+parameter的方式.他们的理由是这个key其实也用不到自己去控制,当然我和他们的观点是一样的,不过由于我和同事之间在技术上的观点有一定的同化性,所以你也可以了解一下身边同事的看法,这样才比较客观

缓存这么用是很显然的，如果你能原创于此，也是不错了。
但不过这样的设计很早很早就有了，参见06年网上关于aop cache的文章，以及更早的英文文章。具体实现06年不到开始，也有了 spring modules cache。跟你的实现差不太多，只是那个是兼容1.4的。

就具体应用而言，这种方案太weak了，除非是业务场景非常简单的情况，否则你的cache将不断面临着invalid，然后flush by cache，而不是remove by key。

spring modules cache项目也就是在这个问题上找不到解决方案，止步不前而迟迟未能推出0。10版本。

更好的解决方案也是有的，就是固定Key+EL表达式结合param的动态key。Cache本身也应该居于namespace的概念。不要总想着什么根据method+param自动生成key，缓存最重要的就是key。一旦你把key隐藏了，也就意味着flush的时候无法定位到具体key了。

annotation作为AOP pointcut是个很好的趋势，除了spring2推出的@Transactional以外，还应该有很多应用。最起码，非常适合缓存这种需要精确粒度（缓存决不能搞什么get*的pointcut，那就歇菜了），而且业务逻辑又很简单的切面操作了。

bless

aopcache这个思想确实不是我原创,其实我在文章一开始就注明了,它的出现也不是06年,而是04年就有了,但是思想是思想,实现是实现,我至少我到现在还没有发现有谁的aopcache实现和我一样,说到这里我不禁怀疑你没有看这篇文章,我用的annotation来实现aop cache的,同时也可以通过annotation来指定缓存的过期时间,你说我不是原创,麻烦你把别人的东西拿出来看看可以吗(我们可以在代码上比对一下).你可以看看我的其他文章,哪篇不是原创,非原创的东西我不会发在这里的

而且缓存这种东西不是一篇文章可以写完的,如果让我系统的写下来的话,估计会超过5篇,所以本文只讨论aop cache实现方法,与aop cache的使用场景,它只是一把锤子.如果你有比较好的关于aop cache的实现,望不吝赐教

为什么不把两个Annotation合并在一起写呢，比如：
@Target(ElementType.METHOD | ElementType.TYPE)  
@Retention(RetentionPolicy.RUNTIME)  
public @interface MethodCache {  
 
}