Every non-trivial service method ends up wearing the same three coats: log what happened, measure how long it took, and wrap it in a transaction. Written by hand, those coats are cross-cutting concerns — they cut across every class, belong to none of them, and drown the business rule they surround. After a year you have 200 methods with 200 slightly different copies of the same try/finally.

Where did the other 17 lines go? They did not disappear — Spring moved them out of the class and around it. The OrderService bean you inject is not an OrderService at all but a generated stand-in (a proxy) that runs the transaction and timer code and only then calls your method. That substitution is the whole of Spring AOP.

Two properties of this model explain almost every AOP surprise you will meet. First, the advice only runs when a call crosses the proxy boundary — code inside the target calling its own methods never touches the proxy. Second, the proxy has to be created and handed out by the container; an object you build with new has no proxy and so no advice.

AOP is a programming idea; Spring AOP and AspectJ are two implementations with very different mechanics. Spring AOP is deliberately small: it uses runtime proxies, supports only method-execution join points on Spring beans, and borrows AspectJ’s annotation style and pointcut language (@Aspect, @Around, execution(...)) without using its weaver. Full AspectJ rewrites bytecode.

In a Spring Boot 3 application, @Aspect classes need the AspectJ library on the classpath (for the annotations and the pointcut parser) — that is what spring-boot-starter-aop brings in — but there is still no weaving. Boot’s AopAutoConfiguration turns on @EnableAspectJAutoProxy with proxyTargetClass=true by default (spring.aop.proxy-target-class=true), meaning class-based CGLIB proxies are the default for everything, including @Transactional beans that implement interfaces.

A proxy must be usable wherever the target was. There are exactly two ways to achieve that on the JVM, and Spring uses both. The choice is made in DefaultAopProxyFactory.createAopProxy(): if the target class has interfaces and proxyTargetClass is false it builds a JdkDynamicAopProxy; otherwise a ObjenesisCglibAopProxy (Spring’s repackaged CGLIB, org.springframework.cglib).

Why Objenesis matters. Old CGLIB proxies called the target’s constructor to create the subclass instance, which ran constructor side effects twice. Since Spring 4 the proxy instance is allocated without running any constructor. Consequence: the proxy object’s own fields are null/default. Spring routes every non-final call to the real target, so you never notice — unless a method is final. A final method runs on the proxy shell, sees null fields, and throws a baffling NullPointerException on an apparently non-null injected dependency.

A pointcut expression decides which method executions receive advice. It is evaluated by AspectJ’s pointcut parser against each method of each candidate bean, once, during auto-proxy creation — not on every call (though some designators such as args, this, @annotation with binding may need a small runtime check). The result for each method is cached in the advisor chain.

Combine with &&, ||, ! and give pieces names with @Pointcut so expressions are reusable and readable.

Spring supports five advice types. Four are conveniences built on top of the fifth, @Around, which is the only one that controls whether and how the target runs.

Ordering across aspects. Advice from different aspects forms nested layers. The aspect with the highest precedence (smallest @Order value) is the outermost: its "before" part runs first and its "after" part runs last. Between advice of the same type inside one aspect the order is undefined — split them into separate aspects if you need determinism. Built-in advisors take part too: @EnableTransactionManagement(order=...) defaults to Ordered.LOWEST_PRECEDENCE, so a custom aspect with a smaller order wraps the transaction (and runs even if commit fails), while a larger order would run inside it.

Here is a complete, production-shaped aspect: an @Audited annotation that records who did what, to which argument, with what outcome and how long it took. It uses a custom annotation as the pointcut (explicit and greppable beats package patterns), binds the annotation, handles success and failure and never changes the method’s result.

The single most common AOP bug, and a standard interview question: a method that calls another method of the same class bypasses the proxy. The call is this.other(), and this is the target, not the proxy. Advice on other() — transaction, cache, async, security — silently does not run.

Several of the best-known Spring annotations carry no logic at all — they are markers read by a built-in advisor. Understanding that makes their limits predictable: they inherit every property of proxies from the previous chapters.

All proxy-based ones are registered as Advisors (a pointcut that looks for the annotation + an interceptor), and one shared auto-proxy creator — InfrastructureAdvisorAutoProxyCreator or, once @EnableAspectJAutoProxy is active, AnnotationAwareAspectJAutoProxyCreator (bean name org.springframework.aop.config.internalAutoProxyCreator) — wraps each eligible bean once, with all matching advisors in a single proxy. That is why one bean can be @Transactional, @Cacheable and carry your aspect without being proxied three times.

To prove to yourself that there is no magic, build the entire mechanism in plain Java — no Spring, compiled with javac. Part A is a JDK dynamic proxy with a chain of advices (the same onion as Spring’s ReflectiveMethodInvocation: an index into a list, and proceed() advances it). It also demonstrates self-invocation. Part B is a hand-written subclass proxy, which is exactly what CGLIB generates.

Read the output: the proxy class is not the implementation (is Impl? false), advice ran in registration order on the way in and reverse order on the way out, and placeTwice got one transaction even though it calls place twice — the inner calls were this.place() inside the target.

Note batch(): advice ran once for batch but not for the two withdraw calls inside it — same bug, different proxy flavour. And audit(), being final, was not overridden, so nothing could intercept it.

When AOP misbehaves, do not guess — ask the container what it built.

• What is a proxy in Spring and why does the container need it?
  A generated stand-in that has the target’s type, holds the target and an interceptor chain, and is injected instead of the raw bean. It lets cross-cutting code run around method calls without editing the class.
• JDK vs CGLIB proxy — difference and Boot’s default?
  JDK = java.lang.reflect.Proxy, implements interfaces only. CGLIB = generated subclass; needs a non-final class. Boot defaults to CGLIB (spring.aop.proxy-target-class=true) so injecting by class works. Trap: final methods are not intercepted.
• Why does @Transactional not work when I call another method in the same class?
  The call is this.method() on the target, bypassing the proxy where the TransactionInterceptor lives. Fix: separate bean, self-injection, AopContext.currentProxy() or AspectJ mode.
• Where exactly does Spring create the proxy?
  In a BeanPostProcessor, AbstractAutoProxyCreator.postProcessAfterInitialization → wrapIfNecessary. For circular references it can create an early proxy in getEarlyBeanReference.
• Advice types and which one can change the return value?
  Before, AfterReturning, AfterThrowing, After, Around. Only @Around (via ProceedingJoinPoint.proceed()) can replace the result, skip the target, or retry.
• How do you order two aspects?
  @Order or Ordered. Smaller value = higher precedence = outermost: first on the way in, last on the way out.
• Spring AOP vs AspectJ?
  Spring AOP: runtime proxies, method execution on beans only. AspectJ: weaving; any join point, any object, works on self-calls. Trap: Spring uses AspectJ’s annotation/pointcut syntax, not its weaver.
• Can you advise a private method, a constructor or a field access?
  Not with Spring AOP. Private/final/static methods are skipped; constructors and field access are not join points. Use AspectJ weaving.
• A bean works, but AopUtils.isAopProxy returns false. Why?
  No advisor’s pointcut matched any of its methods, so the auto-proxy creator returned it unwrapped — or it was created before the creator was ready.
• How would you prove a method is called through the proxy?
  Log AopUtils.isAopProxy(this) from inside (false — this is the target), or inspect the stack for DynamicAdvisedInterceptor / JdkDynamicAopProxy.invoke.