Circular Dependencies in Spring Boot 4: Why Startup Fails and 4 Ways to Fix It

Versions. Spring Boot 4.1.1 and Spring Framework 7.0.9 (both poms were published to Maven Central on 20 August 2026), on Java 25 (LTS, Temurin 25.0.4.1). The start-up failures are Spring Boot runs without a web server. A few scenarios use a plain Spring context instead, and the article says where, because plain Spring allows circular references by default and Boot does not.

The report: three beans in a ring, and no hint which arrow to cut

@Service
public class NotificationService {

    private final OrderService orders;

    public NotificationService(OrderService orders) {
        this.orders = orders;
    }

    public String confirm(String sku) {
        return "e-mail says: " + orders.describe(sku);
    }
}

***************************
APPLICATION FAILED TO START
***************************

Description:

The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  notificationService defined in file [<core-beans>/target/classes/com/ankurm/corebeans/cycles/broken/NotificationService.class]
↑     ↓
|  orderService defined in file [<core-beans>/target/classes/com/ankurm/corebeans/cycles/broken/OrderService.class]
↑     ↓
|  paymentService defined in file [<core-beans>/target/classes/com/ankurm/corebeans/cycles/broken/PaymentService.class]
└─────┘


Action:

Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to true.

┌─────┐
|  clock defined in com.ankurm.corebeans.cycles.beanmethods.BeanMethodCycle
↑     ↓
|  calendar defined in com.ankurm.corebeans.cycles.beanmethods.BeanMethodCycle
└─────┘

Going deeper

• Constructor, setter and field injection, and what each does with a cycle in plain Spring versus Boot: Dependency Injection in Spring Boot 4
• The same failure for a two-bean cycle, captured from a packaged jar: core-di transcript 19
• Spring Boot reference: SpringApplication

Why Spring cannot simply build them in some order

--- exception classes, outermost first ---
UnsatisfiedDependencyException -> UnsatisfiedDependencyException -> UnsatisfiedDependencyException -> BeanCurrentlyInCreationException

--- root cause ---
org.springframework.beans.factory.BeanCurrentlyInCreationException
Error creating bean with name 'notificationService': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

--- creation order (one line per bean the container began to create) ---
start creating notificationService
start creating orderService
start creating paymentService

context started: true
getBean(OrderService.class) failed: UnsatisfiedDependencyException -> UnsatisfiedDependencyException -> UnsatisfiedDependencyException -> BeanCurrentlyInCreationException
root cause: Error creating bean with name 'orderService': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

spring.main.allow-circular-references    default=False
spring.main.lazy-initialization          default=False

Going deeper

• @Autowired Explained for how the container picks candidates before it ever gets to a cycle
• Spring Framework reference: Dependencies and Configuration in Detail (circular dependencies)
• The exact failure per scenario: the module README indexes all thirty-odd transcripts

Turning on allow-circular-references: what it repairs, and what it hides

    @PostConstruct
    void init() {
        Trace.log("SecondService @PostConstruct sees first.isReady() = " + first.isReady());
    }

--- flag on ---
started: true
start creating firstService
FirstService constructed
start creating secondService
SecondService constructed
SecondService @PostConstruct sees first.isReady() = false
FirstService @PostConstruct done, ready=true

--- Spring Boot, constructor cycle, spring.main.allow-circular-references=true ---
FAILED: BeanCurrentlyInCreationException: Error creating bean with name 'ctorA': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

started: true
CachedFirst bean is a proxy      : true (CachedFirst$$SpringCGLIB$$0)
CachedSecond.first is a proxy    : true
CachedSecond.first == the bean   : true
two calls through the injected reference return 1 and 1, method body ran 1 time(s)

--- eager start-up (the default) ---
start creating com.ankurm.corebeans.cycles.allowed.AsyncFirst
start creating com.ankurm.corebeans.cycles.allowed.AsyncSecond
AsyncSecond constructed, identity 2f0ed952
AsyncSecond.setFirst on instance 2f0ed952 received a proxy: false
AsyncSecond constructed, identity 5a8816cc
AsyncSecond.setFirst on instance 5a8816cc received a proxy: true
started: true
AsyncFirst bean is a proxy    : true
AsyncSecond.first is a proxy  : true
AsyncSecond.first == the bean : true
log line from DefaultListableBeanFactory (INFO):
  Bean 'com.ankurm.corebeans.cycles.allowed.AsyncFirst' marked for pre-instantiation (not lazy-init) but currently initialized by other thread - skipping it in mainline thread

