使用 aop 对性能的影响
我们已经开始使用 spring aop 来横切应用程序的各个方面（目前是安全性和缓存）。
尽管我的经理完全了解这项技术的好处，但他还是担心这项技术对性能的影响。
我的问题，您是否遇到过使用aop（特别是spring aop）引入的性能问题？
We have started to use spring aop for cross cutting aspects of our application (security & caching at the moment).
My manager worries about the performance impact of this technology although he fully understands the benefits.
My question, did you encounter performance problems introduced by the use of aop (specifically spring aop)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
理论上，如果您使用 AOP 做硬耦合可以做的事情，那么就不存在性能问题，没有开销，也没有额外的方法调用，除非您无缘无故地编织。 AOP 框架为您提供了一种消除硬耦合并分解横切关注点的方法。
在实践中，AOP框架会引入3种类型的开销：
有关更多详细信息，您可以参考 当aop代码执行时。
只是要小心如何实现建议，因为横向代码对于装箱/拆箱和反射来说是一种诱惑（就性能而言代价高昂）。
如果没有 AOP 框架（硬耦合您的横切关注点），您可以更轻松地开发您的假定建议（专用于每种处理），而无需装箱/拆箱和反思。
你必须知道大多数 AOP 框架不提供完全避免装箱/拆箱和反射的方法。
我开发了一个来满足大多数缺失的需求，集中于三件事：
您可以在这里找到我的开源项目：Puresharp API .net 4.5.2+ 之前NConcern .NET AOP 框架
In theory, if you use AOP do to what you could do with hard coupling, there is no performance issue, no overhead and no extra method calls unless you weave for nothing. AOP Framework offers you a way to remove the hard coupling and factorize your cross-cutting concern.
In practice, AOP Framework can introduce 3 types of overhead:
For more details you can refer to when-is-aop-code-executed.
Just be careful how you implement an advice because transversal code is a temptation for boxing/unboxing and reflection (expensive in term of performance).
Without an AOP Framework (hard coupling your cross-cutting concerns) you can develop your presumed advices (dedicated for each treatment) easier without boxing/unboxing and reflection.
You have to know that most AOP Framework don't offer the way to avoid totally boxing/unboxing and reflection.
I developed one to respond to most of missing needs concentrated to 3 things :
You can find my open source project here : Puresharp API .net 4.5.2+ previously NConcern .NET AOP Framework
您是否想过有一个 AOP 工具可以在需要时在运行时向对象添加方面？ .net 有一个“使用动态装饰器向对象添加方面”(http://www.codeproject.com/KB/architecture/aspectddecorator.aspx)。 我相信你可以为Java写一个类似的。
Have you ever thought about an AOP tools that adding aspects to object at runtime when you need? There is one for .net "Add Aspects to Object Using Dynamic Decorator" (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). I believe you can write a similiar one for Java.
如果您正在使用某种框架来处理方面，则可能会出现一些性能问题。接下来，如果您在某个框架之上创建抽象，并且方面处理是从框架完成的，那么很难找出与性能问题相关的问题的原因。 如果你真的关心性能并且更关心小时间片，我建议编写自己的方面。没有人想重新发明轮子，但有时为了更好它可能是最好的。你可以编写自己的 AOP 联盟抽象实现。
If you are using some one framework for aspects there can be some performance issues .Next if you are creating abstraction above some one framework and aspects handling is done from framework then its very difficult to find out the cause of the problem relating to performance issues . If you are really concern about performance and small time slice concern more ,i suggest to write own aspects .No one want to reinvent the wheel but sometime for better it can be best.You can write own implementation of AOP alliance abstraction .
我在当前项目的批处理过程中使用了 Spring AOP 来事务管理数据库。
起初，我们认为不会出现性能问题，但我们没有考虑到我们调用数据库数千次的等式。 aop 中的一个方面调用不会对性能产生太大影响，但会乘以数千倍，结果发现新系统比旧系统更糟糕，因为这些额外的方法调用。
我想说 aop 是一个很好用的系统，但请尝试注意向您的应用程序添加了多少方法调用
i have used spring AOP in a batch process in my current project to transaction manage a database.
At first, it was figured that there wouldn't be a performance problem, but we didn't figure into the equation that we called the database thousands of times. one aspect call in aop doesn't affect performance much, but multiply that by thousands, and it turns out the new system was worse than the old one, due to these extra method calls.
I'd say that aop is a great system to use, but try to take note on how many methods calls are added to your application
问题11年后，看看这种情况是多么堕落。
示例：绝大多数人认为将一个简单的 @Transactional spring java 注释放在某个方法上并让 spring 在调用者和被调用者代理组件之间建立桥梁是可以的和正常的。 现在他们有 20 多个不可调试的“神奇”代码堆栈帧。 JIT 编译器很快就会被超越，无法再尝试内联，或者最终会因生成大量类而导致内存膨胀。
在这个‘框架用户’的时代，懒惰是没有极限的。 难怪简单的 http 调用的 e2e 时间从 100 毫秒缩短到 10 秒。 难怪您需要 2GB 来运行一个以前需要 128MB 运行的糟糕的 servlet 容器。 不要让我开始讨论记录异常堆栈跟踪的成本......
11 years after the question, look how degenerated this situation is.
Example: the vast majority think it is ok and normal to put a simple @Transactional spring java annotation to some method and let spring do the bridge between caller and callee proxied components. Now they have 20+ stackframes of undebuggable 'magic' code. The JIT compiler is rapidly exceeded and can no longer attempt inlining, or ends up bloating memory with tons of generated classes.
There is no limit to lazyness in this era of 'framework users'. No wonder e2e times for trivial http calls went from 100ms to 10 seconds. No wonder you need 2GB to run a lousy servlet container that used to run in 128MB. And don't get me started on the cost of logging exception stacktraces...
只要您能够控制您的AOP，我认为它是有效的。 无论如何，我们确实存在性能问题，因此根据自己的推理，我们无法完全控制;)这主要是因为编写方面的任何人都必须完全理解所有其他 > 系统的各个方面以及它们如何相互关联。 如果你开始做“聪明”的事情，你很快就会超越自己。 在一个有很多人只看到系统的一小部分的大型项目中做聪明的事情在性能方面可能是非常危险的。 这个建议可能在没有 AOP 的情况下也适用，但是 AOP 让你以一些真正优雅的方式搬起石头砸自己的脚。
Spring 还使用代理进行作用域操作，这是一个很容易出现意外性能损失的区域。
但考虑到你有控制权，AOP 唯一真正的痛点是对调试的影响。
As long as you have control of your AOP I think it's efficient. We did have performance problems anyway, so by own reasoning we were not fully in control ;) This was mostly because it's important that anyone that writes aspects has full understanding of all the other aspects in the system and how they interrelate. If you start doing "smart" things you can outsmart yourself in a jiffy. Doing smart things in a large project with lots of people who only see small parts of the system can be very dangerous performance-wise. This advice probably applies without AOP too, but AOP lets you shoot yourself in the foot in some real elegant ways.
Spring also uses proxying for scope-manipluations and thats an area where it's easy to get undesired performance losses.
But given that you have control, the only real pain point with AOP is the effect on debugging.
如果性能是一个问题，我们使用 AspectJ 效果很好。
因为它使用字节码编织（编译时与运行时之间存在很大差异），所以它是最快的 AOP 框架之一。 请参阅：AOP 基准
If performance is going to be a concern, we have used AspectJ to great effect.
Because it uses bytecode weaving (compile time vs. runtime makes quite the difference) it's one of the fastest AOP frameworks out there. See: AOP Benchmarks
当我使用它时，我没有 - 但我的应用程序不是你的应用程序。
如果您将它用于在非常紧密的循环中使用的调用，则机会会显着影响性能。 如果它只是用于每个请求检查一次安全性并缓存各种内容，我看不出它有什么重要意义 - 但这就是为什么您应该对您的应用程序进行分析和基准测试。
我意识到“使用您的应用程序进行测量”可能不是您正在寻找的答案，但它很可能是您猜测会得到的答案:)
When I used it, I didn't - but then my application isn't your application.
If you use it for calls which are used in a very tight loop, there's the opportunity for a significant performance hit. If it's just used to check security once per request and cache various things, I can't see how it's likely to be significant - but that's why you should profile and benchmark your app.
I realise that "measure with your app" probably isn't the answer you were looking for, but it may well be the one you guessed you'd get :)
如果您使用基于代理的 AOP，则您正在讨论每个应用的方面 1 个额外的 Java 方法调用。 对性能的影响几乎可以忽略不计。 唯一真正关心的是代理的创建，但这通常只在应用程序启动时发生一次。 SpringSource 博客对此有一篇很棒的文章：
http: //blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/
If you are using proxy-based AOP, you are talking about 1 additional Java method invocation per aspect applied. The performance impact there is pretty negligible. The only real concern is the creation of the proxies but this usually happens just once on application startup. The SpringSource blog has a great post on this:
http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/