Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Deadlock possible with AspectJ aspects and multi-threading [SPR-14241] #18814
When AspectJ style aspects are used, the aspects are eagerly converted to Spring Advisors, but the AspectJ aspect object is not eagerly created. It is lazily created at the time of its first use. This can be seen in ReflectiveAspectJAdvisorFactory's use of LazySingletonAspectInstanceFacotryDecorator.
When a singleton Spring bean is created, it grabs the lock of singleton bean map. If, inside its constructor, it calls a function that has an uninitialized aspect wrapped around it, it will then grab the lock in LazySingletonAspectInstanceFactoryDecorator.getAspectInstance.
If, in a different thread (started after some other bean finishes construction), a call is made that invokes the same aspect, which has not yet been initialized, the lock in LazySingletonAspectInstanceFactoryDecorator.getAspectInstance will be acquired and then the singleton aspect bean will be instantiated. This requires going through the singleton bean instantiation code, which acquires the singleton bean map lock.
This leads to a deadlock. I've attached a stack trace from jstack of this situation occurring. I think one potential solution would be to eagerly instantiate the singleton AspectJ aspects, not just the advisors that wrap them.
Affects: 3.2.16, 4.1.7
Backported to: 3.2.17
Juergen Hoeller commented
Indeed, the use of separate locks leads to quite some deadlock potential here. We opted for a shared-lock approach in other places (see #17336), and this also seems to work here:
In 4.3, we can have first-class support for this in the
As a side note, this also reveals that