我今天也遇到了同样的问题，对我来说，真正的问题是在日志中进一步报告的消息不能使用threadCount参数小于1;1 > 0。 当在surefire-plugin配置中添加<threadCount>1</threadCount>时，其他错误消失。

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.18.1</version>
            <dependencies>
                <dependency>
                    <groupId>org.apache.maven.surefire</groupId>
                    <artifactId>surefire-junit47</artifactId>
                    <version>2.18.1</version>
                </dependency>
                <dependency>
                    <groupId>org.apache.maven.surefire</groupId>
                    <artifactId>surefire-testng</artifactId>
                    <version>2.18.1</version>
                </dependency>
            </dependencies>
            <configuration>
                <threadCount>1</threadCount>
            </configuration>
        </plugin>

.．.是的，为了向后兼容，我在这个测试框架中同时使用了junit和testng。

我也遇到了同样的问题，我使用了Oracle的Java 8而不是Openjdk的Java 10来解决这个问题

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

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

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

jdk - 6675699

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

我在Ubuntu机器上的Jenkins构建过程中遇到了这个问题。

/var/log/syslog报告内存不足:Kill process 19557 (java) score 207或牺牲子进程。

因此，我给了Ubuntu机器更多的交换空间。从那以后，这个问题就不存在了。

在我的案例中，这个问题与IntelliJ IDEA控制台(OS windows 10)的日志输出时间过长有关。 命令:

mvn clean install

这个命令解决了我的问题:

mvn clean install > log-file.log

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

% ulimit -n
256

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

% ulimit -n 3072
% ulimit -n     
3072

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

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

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