高频使用 @mockbean 不会导致真正的 jvm 内存泄漏，但会因 spring testcontext 缓存机制与 mock 注册方式叠加，引发上下文膨胀、gc 压力上升等“伪泄漏”；应优先用 @mock/@injectmocks、缩小作用域、显式隔离上下文、禁用冗余自动配置来防控。
高频使用 @MockBean 本身不会直接导致 JVM 内存泄漏，但会显著加剧测试上下文（ApplicationContext）的膨胀与复用风险，进而引发“伪泄漏”现象——表现为测试执行变慢、堆内存持续增长、GC 压力上升，甚至 OutOfMemoryError: Metaspace。根源在于 Spring TestContext 的缓存机制与 @MockBean 的注册方式共同作用，而非传统意义上的对象未释放。
为什么上下文会“越来越大”
Spring 默认对相同配置的测试类复用同一个 ApplicationContext。而每次使用 @MockBean，Spring 都会在该上下文中：
- 注册一个新的 Mockito Mock 实例（非轻量对象，含拦截器链、调用记录、stubbing 规则等）
- 覆盖原有 Bean 定义，但旧定义的元数据和代理对象可能未被完全清理
- 若多个测试类共用上下文（如相同
@SpringBootTest配置），Mock 实例会不断累积
真正有效的缓解策略
不依赖“重置”，而是从上下文生命周期和 Mock 使用粒度入手控制规模：
-
优先改用
@Mock+@InjectMocks：对纯逻辑单元测试（不涉及 Web 层、事务、自动配置），避免启动 Spring 容器。Mockito 创建的 mock 更轻量，无上下文绑定开销 -
缩小
@MockBean作用域：只在真正需要 Spring 管理上下文的测试中使用，并尽量限定在单个测试类内；避免跨多个@SpringBootTest类共享同一上下文配置 -
显式隔离上下文：在易污染的测试类上添加
@DirtiesContext(classMode = ClassMode.BEFORE_CLASS)，确保该类独占上下文，避免与其他类交叉污染 -
禁用不必要的自动配置：用
@SpringBootTest(classes = {...})或@Import显式声明所需组件，而非加载全量@SpringBootApplication，大幅减少上下文初始化 Bean 数量
慎用但必要的兜底手段
当必须高频使用 @MockBean 且无法规避上下文复用时：
-
在
@AfterEach中调用Mockito.reset()：清除调用历史与 stubbing，释放部分内部状态（注意：不销毁 Mock 实例本身，但可减小其内存足迹） -
避免在
@Configuration或@TestConfiguration中声明@MockBean：这类声明会被所有引用该配置的测试共享，极易造成隐式全局污染 -
监控上下文大小：启用
logging.level.org.springframework.test.context.cache=DEBUG，观察日志中context cache size变化，定位异常膨胀点
本质上这不是内存泄漏，而是上下文缓存设计与测试写法不匹配的结果。控制好作用域、按需加载、减少共享，比事后“清理”更高效可靠。
