Spring RequestScope Bean Memory Leak via ScopedTargetProxy

RequestScope bean leak in Singleton beans via ScopedTargetProxy

0 reputation · 25 Dec 2024, 01:51 UTC

38.9K views0

When injecting Request-scoped beans into long-lived Singleton beans, Spring typically utilizes a ScopedTargetProxy to manage the lifecycle mismatch. While this allows the singleton to reference the proxy, memory leaks can occur if the underlying request context is not properly cleared after the HTTP request completes.

In high-concurrency environments using custom thread pools, the rapid creation and destruction of these proxies can lead to significant GC pressure. If a thread is returned to a pool without the request scope being explicitly closed, references to the request bean may persist in the heap. This is particularly problematic when manual ThreadLocal manipulation is introduced via custom filters.

What specific lifecycle conditions cause the ScopedTargetProxy to fail to release its reference to the target bean during asynchronous execution? How can one verify if the bean destruction callback is failing to trigger when the request scope closes prematurely in a thread pool?

Keep exploring this topic

@Async TaskExecutor transition to bounded queue timeout handling

Evaluating the transition from SimpleAsyncTaskExecutor to ThreadPoolTaskExecutor in Spring @Async to handle bounded queues and timeout behaviors.

Memory growth when repeatedly loading ApplicationContext with @Transactional beans lacking interfaces

Investigating memory growth caused by Spring @Transactional CGLIB proxies in short-lived ApplicationContext instances and whether forcing JDK proxies resolves the leak.

DataTables destroy() memory retention: diagnosing lingering event listeners and DOM references

Repeatedly creating and destroying DataTables instances can leave event handlers and DOM references behind depending on version. What heap-snapshot patterns distinguish DataTables-held retention from application-held references across 1.10.x and 1.13.x?

TempDir cleanup timing uncertain after test execution

Investigating the uncertain timing of @TempDir cleanup in JUnit 5: when are temporary directories actually deleted, and under what conditions might they persist and cause leaks?

Why the Proxy Persists After the Request

In a standard servlet environment the RequestScope clears its ThreadLocal map when the request ends. The ScopedTargetProxy itself holds no reference to the target bean; it merely asks the current scope for the instance. In an @Async method or a custom thread‑pool task, the request context is not automatically propagated. The proxy then resolves to null or a stale bean because the RequestAttributes still live in the original thread’s ThreadLocal. If the worker thread is reused without clearing that ThreadLocal, the bean remains reachable and the @PreDestroy callback never runs.

How to Verify

Add a @PreDestroy method that logs when it’s called; if it never fires, the scope never closed.
Take a heap dump after a request and look for the request‑scoped bean; persistent instances indicate a leak.
Inspect the worker thread’s ThreadLocal map (e.g., via JConsole or a debugger) to confirm RequestAttributes are still present.

Ensuring the request scope is explicitly closed—either by wrapping async work with RequestContextHolder.setRequestAttributes and clearRequestAttributes or by using DelegatingSecurityContextExecutorService—prevents the proxy from holding onto stale references.

RequestScope bean leak in Singleton beans via ScopedTargetProxy

0 answers

Your perspective belongs here.

1 question comment

Why the Proxy Persists After the Request

How to Verify