我也经历过这种情况-但在我的情况下，我为黄瓜编写了一个自定义钩子

public class MappingFormatter implements gherkin.formatter.Formatter {

...

我的方法之一是产生一个空指针异常，这导致surefire退出而不记录错误。

我在使用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>

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

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

也面临着同样的问题，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>

当我遇到这个错误时，这是由于我的ulimit打开文件(ulimit -n)太低。它(不知何故)被设置为仅256:

% ulimit -n
256

在我增加限制后，错误消失了:

% ulimit -n 3072
% ulimit -n     
3072

您的系统可能不允许将限制设置得这么高。例如，当我试图使用更大的数字时，就会发生这种情况:

% ulimit -n 3073
ulimit: setrlimit failed: invalid argument

或者这可能低于您现有的限制，您可能面临不同的根本原因。

最近travis终止了一个测试的执行(没有改变任何相关的东西(以及在开发人员机器上成功的构建!))，因此BUILD FAILURE。 原因之一是这样的(见@agudian的答案):

Surefire不支持调用System.exit()的测试或任何引用库

(因为测试类确实称为System.exit(-1))。

相反，使用简单的return语句会有所帮助。 为了让travis再次开心，我还必须添加@xiaohuo提供的surefire参数(<argLine>)。(此外，我必须删除-XX:MaxPermSize=256m，以便能够在我的一个台式机上构建)

只做这两件事中的一件是行不通的。

要了解更多背景知识，请阅读何时调用系统。退出Java。

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.