在将Maven从2.6.3更新到2.8.4之后，我遇到了同样的问题。问题是分叉JVM崩溃的内存不足，所以只是增加内存从1024Mb到2048Mb在Surefire插件配置，这解决了这个问题

        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <!--suppress UnresolvedMavenProperty -->
                <argLine>${argLine} -Dfile.encoding=UTF-8 -Xmx2048m</argLine>
            </configuration>
        </plugin>

我遇到过一个案例，其中没有一个答案能解决问题。它是一个遗留应用程序，恰好使用log4j和SLF4J/logback。

前面的情况:干净的测试构建在Eclipse中启动时运行良好，但是在命令行中启动时，出现了这个错误。基于CircleCI的CI构建也运行良好。

我所做的是:出于纯粹的猜测，配置一个适当的logback-test.xml并降低日志记录的冗长程度。你瞧，我再也没有遇到过这个错误，我现在可以从命令行构建项目(以及发生这个错误的模块)。

我的观点是，日志框架的使用或配置方式可能是另一种解释。

log4j和logback之间真的有冲突吗?或者仅仅是测试产生的大量日志以某种方式溢出了命令行缓冲区?我不知道。这对我来说仍然是个谜。

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

pipeline {
    agent { label projectName }

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

谢谢 南非

我在MacOS上远程调试端口5005上的Selenium测试代码时也遇到了这个问题。这个问题原来是由一个仍然运行的剩余的surefire-fork jvm引起的。Eclipse IDE终端的日志输出没有显示底层问题“Address already in use”。只有当我在MacOS终端上运行Eclipse实际试图运行的相同命令时，才会显示日志消息:

/bin/sh -c cd /path/to/your/project/directory && /Library/Java/JavaVirtualMachines/adoptopenjdk-8.使用实例jdk/Contents/Home/jre/bin/java -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005 -jar /path/to/target/surefire/surefirebooter230340673926465933.jar /path/to/target/surefire 2019-06-28T10-50-02_140-jvmRun1 surefire6455775580414993159tmp surefire_02461993428448591420tmp

杀死流氓JVM实例(在Activity Monitor中查找java进程名)解决了这个问题。顺便说一下，我正在运行surefire插件版本2.21.0，与开放jdk 8 (v1.8.0_212)没有问题。注意，所有路径都将特定于您的构建环境，可能还有端口(address=5005)。

也面临着同样的问题，ubuntu上的java 8

然后发现https://stackoverflow.com/a/53016532/1676516

这似乎是最近在java 8的surefire插件2.22.1版本https://issues.apache.org/jira/browse/SUREFIRE-1588中的一个错误

通过本地MVN设置~/.m2/ Settings .xml遵循建议的解决方案

<profiles>
    <profile>
        <id>SUREFIRE-1588</id>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
        </properties>
    </profile>
</profiles>

这也可能是由于一个完全不同的问题。例如，在我的案例中，我们的Jenkins构建在执行测试时毫无理由地间歇性失败。

我筛选了我们的测试，以寻找System.exit()的任何出现，但没有。

经过更多的挖掘，我发现这可能是因为JDK的bug导致了这种回归。

jdk - 6675699

我仍在努力在我们的构建中修复这个问题，将回来并再次更新线程。