@Component vs @Bean in Spring: Differences and When to Use Each (2026)

@Component is a class-level annotation: you put it on a class you own, and Spring's component scanning finds that class and instantiates it for you — calling the constructor and injecting dependencies automatically. @Bean is a method-level annotation that lives inside a @Configuration class: you write the method body yourself, construct the object however you like, and return it. Spring registers whatever you return as a bean in its IoC container.

The practical rule is simple. A class you own and can annotate → use @Component (or one of its stereotypes). A third-party class, or any class that needs non-trivial construction logic — a builder, a factory call, conditional wiring — → use @Bean. This guide reflects Spring 6 / Spring Boot 3, running on the jakarta.* namespace with Java 17 or later; the same distinction applies to earlier versions.

The Short Answer

Both @Component and @Bean register beans in the same Spring IoC container, and at runtime those beans behave identically — singleton by default, eligible for injection anywhere. The difference is who creates the object and where the declaration lives: @Component means Spring scans your class, calls its constructor, and hands you the result; @Bean means you write a method that does the construction, and Spring calls that method once and stores what you return.

Bottom line: Same container, same kind of bean — @Component lets Spring build your class, @Bean lets you build it yourself.

What Is @Component

@Component is a class-level stereotype annotation. When Spring starts up, its component scanning mechanism — activated by @ComponentScan or, in Spring Boot, by @SpringBootApplication — walks the classpath looking for classes annotated with @Component or any annotation that is itself meta-annotated with @Component. For each one it finds, Spring instantiates the class (preferring constructor injection), wires in its dependencies, and registers the result as a bean. The full bean creation and lifecycle happens automatically.

@Component is the root of a hierarchy of spring stereotype annotations that carry additional semantics:

• @Service — marks service-layer classes; functionally identical to @Component but signals architectural intent.
• @Repository — marks persistence-layer classes; additionally wraps unchecked persistence exceptions in Spring's DataAccessException hierarchy (exception translation).
• @Controller / @RestController — marks web-layer classes; @RestController combines @Controller with @ResponseBody.
• @Configuration — marks configuration classes; it is itself a @Component, so it is detected by scanning, but it also triggers CGLIB proxying of its @Bean methods (more on that below).

The key constraint is that @Component can only go on a class you control and can modify. You cannot put it on a class from an external library.

What Is @Bean

@Bean is a method-level annotation that tells Spring: "call this method, take the return value, and register it as a bean." The method normally lives inside a @Configuration class, though it can also appear in a plain @Component class with important behavioral differences explained below.

The method return type becomes the bean's primary type, and the method name becomes the default bean name (overridable with the name attribute). Any dependencies the method needs are declared as its parameters — Spring resolves and injects them before calling the method, exactly as it would for any other injection point. This means you can write arbitrary Java in the method body: call a builder, read a property, apply conditional logic, or call a factory.

Because you write the construction code yourself, @Bean works for any class you can import — your own classes, third-party classes, even classes from the JDK. That makes it the only option when you need to register a bean for a class you cannot annotate.

@Component vs @Bean: Head-to-Head

Which One Should You Use?

In practice, most Spring applications use both. @Component handles the overwhelming majority of cases — your services, repositories, and controllers. @Bean steps in wherever @Component cannot or should not.

