A test suite starts failing with a Mockito error saying static mocking is already registered in the current thread, and the failure lands on a test that does not mock anything. What causes this, and how do you prevent it?
answer
- thread-local registration, one per type per thread
- second overlapping registration → immediate error
- failure appears in a LATER, innocent test
- try-with-resources or @AfterEach close()
- parallel execution makes leaks intermittent
basics
~20 sA MockedStatic scope was opened and never closed, so the thread-local registration survives into later tests on the same thread. Any attempt to register the same type again fails, and unrelated tests see mocked statics. Always open the scope in try-with-resources, or close it in teardown.
solid answer
~50 s`Mockito.mockStatic` registers the mock in a **thread-local** slot for that type. Mockito deliberately refuses a second overlapping registration for the same type on the same thread and throws, because two live registrations would make behaviour ambiguous. So a leaked scope produces two symptoms: unrelated tests silently run against mocked statics, and the next test that legitimately calls `mockStatic` on that type blows up with "static mocking is already registered in the current thread". The leak sources I look for: a scope assigned to a field in `@BeforeEach` with no `close()` in `@AfterEach`; an exception thrown between `mockStatic` and `close()` in hand-written code with no `finally`; and a scope opened inside a helper that returns it with nobody owning it. Fixes: always try-with-resources; if the scope must span a test, hold it in a field and close it unconditionally in `@AfterEach`. Parallel execution puts tests on different threads, which changes which tests are poisoned but does not make leaks safe.
code
java · 17 lines// Leaks if close() is ever skipped
private MockedStatic<Clock> clock;
@BeforeEach
void setUp() { clock = Mockito.mockStatic(Clock.class); }
@AfterEach
void tearDown() { if (clock != null) clock.close(); } // must always run
// Preferred: the block that opens it closes it
@Test
void safe() {
try (MockedStatic<Clock> scoped = Mockito.mockStatic(Clock.class)) {
scoped.when(Clock::systemUTC).thenReturn(fixed);
assertEquals(fixed, service.now());
}
}go deeper
Know that the scope must be closed and that try-with-resources is the standard way to guarantee it.
Explain the thread-local registration and why a second overlapping registration on the same thread fails.
Trace the failure back to the leaking test, name the concrete leak shapes, and set the narrow-scope rule for the team.
Treat it as a suite-hygiene and flakiness issue: enforce the resource pattern in review or lint, and reduce reliance on static mocking so the class of failure shrinks.
## What registration means When `Mockito.mockStatic(Foo.class)` is called, the inline mock maker installs an interceptor on Foo's static methods and records, in a thread-local map, that this thread currently routes Foo's statics to this control handle. The interception itself is global to the JVM at the bytecode level; the *routing decision* is per thread, which is what allows tests on other threads to keep calling the real methods. `MockedStatic.close()` removes the thread-local registration. `closeOnDemand()` does the same but does not complain if it was already closed. ## Why a second registration is an error If a second `mockStatic(Foo.class)` were allowed on the same thread while the first is live, every static call would have two candidate handles, with unclear precedence and unclear verification semantics. Mockito chooses fail-fast: it throws immediately, with a message naming the thread and, in recent versions, pointing at the location where the earlier registration was created. That message is the single most useful clue — it tells you which test leaked, even though the failure surfaces in a different one. ## Typical leak shapes **Field without teardown.** A scope opened in `@BeforeEach` and stored in a field, with no `@AfterEach` calling `close()`. Every test after the first fails. **Missing finally.** Manual `MockedStatic<Foo> m = mockStatic(Foo.class); ... m.close();` where the exercise phase throws. The assertion failure is the visible failure; the leak is collateral, and the *next* test carries the strange error. **Early return.** A conditional `return` between open and close in a helper method. **Nested scopes.** Opening the same type twice inside one test — for example a helper that opens a scope while the test already has one — fails immediately even without a leak. **Shared scope across test classes.** A static field or a JUnit extension that opens the scope once for a suite, then a test method opens its own. ## The remedies 1. **try-with-resources by default.** It is the whole reason `MockedStatic` implements `AutoCloseable`; the scope closes even when the body throws. 2. **Symmetric lifecycle when a field is unavoidable.** Open in `@BeforeEach`, close in `@AfterEach`, and make the close unconditional so a null field does not mask the real failure. 3. **Narrow scopes.** Open around the exercise phase only. Narrow scopes leak less, damage less when they do, and avoid mocking statics during arrange and assert. 4. **Do not share scopes between tests.** The cost of reopening is small compared with the debugging cost of a shared handle. ## Interaction with parallel execution and lifecycle With parallel test execution enabled, test methods can run on different threads. A registration made on one thread is invisible to another — so a scope opened in a `@BeforeAll` on the launcher thread may not apply to test methods at all, and a leak poisons only the tests that happen to reuse the same thread from the pool. That makes symptoms intermittent and ordering-dependent, which is exactly the flakiness profile teams waste days on. The rule that removes the whole class of problems is: the same block of code that opens a scope closes it. ## Verifying hygiene in CI A cheap safeguard is a base test class or extension that, after each test, asserts no static mock registration remains for the types the suite touches — or simply a code-review rule that `mockStatic` may only appear as a try-with-resources resource. Static analysis can enforce the latter, and it is worth doing in codebases where static mocking is common.
- The failure message names a different test class than the one that failed. How do you use that?That name is the location where the still-open registration was created, so it identifies the leaking test, not the victim. Go to that class, find the mockStatic call, and check whether every path from it reaches close() — usually an exception path or an early return. The failing test itself is innocent; changing it is the wrong move.
- Does enabling parallel test execution make static-mock leaks safer, since tests get their own threads?No. Threads come from a pool and are reused, so a leaked registration poisons whichever later test picks up that thread — the damage becomes non-deterministic rather than absent. Parallelism also means a scope opened on one thread does not apply to code running on another, which can make correct-looking tests silently exercise the real static.
saying these in an interview costs you the question
- Blaming the test that reports the error rather than the one that leaked the scope.
- Closing the scope only on the happy path, without try-with-resources or finally.
- Assuming Mockito automatically cleans up static mocks after each test method.
- Sharing one MockedStatic across a test class or suite to 'save time'.
- Believing parallel execution eliminates the problem because each test gets a fresh thread.