---

🟢 Junior Level

AOP (Aspect-Oriented Programming) is a programming paradigm designed to isolate and modularize Cross-Cutting Concerns (infrastructure logic) from core business logic.

What are Cross-Cutting Concerns?

In enterprise applications, certain technical capabilities are required across multiple distinct architectural layers and business services:

• Transaction Management: Opening database connections, committing, and rolling back.
• Security & Authorization: Verifying user roles and permissions before method entry.
• Auditing & Logging: Recording who performed which operation and execution timestamps.
• Performance Metrics: Measuring method execution time and tracking latency.
• Caching: Checking in-memory caches before querying downstream databases.

Without AOP (Code Tangling & Scattering): Infrastructure code is copied and pasted into the beginning and end of every service method, violating the Single Responsibility Principle (SRP) and DRY (Don’t Repeat Yourself).

With AOP (Modular Declarative Architecture): Business methods contain 100% pure domain logic. Cross-cutting tasks are extracted into an Aspect class and applied declaratively via annotations or pointcut expressions.

Without AOP (Scattered & Tangled Code):         With AOP (Clean Modular Separation):
┌──────────────────────────────────────┐        ┌──────────────────────────────────────┐
│ OrderService.createOrder()           │        │ ExecutionTimeAspect (@Aspect)        │
│  • Start DB Transaction (Infra)      │        │  • Logs start/finish & latency       │
│  • Check Security Permissions (Infra)│        └──────────────────┬───────────────────┘
│  • Pure Order Business Logic (Domain)│                           │ (Intercepts execution)
│  • Log Performance Metrics (Infra)   │                           ▼
│  • Commit DB Transaction (Infra)     │        ┌──────────────────────────────────────┐
└──────────────────────────────────────┘        │ OrderService.createOrder()           │
                                                │  • Pure Order Business Logic (Domain)│
                                                └──────────────────────────────────────┘

Practical Code Example

package com.example.service;

import com.example.aspect.LogExecutionTime;
import org.springframework.stereotype.Service;

@Service
public class OrderService {

    // Infrastructure concern applied declaratively via custom annotation
    @LogExecutionTime
    public void processOrder(Long orderId) {
        // Pure domain logic: no timers, try/finally blocks, or manual logging
        System.out.println("Processing order: " + orderId);
    }
}

package com.example.aspect;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class ExecutionTimeAspect {

    @Around("@annotation(LogExecutionTime)")
    public Object measureExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long startTime = System.currentTimeMillis();
        try {
            // Delegates to target business method
            return joinPoint.proceed();
        } finally {
            long duration = System.currentTimeMillis() - startTime;
            System.out.println("Method " + joinPoint.getSignature().getName() 
                    + " executed in " + duration + " ms");
        }
    }
}

---

🟡 Middle Level

The 4 Core Terminology Pillars of AOP

Join Point (WHERE it CAN happen) ──> Any possible execution point in a program (in Spring AOP, strictly method execution).
Pointcut   (WHERE it WILL happen) ──> A predicate expression matching specific Join Points (e.g., matching an annotation or package).
Advice     (WHAT is executed)     ──> The cross-cutting code that runs at a matched Join Point (before, after, or around).
Aspect     (THE CONTAINER)        ──> The modular class encapsulating Pointcuts and Advices into a cohesive Spring bean.

The 5 Types of Advice

Annotation	Execution Timing	Capabilities and Constraints
@Before	Runs before the target method execution	Can inspect arguments or throw exceptions to abort execution; cannot alter the return value or bypass method entry.
@AfterReturning	Runs after successful method completion	Accesses the returned value via the returning attribute; cannot prevent method return (unless throwing an exception).
@AfterThrowing	Runs only if an unhandled exception is thrown	Accesses the thrown exception via the throwing attribute; useful for alerting/auditing, but does not swallow the exception.
@After (finally)	Runs unconditionally upon method exit (success or error)	Analogous to a standard Java finally block; used for resource cleanup.
@Around	Wraps the entire method invocation	The most powerful advice: can modify method arguments, alter the return value, catch and swallow exceptions, or skip invoking proceed() altogether.

Spring AOP vs Full AspectJ

┌────────────────────────────────────────────────────────┬────────────────────────────────────────────────────────┐
│                      Spring AOP                        │                        AspectJ                         │
├────────────────────────────────────────────────────────┼────────────────────────────────────────────────────────┤
│ • Implemented via Runtime Dynamic Proxies              │ • Implemented via Bytecode Weaving (CTW, PCW, LTW)     │
│ • Target must be a Spring-managed Bean                 │ • Can target any Java POJO (even created via `new`)    │
│ • Join Points: Only `public` method executions         │ • Join Points: Methods, constructors, field accesses    │
│ • Self-Invocation (`this.method()`): FAILS             │ • Self-Invocation: WORKS (woven into class bytecode)    │
│ • Tooling: Zero compiler configuration                 │ • Tooling: Requires AspectJ compiler (`ajc`) or Agent  │
│ • Use Case: 95% of standard enterprise microservices   │ • Use Case: High-frequency tracing, domain-level DDD   │
└────────────────────────────────────────────────────────┴────────────────────────────────────────────────────────┘