--- spring.main.lazy-initialization=true, then getBean(AsyncFirst.class) ---
started: true
getBean(AsyncFirst.class) failed: BeanCurrentlyInCreationException
root cause: Error creating bean with name 'com.ankurm.corebeans.cycles.allowed.AsyncFirst': Bean with name 'com.ankurm.corebeans.cycles.allowed.AsyncFirst' has been injected into other beans [com.ankurm.corebeans.cycles.allowed.AsyncSecond] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.

A clean start-up proves less than it used to. With the flag on, a cycle that involves an @Async bean was repaired silently at start-up on Spring Framework 7.0.9, at the price of constructing one bean twice, and produced the raw-version error on the first lazy getBean. Whether you see the exception depends on which path reaches the bean first. I did not run Framework 6 to compare, so I cannot say when this changed; the accordion below records what I can support and what I am inferring.

--- DefaultListableBeanFactory.preInstantiateSingleton(String, RootBeanDefinition): exception table ---
Exception table:
from    to  target type
157   162   165   Class org/springframework/beans/factory/BeanCurrentlyInCreationException

Going deeper

• The Spring Cache Abstraction for what the proxy does once it is in place
• @Async in Spring Boot 4 for the proxy and self-invocation rules that apply to any @Async bean
• Spring Boot reference: SpringApplication, which documents the property and its default

Fix 1: redesign — the ring is usually a missing fourth bean

@Service
public class OrderCatalog {

    public String describe(String sku) {
        return "1 x " + sku;
    }
}

@Service
public class NotificationService {

    private final OrderCatalog catalog;

    public NotificationService(OrderCatalog catalog) {
        this.catalog = catalog;
    }

    public String confirm(String sku) {
        return "e-mail says: " + catalog.describe(sku);
    }
}

started: true
place("kettle") -> order placed: charged, e-mail says: 1 x kettle

Going deeper

• Full source of the redesigned package: RedesignConfig.java and its four classes
• Spring Framework reference on dependency resolution and cycles

Fix 2: publish an event instead of calling back

@Service
public class PaymentService {

    private final ApplicationEventPublisher events;

    public PaymentService(ApplicationEventPublisher events) {
        this.events = events;
    }

    public String charge(String sku) {
        events.publishEvent(new PaymentCaptured(sku));
        return "charged";
    }
}

    @EventListener
    void onPaymentCaptured(PaymentCaptured event) {
        if (event.sku().equals("boom")) {
            throw new IllegalStateException("mail server down");
        }
        Trace.log("listener on thread " + Thread.currentThread().getName()
                + ": e-mail says: " + orders.describe(event.sku()));
    }

started: true
place("kettle") -> order placed: charged
listener on thread main: e-mail says: 1 x kettle

--- what the publisher sees when the listener throws ---
place("boom") threw IllegalStateException: mail server down

An event is a call with the caller’s name removed. The listener ran on the main thread, inside the publisher’s call, and when it threw, place("boom") threw the same exception. Publishing an event does not make the reaction asynchronous, isolated or optional. It only removes the compile-time dependency. If the reaction must not fail the operation, or must wait until a transaction commits, that takes deliberate choices, which the article on Spring application events covers.

Going deeper

• Spring Application Events: @EventListener, @TransactionalEventListener and Async Events
• Spring Framework reference: standard and custom events

Fix 3: @Lazy — a proxy stands in until the first call

    /** @Lazy makes Spring inject a proxy and look the real OrderService up on the first call. */
    public NotificationService(@Lazy OrderService orders) {
        this.orders = orders;
    }

started: true
NotificationService holds a com.ankurm.corebeans.cycles.lazy.OrderService$$SpringCGLIB$$0
place("kettle") -> order placed: charged, e-mail says: 1 x kettle

started: false
exception classes: BeanCreationException -> AopConfigException -> IllegalArgumentException
root cause: java.lang.IllegalArgumentException: Cannot subclass final class com.ankurm.corebeans.CycleFixesTest$FinalTarget

