在我的例子中，我忘记在pom中添加依赖项:

      <dependency>
          <groupId>org.aspectj</groupId>
          <artifactId>aspectjweaver</artifactId>
          <version>1.8.5</version>
      </dependency>

只要确保你选择了正确的版本(目前1.8.9是最新的)

在调试模式下运行了几十次Maven之后，我遇到了这样的情况:

-Dmaven.surefire.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"

由于某些原因，我不得不杀死仍在并行运行的额外java进程。

我的设想是

我的测试有很多日志输出(我的意思是很多!) 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处理症状，而不是原因。

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

我在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)。

发生在我身上的事情:如果你的项目依赖于docker机器或/和数据库来成功构建，那么请首先检查你的db实例是否启动，你的docker也启动，因为可能有一些单元测试在后台运行…特别是在启动笔记本电脑后。希望这能帮助到一些人