我在Jenkins Docker容器中也遇到了这个问题(尝试过Jenkins:lts, Jenkins, Jenkins:slim和Jenkins:slim-lts。我不想遍遍所有的存储库并为每个项目更新pom，所以我只是在maven命令行调用中添加了disableClassPathURLCheck:

mvn test -DargLine="-Djdk.net.URLClassPath.disableClassPathURLCheck=true"

我最近在JHipster 6.10.5使用spring-boot 2.2.7生成的应用程序中遇到了同样的问题。RELEASE和maven surefire插件3.0.0-M4。这是由于非常长的测试日志造成的超时。通过在pom.xml中的maven-surefire-plugin(在pluginManagement下)中添加以下配置参数来解决:

1200年< forkedProcessExitTimeoutInSeconds > < / forkedProcessExitTimeoutInSeconds >

看到https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html forkedProcessExitTimeoutInSeconds

我在使用Java 8和spring boot 5.2.7时也遇到了同样的问题(包括插件，开箱即用)。插件的版本是默认的(2.22.2)。在我的例子中，问题只发生在团队中的一些机器上，而在其他机器上一切正常。我猜这和maven检测到的内核数量有关。

我用这些设置来修复它:

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <reuseForks>false</reuseForks>
            </configuration>
        </plugin>

我尝试了许多建议的方法，但没有一种对我的情况有效。

这个解决方案唯一的缺点是禁用分叉的重用，现在测试运行得更慢了。

版本2.22.2在fork jvm方面存在实际问题。 使用版本2.20 -它的工作就像一个魅力!

<groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>

我的决心是将Jenkinsfile中提到的超时时间从90更改为120。

pipeline {
    agent { label projectName }

options {
    disableConcurrentBuilds()
    buildDiscarder(logRotator(numToKeepStr:'5'))
    timeout(time: 90, unit: 'MINUTES')
}

谢谢 南非

Surefire FAQ的这一部分可以帮助你:

Surefire fails with the message "The forked VM terminated without properly saying goodbye" Surefire does not support tests or any referenced libraries calling System.exit() at any time. If they do so, they are incompatible with surefire and you should probably file an issue with the library/vendor. Alternatively the forked VM could also crash for a number of reasons, which can also make this issue happen. Look for the classical "hs_err*" files indicating VM crashes or examine the log output from running maven when the tests execute. Some "extraordinary" output from crashing processes may be dumped to the console/log. If this happens on a CI environment and only after some time runs there is a fair chance your test suite is leaking some kind of OS-level resource that makes things worse for every run. Regular os-level monitoring tools may give you some indication.