--- @Lazy on the parameter, target is an ordinary singleton ---
started: false
root cause: cannot reach the payment provider

--- @Lazy on the parameter AND on the target bean ---
started: true
first call threw: BeanCreationException -> BeanInstantiationException -> IllegalStateException
root cause: cannot reach the payment provider

started: false
exception classes: BeanCreationException -> UnsatisfiedDependencyException -> BeanCurrentlyInCreationException
root cause: Error creating bean with name 'cycleFixesTest.LazyUserA': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

Going deeper

• Dependency Injection in Spring Boot 4, where the same @Lazy proxy is shown on a two-bean cycle
• Spring Framework reference: lazy-initialized beans

Fix 4: ObjectProvider — look it up at the call site

@Service
public class NotificationService {

    private final ObjectProvider<OrderService> orders;

    /** Nothing is resolved here: the provider is a handle, not the bean. */
    public NotificationService(ObjectProvider<OrderService> orders) {
        this.orders = orders;
    }

    public String confirm(String sku) {
        return "e-mail says: " + orders.getObject().describe(sku);
    }
}

started: true
place("kettle") -> order placed: charged, e-mail says: 1 x kettle

--- the same provider, but getObject() is called inside the constructor ---
started: false
root cause: Error creating bean with name 'cycleFixesTest.EagerNotifier': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

--- the provider needs no proxy, so a final class is fine ---
started: true
hello() -> hello

Going deeper

• Spring Bean Scopes, where the same provider fetches a fresh prototype per call
• Spring Framework reference: @Autowired and ObjectProvider

Cycles that do not look like A → B → A

@Component
static class Dispatcher {
    private final List<Handler> handlers;

    Dispatcher(List<Handler> handlers) {
        this.handlers = handlers;
    }

    String dispatch(String message) {
        return handlers.stream().map(h -> h.handle(message)).toList().toString();
    }
}

@Component
static class RedispatchingHandler implements Handler {
    private final Dispatcher dispatcher;

    RedispatchingHandler(Dispatcher dispatcher) {
        this.dispatcher = dispatcher;
    }

    @Override
    public String handle(String message) {
        return "seen " + message;
    }
}

--- Handler injects the Dispatcher ---
started: false
exception classes: UnsatisfiedDependencyException -> UnsatisfiedDependencyException -> BeanCurrentlyInCreationException
root cause: Error creating bean with name 'hiddenCyclesTest.Dispatcher': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

--- Handler injects ObjectProvider<Dispatcher> ---
started: true
dispatch("ping") -> [seen ping (dispatcher available: true)]

started: false
exception classes: BeanCreationException
root cause: Error creating bean with name 'b' defined in com.ankurm.corebeans.HiddenCyclesTest$DependsOnCycle: Circular depends-on relationship between 'b' and 'a'

Going deeper

• Spring Framework reference: using depends-on
• Why Your Spring Boot App Takes 8 Seconds to Start, for the trade-off lazy initialisation actually buys

Which fix, and whether the ring should exist at all

Should you even keep the cycle? Usually not. Extracting a bean leaves the code with one fewer thing to explain, while @Lazy and a provider both leave the ring in place and deserve a comment saying why. A @Lazy or a provider is fine for glue you do not own or a registry that really does need to know its members, and a poor default for two application services that grew into each other. If a fix is cheap to reverse and the redesign is not, take the cheap one and write down what would justify the redesign. The one setting I would not take is the flag: it hides the question instead of answering it.

Going deeper

• Run everything yourself: the module README has the quick-start and the index of transcripts; ./scripts/run-all.sh regenerates all of them

Further reading

• Companion repository for this article: asmhatre/spring-boot-demo, core-beans module
• Other articles in this series: Constructor vs Setter vs Field injection, @Autowired Explained, Spring Bean Scopes, Spring Bean Lifecycle
• On this site: @Async in Spring Boot 4, The Spring Cache Abstraction, @Transactional propagation and isolation
• Spring Framework reference: dependency resolution and circular dependencies
• Spring Framework reference: @Autowired, @Lazy and ObjectProvider
• Spring Framework reference: lazy-initialized beans
• Spring Boot reference: SpringApplication
• Spring Boot 2.6 release notes (circular references prohibited by default)