Concurrency Risks of Object Escape in Spring AOP and Correct Advice Ordering

In the book *Java Concurrency in Practice* (chapters 3.2 and 3.5), object escape is identified as a source of concurrency safety issues and a guide is given on how to publish objects safely. In today’s Spring‑based development, AOP can easily introduce object escape, creating concurrency hazards.

Because AOP is frequently used to handle cross‑cutting concerns, an incorrect ordering of advices often results in business exceptions.

AOP‑induced object escape mainly concerns the escape of method input parameters and return‑value objects. These escaped objects usually involve the introduction of asynchronous threads and caching.

If an asynchronous thread and the main thread both modify the same object, a concurrency safety problem arises.

When an object is cached and accessed by multiple threads, any modification by one thread can also cause a concurrency safety problem.

Incorrect AOP ordering can lead to various business anomalies. For example, when a distributed‑lock annotation and @Transaction are used together, if the lock logic runs inside the transaction, the lock may be released before the transaction completes, causing data inconsistency. Therefore, the distributed‑lock AOP must execute before the transaction AOP.

Another example involves spring‑retry with @Retryable . If @Transaction intercepts before @Retryable , the snapshot read of InnoDB (ReadView) is created before the retry logic, making the retry ineffective. Hence, @Retryable must execute before @Transaction .

Similarly, when dynamic data‑source switching (implemented via AbstractRoutingDataSource ) is combined with @Transaction , the data‑source switching AOP must run before the transaction AOP; otherwise, the dynamic data‑source switch fails due to the transaction’s execution mechanism and ThreadLocal usage.

In summary, while AOP is widely used, it introduces pitfalls such as object‑escape‑related concurrency issues and problems caused by incorrect advice ordering (e.g., distributed lock vs. transaction, @Retryable vs. @Transaction , dynamic data‑source vs. transaction). Further pitfalls will be discussed in future posts.