Introduction

Spring usually publishes fully initialized singleton beans safely, but that is not the same thing as making those beans thread-safe. The container manages object creation and reference visibility; you still have to design shared state correctly when multiple threads call the same bean.

Safe publication and thread safety are different

These two ideas often get blurred together:

• safe publication means other threads see a correctly initialized reference
• thread safety means concurrent calls do not corrupt state or observe broken invariants

Spring helps with the first one during normal singleton creation. It does not automatically guarantee the second one.

A stateless singleton is usually fine:

1import org.springframework.stereotype.Service;
2
3@Service
4public class PriceFormatter {
5    public String format(int cents) {
6        return "$" + (cents / 100.0);
7    }
8}

There is no mutable shared state, so concurrent calls are harmless.

A safely published bean can still be unsafe

Now consider a singleton with mutable state:

1import org.springframework.stereotype.Service;
2
3@Service
4public class RequestCounter {
5    private int count = 0;
6
7    public int next() {
8        return ++count;
9    }
10}

Spring may publish this bean reference safely, but the bean itself is not thread-safe. Two threads can race on count, and the increment can lose updates.

That is the core answer: Spring can safely expose the bean, but it does not make your mutable fields safe to share.

Why normal singleton publication is usually reliable

During context startup, Spring creates the bean, injects dependencies, runs initialization callbacks, and only then stores and exposes the singleton in the application context. Under normal lifecycle rules, dependent components see a fully initialized object rather than a half-constructed one.

Constructor injection reinforces that pattern:

1import org.springframework.stereotype.Service;
2
3@Service
4public class OrderService {
5    private final PriceFormatter formatter;
6
7    public OrderService(PriceFormatter formatter) {
8        this.formatter = formatter;
9    }
10
11    public String total(int cents) {
12        return formatter.format(cents);
13    }
14}

Using constructor injection and immutable dependencies makes publication easier to reason about.

Where things get tricky

The guarantees become less clear when a bean reference escapes too early. This can happen with circular dependencies, custom initialization tricks, or code that starts background threads during construction.

If a bean leaks this before initialization is complete, another thread may observe it too early. That is a Java safe-publication problem that happens inside a Spring application, not a special feature of Spring itself.

The practical advice is:

• do not start worker threads from constructors
• avoid circular dependencies when possible
• avoid publishing bean references manually during early initialization

Scope changes do not remove design responsibility

Singleton scope means one shared instance per application context. Prototype scope creates a new instance on each request from the container. Web scopes such as request or session narrow the lifetime further.

Those scopes change how much sharing happens, but they do not remove the need to think about concurrency. A singleton is safe if it is stateless or properly synchronized. A request-scoped bean is usually less exposed, but it can still cause problems if it hands mutable state to async work incorrectly.

The safest general rule for Spring beans is to prefer:

• stateless singleton services
• immutable collaborators
• explicit synchronization or concurrent primitives when state must be shared

Common Pitfalls

• Assuming singleton scope means automatic thread safety.
• Confusing safe publication with safe concurrent mutation.
• Storing request-specific data in singleton bean fields.
• Leaking bean references during construction or early initialization.
• Changing bean scope instead of fixing the underlying shared-state design.

Summary

• Spring normally publishes singleton beans in a safely initialized form.
• Safe publication does not make mutable singleton logic thread-safe.
• Stateless singleton beans are usually the safest default design.
• Mutable shared state still requires synchronization, atomic types, or a different architecture.
• Early reference leaks and circular-dependency edge cases are where publication guarantees get harder to reason about.