How do you use a prototype or request-scoped bean from a Spring singleton?

Explains why ordinary injection resolves once and chooses providers, factories, scoped proxies, or explicit parameters for shorter-lived dependencies.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

If a prototype bean is injected directly into a singleton, Spring resolves that dependency while creating the singleton, so the singleton keeps that one prototype instance. To obtain a fresh prototype for each operation, inject an ObjectProvider, a narrow factory, or use supported method lookup. A request-scoped dependency is commonly represented by a scoped proxy that resolves the real target for the active request. Ordinary direct injection does not change lifetime on each method call.

Full answer below

Practice focus

Lifetime mismatch, deferred resolution, proxy boundaries, ownership, and avoidance of scope as hidden state.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
A longer-lived consumer needs a way to resolve the shorter-lived target at the time it is actually used.
If a prototype bean is injected directly into a singleton, Spring resolves that dependency while creating the singleton, so the singleton keeps that one prototype instance. To obtain a fresh prototype for each operation, inject an ObjectProvider, a narrow factory, or use supported method lookup. A request-scoped dependency is commonly represented by a scoped proxy that resolves the real target for the active request. Ordinary direct injection does not change lifetime on each method call.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I choose the mechanism by meaning. A provider communicates deferred container resolution, a domain factory can accept runtime parameters, and a scoped proxy lets a stable reference delegate to the current request target. Calling a request-scoped proxy from a background thread without an active request fails because no matching scope exists. Prototype cleanup after creation is also the caller's responsibility when the instance owns resources.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Expecting direct prototype injection to create one instance per call.
Using request scope from arbitrary background threads.
Forgetting cleanup of resource-owning prototypes.

How do you use a prototype or request-scoped bean from a Spring singleton?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement

Found this answer useful?