运行包中的所有测试时出现 JUnit java.lang.OutOfMemoryError

发布于 2024-08-12 03:29:53 字数 306 浏览 4 评论 0原文

当加载包中的所有单元测试时,make 任务会抛出 java.lang.OutOfMemoryError: Java 堆空间错误。

不过,如果我运行每个子包中的所有测试,所有测试都会加载并完成。只有当我尝试运行父包中的所有测试时,才会出现 OOM 错误。

我认为这个问题不应该通过调整虚拟机参数来解决。我尝试增加最大堆和烫发大小,但没有解决问题。

这让我相信在不同包中的加载测试之间存在一些垃圾收集问题,或者正在进行一些过于急切的类加载。

是否有 JUnit 设置可以解决这些问题,或者是否必须通过更改或添加测试用例中的代码来解决问题?

When loading all unit tests in a package, the make task throws a java.lang.OutOfMemoryError: Java heap space error.

If I run all the tests in each subpackage, though, all tests load and complete just fine. It is only when I try to run all tests in the parent package that the OOM error occurs.

I don't think this problem should be solved by tweaking VM parameters. I tried increasing the maximum heap and perm size, and it didn't solve the problem.

This leads me to believe there is some problem garbage collecting between loading tests in different packages, or that there is some too-eager class loading going on.

Is there a JUnit setting that could take care of these issues, or is the problem going to have to be solved by changing or adding code in the test cases?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

微凉徒眸意 2024-08-19 03:29:53

您必须在 tearDown() 中将测试类的所有字段设置为 null

原因是 JUnit 每个测试都会实例化一个测试类实例。它始终保留该实例以保存测试结果(成功、失败、堆栈跟踪)。因此,如果您使用字段,它们将保留下来,并且您将耗尽内存。

You must set all fields of the test classes to null in tearDown().

The reason is that JUnit instantiates one instance of the test class per test. It keeps that instance around for the whole time to save the results of the test (success, failure, stack trace). So if you use fields, they will stay and you'll run out of memory.

眼前雾蒙蒙 2024-08-19 03:29:53

我在使用 TestNG 时遇到了类似的问题,并将其追溯到我生成到控制台的日志信息量。一旦我减少了这个,我就能够运行我的测试套件而不会出现内存问题。

I experienced a similar problem using TestNG and traced it to the amount of log information I was generating to the console. Once I'd reduced this I was able to run my test suite without memory problems.

何止钟意 2024-08-19 03:29:53

当 CPU 有空闲时间或可用内存较低时,GC 就会运行。如果您的测试崩溃,则可能在某处存在内存泄漏。 (是的,它们也存在于 java 中)

查看循环引用和静态类/变量。这些是 IIRC 内存泄漏的常见原因。您还应该看看 jconsole。

The GC runs when the CPU has spare time or the free memory is low. If your tests crash, you might have a memory leak somewhere. (Yes they exist in java too)

Have a look for circular references and static classes/variables.Theses are IIRC common reasons for memory leaks. You should also have a look at jconsole.

找回味觉 2024-08-19 03:29:53

对我来说,设置 null testclass 并不能解决问题。因为每个测试都占用 Eclipse 虚拟机上的内存,所以最好的事情(为我解决)是杀死每个测试类的 junit 应用程序上下文(通过使用@DirtiesContext)完成!像下面这样

@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest
@DirtiesContext(classMode=ClassMode.AFTER_CLASS)  // this one
public class SomeControllerTest {
  ....
}

For me , setting null testclass is not solving . Coz each test take memory on eclipse vm so the best thing(solve for me) is killing junit application context( by using @DirtiesContext) for each test class are finished ! Like below

@RunWith(SpringJUnit4ClassRunner.class)
@SpringBootTest
@DirtiesContext(classMode=ClassMode.AFTER_CLASS)  // this one
public class SomeControllerTest {
  ....
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文