这将工作肯定.....

在POM文件中添加以下行并给出一个构建。

<plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-surefire-plugin</artifactId>
          <version>2.19.1</version>
          <configuration>
            <trimStackTrace>false</trimStackTrace>
            <includes>
              <include>**/*Test.class</include>
            </includes>
          </configuration>
        </plugin>

在Windows (OpenJDK11, Maven 3.6.0, SUREFIRE 3.0.0-M1)上，我得到了根本原因:

# Created at 2018-11-14T14:28:15.629
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000006c7500000, 522190848, 0) failed; error='The paging file is too small for this operation to complete' (DOS error/errno=1455)

并通过增加分页文件大小来解决，例如这样。

我最近在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

在使用maven测试运行单元测试时，我也遇到了同样的问题。 我试过改变那些肯定会成功的版本，但不管用。 最终成功解决如下问题: 早些时候:(当问题发生时): Javac来自JDK 1.8 Java指向JDK 1.11中的Java bin 当前:(当问题得到解决时): javac和Java都指向JDK 1.8中的bin

问候 泰娅。

如果有人包含自定义argLine参数，则必须重新考虑，因为它很可能是内存分配问题的根源。

例如(我曾经有过):

<argLine>XX:MaxPermSize=4096m ${argLine}</argLine>

现在我使用硬指定值:

<argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>

无论出于何种原因，与Surefire集成的应用程序(如Jacoco)不会请求足够的内存来与构建时发生的测试共存。

我的设想是

我的测试有很多日志输出(我的意思是很多!) Surefire插件v2.22.2 错误只发生在IDE内部，如果从命令行执行mvn命令则不会发生。 没有迹象显示Surefire插件中的任何.dump文件或Java二进制中的传统hs_err崩溃文件。

对我来说，有两件事一直是解决方案(它们是替代方案):

不使用fork:设置Surefire插件属性forkcount = 0。 增加Surefire插件属性 forkedProcessExitTimeoutInSeconds从30秒变成300秒。插件文档说，如果这个超时被击中，你会看到错误消息有一个超时在fork。我没有看到这样的错误消息，但是它一直在修复这个问题以增加这个超时值。

您可能希望使用解决方案(2)，因为分叉是可取的。

Why?

我的理论是，如果有大量的日志输出，那么在fork关闭时仍然需要进行大量的处理(特别是如果您在一个IDE中运行，该IDE捕获输出并可能为其窗口内容使用内存映射文件)。简而言之:在测试完成时，仍有大量文本等待转发到IDE中。30岁似乎还不够。

这也解释了为什么有些开发者能够发现问题，而有些开发者却不能。在测试结束时，剩下多少输出处理可能是cpu功率、磁盘速度等的函数。

如果我在这一点上是正确的-不能证明它-那么所有的建议，如重定向日志输出和降低日志级别都是IMO处理症状，而不是原因。