Introduction

In Spring, @Configuration(proxyBeanMethods = true) tells the container to create a CGLIB proxy around the configuration class so calls between @Bean methods still return managed singleton beans. Setting it to false disables that interception and treats each @Bean method like a plain factory method.

You should set it to false when the configuration class is "lite": its @Bean methods are independent and do not call one another to obtain managed beans. In that case, disabling proxies reduces indirection and makes startup a little simpler.

What the Proxy Does

With the default proxy behavior, Spring subclasses the configuration class. When one @Bean method calls another, the proxy intercepts the call and returns the bean from the application context rather than constructing a new instance directly.

That matters in code like this:

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3
4@Configuration(proxyBeanMethods = true)
5class AppConfig {
6    @Bean
7    ServiceA serviceA() {
8        return new ServiceA(serviceB());
9    }
10
11    @Bean
12    ServiceB serviceB() {
13        return new ServiceB();
14    }
15}

Because of the proxy, serviceB() inside serviceA() resolves to the managed bean, not to a fresh new ServiceB() each time.

When false Is the Right Choice

Set proxyBeanMethods = false when:

• each @Bean method is self-contained
• dependencies are injected through method parameters instead of direct method calls
• you do not rely on inter-bean calls inside the same configuration class

This style is common in modern Spring Boot auto-configuration and in application code that prefers explicit dependencies.

A safe pattern looks like this:

1import org.springframework.context.annotation.Bean;
2import org.springframework.context.annotation.Configuration;
3
4@Configuration(proxyBeanMethods = false)
5class AppConfig {
6    @Bean
7    ServiceB serviceB() {
8        return new ServiceB();
9    }
10
11    @Bean
12    ServiceA serviceA(ServiceB serviceB) {
13        return new ServiceA(serviceB);
14    }
15}

This version does not need proxy interception because Spring resolves ServiceB through the method parameter.

Why Many Teams Prefer false

Using false encourages a cleaner configuration style. Instead of one @Bean method reaching into another, each bean declares its dependencies explicitly.

Benefits include:

• fewer CGLIB proxies
• slightly simpler startup behavior
• configuration code that is easier to reason about
• fewer surprises when reading or testing configuration classes

The performance gain is usually modest, so clarity is the main reason to prefer it.

When You Should Keep It true

Keep proxyBeanMethods = true if one @Bean method directly calls another and you expect those calls to respect container semantics.

If you turn it off in that situation, you can accidentally create extra instances:

1@Configuration(proxyBeanMethods = false)
2class BrokenConfig {
3    @Bean
4    ServiceA serviceA() {
5        return new ServiceA(serviceB());
6    }
7
8    @Bean
9    ServiceB serviceB() {
10        return new ServiceB();
11    }
12}

Here serviceB() inside serviceA() is just an ordinary Java method call. It does not go through the container, so ServiceA may receive a different instance than the managed bean.

A Practical Rule

If your configuration follows constructor-like dependency style through method parameters, use false. If it relies on configuration-method self-invocation, keep true or refactor.

That rule is simple and prevents most mistakes.

Common Pitfalls

• Turning it off without checking for direct @Bean method calls inside the same class.
• Assuming false changes bean scope rules by itself. It changes method interception, not bean scope semantics.
• Using self-invocation patterns that make configuration behavior harder to reason about.
• Expecting a major performance win when the real benefit is mostly code clarity.
• Mixing lite configuration style with proxy-dependent configuration style in the same class.

Summary

• 'proxyBeanMethods = true preserves container semantics for inter-bean method calls.'
• 'proxyBeanMethods = false is best when @Bean methods are independent.'
• Prefer false when dependencies are passed as method parameters.
• Keep true if one @Bean method directly calls another and expects the managed bean.
• The main benefit of false is simpler, clearer configuration code.