Spring切入点指示符差异（在vs执行中）
<aop:pointcut expression="within(my.app.dao.impl.*)" id="commonDaoOperation"/>
<aop:pointcut expression="execution(public * my.app.dao.impl.*.*(..))" id="commonDaoOperation"/>
使用“Eclipse memory Analyzer”分析了应用程序服务器的“堆转储”之后，我发现我的应用程序消耗了450 MB，而“org.springframework.aop.aspectj.aspectJExpressionPointCut”类的实例消耗了这450MB中的30%.
AspectJExpressionPointCut的每个实例（大约）占用6 MB，这是因为每个实例都管理与java.lang.Reflect.Method实例匹配的缓存，而且令人惊讶的是，缓存了很多java方法（我的pointcut表达式没有提到的方法）。
在阅读了Spring文档之后，我决定使用第一种方法（在pointcut指示符中），现在AspectJExpressionPointcut的每个实例占用的内存要少得多。
问题是关于...他们在性能上有什么不同...
提前多谢...
共有1个答案
Spring文档解释了其中的区别：
- execution--为了匹配方法执行连接点，这是在使用Spring AOP时将使用的主要切入点指示符
- 与某些类型中的连接点的限制内匹配（使用Spring AOP时在匹配类型中声明的方法的执行）
换句话说，执行匹配一个方法，而内的匹配一个类型。
-
大家：我在找一个有更多知识的人来检查我对蜂巢和火花的理解 我一直在研究不同的大型数据库解决方案，并试图理解Hive和Spark在执行方面的差异。我尝试安装Hadoop、Hive和Spark，看看它们的性能如何。我能够让Hadoop和Spark工作。我无法让Hive去工作。
-
我有一个由Maven管理的Spring项目。而不是使用pointcut指示符，如下所示： 我想使用点切指示符，如下所示： 但是，我的IDE（IntelliJ）告诉我，支持，即使我删除了中的。 我想提到上面的例子，pointcut designator正在工作，而Spring AOP并不支持所有的AspectJ pointcut designator。 这个答案展示了如何在不使用Spring的情况下
-
在Java中的AOP（AspectJ）中，当我们谈到方法切入点时，我们可以将它们区分为两个不同的集合:和。 基于这里的这些资源： 执行vs.调用连接点 AOP中调用和执行的区别 null 将匹配callerObject.SomeMethod（）方法中的连接点，因为RuntimeTypeObject的是CompiletimeTypeObject，但是此方法调用pointcut： 将不匹配，因为对象的
-
根据维基百科，DFS和BFS的实现基本上有两种不同。 它们是： 1）DFS使用堆栈，而BFS使用队列。（我理解这一点）。 2）DFS延迟检查是否发现顶点，直到顶点从堆栈中弹出，而不是在推动顶点之前进行此检查。 我不能理解第二个区别。我的意思是为什么DFS在从堆栈中删除后访问节点，而BFS在将节点添加到队列之前访问节点。 谢谢 额外信息： 在上述两种算法的一个简单实现中，我们使用一个布尔数组（让我们
-
8.2. Spring中的切入点API 让我们看看Spring是如何处理切入点这个重要概念的。 8.2.1. 概念 Spring的切入点模型使得切入点可以独立于通知类型进行重用，这就使得针对不同 advice使用相同的pointcut成为可能。 org.springframework.aop.Pointcut 是最核心的接口，用来将 通知应用于特定的类和方法，完整的接口定义如下： public i
-
我试图在方法注释上创建一个Aeyj切入点，但我总是用不同的方法失败。我使用的是aspectj自动代理（我在Spring上下文中没有配置其他编织）。我的类如下所示： 所以我想知道为什么aspectj不会创建切入点。我设法使用执行（**（…）使其工作抛出一些exc）这对我来说很好，但我仍然想知道我做错了什么。 另外，由于是在接口中定义的，我指定了实现类的注释，有没有办法让它以这种方式工作？其他代理机制