• Use @Component (or a stereotype) when the class is in your codebase and you can annotate it — the common case for your services, repositories, and controllers.
• Use @Bean when the class is third-party (you can't add an annotation to it), construction needs logic (conditional wiring, builders, factory calls), or you need several beans of the same type with different configuration.

Code: The Same Bean Both Ways

With @Component, Spring finds the class and builds it:

@Service // a @Component specialization — still found by scanning
public class OrderService {
    private final PaymentClient paymentClient;
 
    // constructor injection — Spring supplies the dependency
    public OrderService(PaymentClient paymentClient) {
        this.paymentClient = paymentClient;
    }
}
 
@Configuration
@ComponentScan("com.example")
public class AppConfig { }

With @Bean, you build it yourself inside a configuration class:

@Configuration
public class AppConfig {
 
    // You construct it; the parameter is injected by Spring
    @Bean
    public OrderService orderService(PaymentClient paymentClient) {
        return new OrderService(paymentClient);
    }
}

Both produce the same singleton OrderService bean in the IoC container. Which you choose depends on who owns the class and how complex its construction is — not on any difference in how the resulting bean behaves at runtime.

@Configuration vs "Lite Mode" — The Exam Trap

This is the subtlety that separates candidates who have read Spring's source from those who have only read the surface.

When @Bean methods live inside a @Configuration class, Spring creates a CGLIB subclass proxy of that configuration class. The proxy intercepts every @Bean method call: if the bean has already been created, the proxy returns the same singleton instance rather than running the method body again. This means calling one @Bean method from another is safe — you always get the shared singleton.

@Configuration // proxied: beanB() reuses the SAME beanA() singleton
public class AppConfig {
    @Bean public A beanA() { return new A(); }
    @Bean public B beanB() { return new B(beanA()); } // same A instance
}

When @Bean is placed inside a plain @Component class — called "lite mode" — Spring does not create a CGLIB proxy. The class is used as-is, so calling one @Bean method from another runs the real method body again and creates a new instance each time. The two calls to beanA() return different objects.

@Component // NOT proxied: calling beanA() here creates a NEW A each time
public class AppConfig {
    @Bean public A beanA() { return new A(); }
    @Bean public B beanB() { return new B(beanA()); } // different A instance!
}

Remember: If your @Bean methods call each other, use @Configuration — not @Component. In "lite mode" there is no proxy, no singleton guarantee across method calls, and the result is subtle state duplication that is hard to debug.

@Component vs @Bean for Interviews and the Exam

This distinction is a staple screening question in Java interviews, and for good reason: a precise answer signals that the candidate understands Spring's IoC container, not just its annotations. The one-line answer to deliver: "@Component is class-level and Spring instantiates it via scanning; @Bean is method-level and you instantiate it yourself — both land in the same container." Then expand with the third-party class use case and the CGLIB proxy trap.

For certification, this topic falls squarely in the Container and Dependency Injection domain of the 2V0-72.22 exam. See our Spring interview questions and Spring Boot interview questions for more questions in this format, and follow the Spring Professional preparation guide for a structured study path. Try a few free practice questions to see how well you can apply the concept under exam conditions.

Frequently Asked Questions

What is the difference between @Component and @Bean?

@Component is placed on a class and Spring instantiates it automatically via component scanning; @Bean is placed on a method inside a @Configuration class where you construct the object yourself. Both register beans in the same IoC container — the difference is who writes the construction code.

When should I use @Bean instead of @Component?

Use @Bean when you cannot annotate the class directly (third-party libraries), when construction requires non-trivial logic such as a builder or factory call, or when you need multiple beans of the same type with different configurations.

Can I use @Bean inside a @Component class?

Yes, but it runs in "lite mode" with no CGLIB proxy, so calling one @Bean method from another creates a new instance instead of reusing the singleton. Use @Configuration when @Bean methods call each other.

What are stereotype annotations in Spring?

@Service, @Repository, and @Controller are specializations of @Component. They are all detected by component scanning; @Repository also adds persistence exception translation that converts vendor-specific exceptions into Spring's DataAccessException hierarchy.

Are @Component and @Bean beans singletons by default?

Yes. Both produce singleton-scoped beans unless you explicitly change the scope with @Scope. See the Spring bean scopes guide for a full breakdown of available scopes and when to use each.

Next Steps

The rule is short: annotate a class you own with @Component (or a stereotype like @Service or @Repository), and use @Bean in a @Configuration class whenever you need programmatic construction or are dealing with a third-party class. Master the CGLIB proxy distinction and you have covered the most common exam trap in this area. To reinforce the concept, try the free practice questions, go deeper on the Spring bean lifecycle and bean scopes, and check the Spring interview questions to see how these ideas appear in real screening rounds.