---

🔴 Senior Level

Execution Pipeline: The Interceptor Chain (Onion Architecture)

Under the hood, Spring converts each Aspect into an internal Advisor (pairing one Pointcut and one Advice). When a client invokes a method on a proxied bean, Spring delegates the call to an ordered chain of MethodInterceptors:

Caller (e.g. Controller)
       │
       ▼
 ┌─────────────────────────────────────────────────────────────────┐
 │ Aspect 1: SecurityInterceptor (@Order(1))                       │
 │   ┌─────────────────────────────────────────────────────────────┐
 │   │ Aspect 2: TransactionInterceptor (@Order(2))                │
 │   │   ┌─────────────────────────────────────────────────────────┐
 │   │   │ Aspect 3: CustomLoggingAspect (@Order(3))               │
 │   │   │   ┌─────────────────────────────────────────────────────┐
 │   │   │   │ Target Bean Instance (Business Logic Execution)     │
 │   │   │   └─────────────────────────────────────────────────────┘
 │   │   │ Method exit: Logging completes                          │
 │   │   └─────────────────────────────────────────────────────────┘
 │   │ Method exit: Transaction commits or rolls back              │
 │   └─────────────────────────────────────────────────────────────┘
 │ Method exit: SecurityContext cleaned up                         │
 └─────────────────────────────────────────────────────────────────┘
       │
       ▼
Caller Receives Result

Execution is driven recursively by ReflectiveMethodInvocation.proceed():

public Object proceed() throws Throwable {
    // If all interceptors have been traversed, invoke the target method
    if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
        return invokeJoinpoint();
    }
    // Fetch and advance to the next interceptor in the chain
    MethodInterceptor interceptor = 
        (MethodInterceptor) this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
    return interceptor.invoke(this);
}

Precedence and Ordering (@Order / Ordered)

When multiple aspects advise the exact same method, execution order is non-deterministic unless explicitly configured using @Order(int) or by implementing org.springframework.core.Ordered:

@Aspect
@Component
@Order(1) // Outermost layer: Executes FIRST on entry, LAST on exit
public class SecurityAspect { ... }

@Aspect
@Component
@Order(2) // Inner layer: Executes SECOND on entry, SECOND TO LAST on exit
public class TransactionAspect { ... }

[!IMPORTANT] Order Rule: Lower numerical values indicate higher priority. The aspect with @Order(1) acts as the outer skin of the onion, wrapping the aspect with @Order(2).

Thread-Safety Invariant for Aspect Classes

By default, classes annotated with @Aspect and @Component are instantiated as Spring Singletons:

• A single aspect instance is shared concurrently by hundreds of active HTTP request threads.
• Never declare mutable instance fields in an Aspect class!

@Aspect
@Component
public class DangerousAspect {

    // ❌ FATAL BUG: Instance state shared across all concurrent servlet threads!
    // Causes Data Races, context leakage between requests, and security vulnerabilities.
    private Long currentUserId; 

    @Before("execution(* com.example.service..*(..))")
    public void captureUser(JoinPoint joinPoint) {
        this.currentUserId = SecurityUtils.getUserId(); // RACE CONDITION!
    }
}

Solution: Keep aspect beans strictly stateless. Any transient request metadata must be obtained directly from JoinPoint.getArgs(), RequestContextHolder, or thread-safe ThreadLocal containers.

Java 21 Virtual Threads & Loom: Carrier Thread Pinning Hazard

In modern Spring Boot 3.2+ applications running on Java 21 with Virtual Threads (spring.threads.virtual.enabled=true):

• If a custom aspect or interceptor uses synchronized blocks or methods:

  @Around("execution(* com.example.service..*(..))")
  public Object badSynchronized(ProceedingJoinPoint pjp) throws Throwable {
      synchronized (this) { // ❌ DANGEROUS: Pins carrier thread on blocking I/O!
          return pjp.proceed();
      }
  }
  

• If pjp.proceed() performs blocking I/O (e.g., database queries or HTTP calls), the virtual thread pins its underlying OS carrier thread (ForkJoinPool.commonPool), preventing other virtual threads from executing. Under heavy load, this leads to carrier pool starvation and severe throughput collapse.
• Solution: Replace all synchronized blocks in aspects with java.util.concurrent.locks.ReentrantLock.

---

4 Tricky Questions

1. What is the fundamental difference between Spring AOP and full AspectJ, and when would you choose AspectJ in production?

