为何mongodExecutable.stop()无法停止已启动的Embedded MongoDB进程

• 静态变量引用覆盖问题：代码中将mongodExecutable定义为static静态变量，若测试框架每执行一个测试方法就实例化一次测试类，@Before注解的方法会重复执行，每次执行都会重新给mongodExecutable赋值，之前启动的MongoDB进程对应的可执行实例引用会被覆盖，此时调用的stop()方法作用于新的实例，完全无法触达已经启动的MongoDB进程。
• 端口冲突导致的进程脱离：代码硬编码指定了固定端口27017，如果此前的测试运行异常退出，遗留了未被清理的MongoDB进程占用该端口，本次调用start()时实际没有启动新的MongoDB进程，而是识别到端口被占用直接复用了已存在的旧进程，这个旧进程没有被当前Java进程持有进程句柄，自然无法通过stop()方法终止。
• 进程运行状态判断失效：清理逻辑中依赖mongod.isProcessRunning()做分支判断，这个方法的判断依据是Java侧持有的进程句柄有效性，而非操作系统层面的实际进程存活状态。如果MongoDB进程已经脱离Java侧的句柄绑定，该方法会返回异常结果，导致清理逻辑根本没有走到执行stop()的分支。
• 信号发送权限不足：stop()方法的实现逻辑是向操作系统层面的MongoDB进程发送终止信号，如果当前Java进程没有对应进程的操作权限（类Unix系统下的权限不足、Windows下的权限隔离），终止信号无法送达MongoDB进程，就会出现方法执行完但进程依然存活的情况。
• JVM退出导致清理逻辑未执行：如果测试过程中出现未捕获的异常，JVM提前终止执行流程，@After注解的清理方法根本没有被触发，MongoDB进程自然会残留。

可参考的修复调整 #

• 移除mongodExecutable、mongod变量的static修饰，让变量生命周期和测试类实例完全绑定，避免引用被覆盖丢失。
• 取消硬编码的固定端口配置，改为让Embedded MongoDB自动分配空闲可用端口，从根源避免残留进程占用端口导致的启动异常。
• 清理逻辑移除isProcessRunning()的分支判断，直接调用mongodExecutable.stop()，并对stop过程的异常做捕获处理，避免因为判断偏差漏掉进程终止的步骤。
• 在测试启动前增加端口占用检查，若发现指定端口存在异常进程，先主动终止对应进程再执行MongoDB启动逻辑。

内容的提问来源于stack exchange，提问作者suman biswas