Aop资料整理

1.Spring AOP 实现机制2

http://cjhz.iteye.com/blog/2245161

http://itindex.net/detail/29812-aop

2.跟我学aspectj之一 ----- 简介

http://blog.csdn.net/zl3450341/article/details/7673938

http://blog.csdn.net/wudishine/article/details/8058944

http://opoo.org/aspectj-compile-time-weaving/

http://jinnianshilongnian.iteye.com/blog/1415606

3.classLoader

一个自定义类加载器ClassLoader示例 http://blog.csdn.net/ns_code/article/details/17881581

深入Java虚拟机】之四：类加载机制 http://blog.csdn.net/chenjiazhan/article/details/37714401

4.深入理解JDK动态代理：java.lang.reflect.InvocationHandler

　　http://rejoy.iteye.com/blog/1627405?page=3#comments

 

https://stackoverflow.com/questions/39448543/run-time-aop-vs-compile-time-aop

• Source code weaving: Aspect code is injected as source code statements into your application source code. This is some kind of preprocessor approach. No AOP framework in the Java world uses this approach nowadays, but there used to be some in the early days of AOP.
  • The advantage would be complete independence of any runtime libaries or special AOP compilers during runtime, if done right.
  • The disadvantage would be bloated source code and a preprocessing / code generation step before compilation. You would always need the generated source code for debugging.
• Compile-time weaving: Aspect code is woven into your application by a special compiler.
  • The advantage is no runtime overhead for aspect weaving. The only thing you need is a small runtime library on your classpath.
  • The disadvantage is that you cannot defer the decision if you want to weave aspects into your application at all to runtime. But this is only a problem when dealing with debugging or tracing aspects not needed all the time. Another disadvantage is that this approach only works for code under your control, i.e. you need to have the source code. It does not work for 3rd party libs.
• Binary weaving: Aspect code is woven into existing class files after compilation rather than during compilation.
  • The advantage is that it also works for 3rd party code you do not have the source code for. This approach can also be mixed with compile-time weaving. You also avoid the overhead of load-time weaving (see below).
  • The disadvantages are similar to compile-time weaving: You cannot unapply an aspect once it is woven into the code, merely deactivate its execution by pointcuts such as if(). But this can be quite efficient.
• Load-time weaving (LTW): A weaving agent/library is loaded early when your VM/container is started. It gets a configuration file with rules describing which aspects should be woven into which classes.
  • The advantage is that you can dynamically decide if/what to weave. If done via byte-code transformation and not via dynamic proxies or reflection (see below), the resulting bytecode is equally efficient as the one created via compile-time or binary weaving. Another advantage is that like binary weaving it works for your own code as well as 3rd party code, as long as the weaving agent can "see" it, i.e. it happens in a child classloader.
  • The disadvantage is the one-time weaving overhead during application start-up because weaving is done while classloading occurs.
• Proxy-based LTW: This special LTW form is used by Spring AOP while AspectJ does the previous 3 forms listed above. It works by creating dynamic proxies (i.e. subclasses or interface implementations) for aspect targets.
  • I cannot think of any special advantage other than maybe your framework of choice (such as Spring) happens to support it.
  • Disadvantages are limitation to public, non-static methods and runtime overhead due to the proxy-based approach. It also does not capture internal method calls, i.e. when a proxied class calls one of its own methods because those calls are not captured by the proxy. Special types of pointcuts such as constructor interception, member variable read/write access and many more are not supported, making this more of an "AOP lite" approach. But it can be sufficient for your purposes.

Generally, good aspect compilers such as AspectJ create very efficient bytecode and do not heavily rely on reflection during runtime. If your aspect framework of choice does rely on reflection, probably it is not very fast. But maybe it is fast enough, depending on how heavily you use aspects.

Probably I have written too much already, but I could write even more. This is why I am stopping now. Besides, this kind of question is not well-suited to StackOverflow because it can lead to philosophical discussions and opinion-based debates. I hope I managed to be fairly objective/impartial even so.

Source code weaving