Answer: Spring AOP is a lightweight, proxy-based runtime framework (using CGLIB or JDK Dynamic Proxies). It can only intercept public method executions on beans registered inside the Spring ApplicationContext. It cannot intercept internal self-invocations (this.method()), static methods, constructors, or domain entities instantiated with new.

Full AspectJ modifies the actual JVM bytecode using Weaving (Compile-Time Weaving with ajc, Post-Compile Weaving, or Load-Time Weaving via a Java Agent). It can intercept any join point: private methods, constructors, field reads/writes, and self-invocations on any Java object.

AspectJ is chosen in production when:

1. Intercepting calls inside rich domain models (DDD entities created via new).
2. Requiring interception of internal method calls (self-invocation) without architectural refactoring.
3. Sub-microsecond latency-critical systems where proxy allocation overhead is unacceptable.

2. How does aspect precedence (@Order) behave during both the method entry phase and the method exit phase?

Answer: Aspects follow an Onion (LIFO / Stack) execution pattern:

• On Method Entry (Before / Around-entry): Lower @Order numbers execute first. An aspect with @Order(1) executes before an aspect with @Order(2).
• On Method Exit (AfterReturning / AfterThrowing / After / Around-exit): Lower @Order numbers execute last. The aspect with @Order(1) wraps everything and receives control only after the @Order(2) aspect has completed its exit handling.

This mirrors the Servlet Filter chain: the filter with the highest priority processes the request first and processes the response last.

3. Why must classes annotated with @Aspect strictly avoid mutable instance fields?

Answer: In Spring, @Aspect classes managed as @Component beans are created with singleton scope by default. A single aspect instance intercepts invocations from all worker threads in the application concurrently.

If an aspect class contains mutable instance variables to store state (such as the current user, start timestamp, or execution ID), concurrent threads will overwrite each other’s data, causing classic race conditions, corrupted audit trails, and security leaks across requests. All state must remain localized within the advice method scope (local variables) or accessed via thread-safe constructs like ThreadLocal.

4. What happens under the hood if you omit joinPoint.proceed() inside an @Around advice? Can @Around return a completely different type than the target method?

Answer:

• Omitting joinPoint.proceed(): The target business method is never executed. The @Around advice completely usurps execution control. The method call returns whatever value the advice returns (or null), effectively bypassing the business logic. This technique is precisely how caching aspects work: if a cache hit occurs, the aspect returns the cached value without calling proceed().
• Returning a different type: The value returned by @Around must be assignment-compatible with the target method’s declared return type. If @Around returns an incompatible type (e.g., returning a String when the method expects an Integer), the caller will throw a ClassCastException at runtime when the proxy tries to cast the return value.

---

🎯 Interview Cheat Sheet

30-Second Elevator Pitch

AOP (Aspect-Oriented Programming) is a paradigm that extracts cross-cutting concerns (transactions, security, caching, logging, metrics) into modular classes called Aspects, keeping business logic clean and adhering to SRP and DRY. In Spring, AOP is implemented via runtime dynamic proxies (CGLIB / JDK Proxy) and applies strictly to public methods of Spring-managed beans. Key concepts:

• Join Point: Possible point of interception (method execution in Spring).
• Pointcut: Expression defining which Join Points to intercept.
• Advice: Code executed (@Before, @AfterReturning, @AfterThrowing, @After, @Around).
• Aspect: Class combining Pointcut + Advice.
• Full AspectJ: Uses bytecode weaving (CTW/LTW) to intercept private methods, constructors, fields, and self-invocations on any Java object.

Advice Types Quick Reference

Advice	Trigger Condition	Can Abort Method?	Can Alter Return Value?
@Before	Before method start	Yes (throw exception)	No
@AfterReturning	After clean return	Yes (throw exception)	No (can only read)
@AfterThrowing	After exception thrown	Yes (rethrow / wrap)	No
@After	Always (finally)	Yes (throw exception)	No
@Around	Wraps entire call	Yes (omit proceed())	Yes (complete control)

Red Flags (DO NOT Say)

• ❌ “Spring AOP modifies compiled .class files on disk.” (AspectJ does bytecode weaving; Spring AOP generates dynamic in-memory proxy classes at runtime).
• ❌ “Spring AOP can easily intercept private or protected methods.” (Proxies cannot intercept non-public methods; AspectJ is required for that).
• ❌ “Advice classes are created new for each thread, so instance variables are safe.” (Aspect beans are Spring Singletons; instance fields cause race conditions).
• ❌ “Forgetting joinPoint.proceed() in @Around advice will still execute the target method automatically.” (The target method will never be invoked).

Related Topics

• What is aspect advice pointcut join point
• What is a proxy in Spring
• When does Spring create a proxy
• What does the Transactional annotation do
• Why Transactional does not work with self-invocation