MockitoAnnotations.openMocks(this) returns an AutoCloseable. What does closing it do, what goes wrong in a large suite if you never close it, and how does it differ from the older initMocks call?

## What openMocks returns and why ```java private AutoCloseable mocks; @BeforeEach void init() { mocks = MockitoAnnotations.openMocks(this); } @AfterEach void release() throws Exception { mocks.close(); } ``` The returned `AutoCloseable` represents "the set of mocks this call created, plus the internal bookkeeping for them". Closing it tells Mockito that this batch is finished so the framework can drop its references and clear the associated state. That matters because of *how* Mockito holds mocks. ## The inline mock maker and the global registry Mockito has two mock makers. The classic **subclass** maker generates a subclass per mocked type; the mock object itself is an ordinary object, and once your test drops the reference the garbage collector reclaims it. The **inline** maker — the default since Mockito 5, and opt-in earlier via `mockito-inline` — instruments the original class's bytecode instead, so a method body must ask "is this receiver a registered mock?". Answering that requires a process-wide registry mapping mock instances to their handlers. Mockito uses weak references there, so mocks are not leaked forever in principle, but the practical picture in a long-lived test JVM is messier: strong references from a test class's fields, from captured argument lists, from stubbed answers holding whole object graphs, and from static state all conspire to keep entries alive. Closing the session explicitly clears Mockito's own hold immediately rather than hoping the collector gets around to it. The visible symptoms in a big suite that never closes: - heap usage that grows monotonically across test classes rather than sawtoothing; - an eventual `OutOfMemoryError: Java heap space` late in the run, often in an innocent test that merely happened to be last; - slow full GCs as the registry grows; - with heavy class mocking, metaspace growth from instrumented types. These are exactly the failures that look like flakiness and get "fixed" by raising the heap or forking more often, when the real cause is unclosed sessions. ## Beyond memory: session hygiene Closing also finishes the mocking session in the Mockito sense. Any state associated with the initialization is torn down cleanly, so one test's leftover partial interaction (an unfinished `when(...)`, for instance) is less likely to surface as a confusing failure inside the *next* test. Mockito's own recommendation is unambiguous: use `openMocks` and close it, or use the JUnit 5 extension, which opens and finishes a `MockitoSession` around each test automatically and therefore has nothing for you to forget. ## initMocks vs openMocks `MockitoAnnotations.initMocks(this)` is the historical API. It performs the same field initialization but returns `void`, so there is no way to release anything. Mockito 3.4.0 deprecated it and introduced `openMocks`, whose sole difference is the returned `AutoCloseable`. Seeing `initMocks` in a codebase is a reliable marker of test code that predates that release; the migration is mechanical — capture the return value and add an `@AfterEach` that closes it. ## Practical guidance - **Where to close:** `@AfterEach` for per-test initialization. Do not swallow the exception from `close()`; declare `throws Exception` on the teardown method. - **Try-with-resources** works if you initialize inside a single test method, but the field + `@AfterEach` pattern is what a class-wide setup needs. - **One place only:** put the init/close pair in a shared abstract base class rather than repeating it, so nobody forgets the close half. - **Prefer the extension** on JUnit 5 — it removes the failure mode entirely. - **Verify a suspicion cheaply:** run the suite in one fork with a modest heap and watch whether usage climbs across classes; if it does and adding `close()` flattens it, you have your answer. - **Not a substitute for `validateMockitoUsage()`**, which checks *usage correctness* after a test; closing is about *resource release*. The extension does both. ## Interview framing A good answer names the concrete mechanism — inline mock maker, process-wide registry, mocks and their captured graphs staying reachable — rather than a vague "it cleans up". Then connect it to the observable symptom (heap growth over a long single-fork suite, late OOM), state the `initMocks` deprecation, and finish with the pragmatic recommendation: on JUnit 5, let the extension own the session so this cannot be forgotten.