为什么应用程序会创建 31 个“GC 任务线程”?在一个 Solaris 盒子中,而在另一个盒子中只有 2 个

发布于 2024-12-14 03:14:25 字数 480 浏览 2 评论 0原文

我在一个应用程序 (java) 中看到 Solaris 机器中的内存使用情况不规则。当我进行线程转储时,我看到有 31 个“GC 任务线程”...

这很奇怪,因为在其他 Solaris 机器中,同一应用程序只有 2 个“GC 任务线程”。

想知道有谁知道,在什么情况下,jvm会创建这么多GC任务线程,这会导致内存问题吗?

任何想法表示赞赏。

关于我的案例的更多背景: 每次我都会在同一个盒子里同时运行两个类似的 Java 应用程序。我将继续向应用程序 A 发送请求,而不向应用程序 B 发送请求。因此,应用程序 B 应该处于非活动状态。并且在使用prstat时它始终处于“睡眠”状态。

奇怪的是,在一个 Solaris 机器中,应用程序 B 在应用程序 A 处理请求时不断消耗内存。在应用程序 B 的线程转储中,我可以看到 31 个 GC 任务线程。 而在另一个Solaris机器中,应用程序B是正常的,内存是正常的,只有2个GC任务线程。

多谢。

I saw in one application (java) which has irregular memory usage in a Solaris box. When I took a thread dump, I saw there were 31 "GC task thread"...

This is very strange as in other Solaris box, same application only had 2 "GC task thread".

Wondered if anybody know, under which circumstance, the jvm will create so many GC task threads and could this cause memory issue?

Any ideas is appreciated.

Some more background on my case:
Each time I will have two similar Java applications running at the same time in same box. I will keep sending requests to application A , and no request to application B. So, app B should be in-active. And it is alway "sleep" when using prstat.

Strange thing is, in one Solaris box, app B keeps consuming memory while app A is processing request. And in app B's thread dump, I can see 31 GC task threads.
And in another Solaris box, app B is normal, the memory is normal and only 2 GC task threads.

Thanks a lot.

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

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

发布评论

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

评论(1

萌面超妹 2024-12-21 03:14:25

GC 任务线程与并行垃圾收集器行为相关。
并行GC线程数的值由

-XX:ParallelGCThreads=n 

命令行参数定义。在Java热点VM的文档中,它说:

-XX:ParallelGCThreads=n

设置垃圾并行阶段使用的线程数
收藏家。默认值根据平台不同而不同
JVM 正在运行。

(参见:http://www.oracle.com /technetwork/java/javase/tech/vmoptions-jsp-140102.html

文档没有明确说明,但默认值随平台拥有的处理器/核心数量而变化,并且我认为这个数字等于CPU核心的数量。

到目前为止,这就是“为什么 JVM 创建那么多 GC 任务线程。

这会导致内存问题吗?答案是否定的。事实上,每个 GC 线程的内存占用量都非常低,因此它们不会产生任何内存问题。”预计会导致任何相当大的内存问题但是,您可能希望使用上述参数来微调垃圾收集线程的数量。

The GC task thread is related with the parallel garbage collector behaviour.
The value of number of parallel GC threads are defined by the

-XX:ParallelGCThreads=n 

command line parameter. In the documentation of Java hotspot VM, it says:

-XX:ParallelGCThreads=n

Sets the number of threads used during parallel phases of the garbage
collectors. The default value varies with the platform on which the
JVM is running.

(see: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html)

The documentation does not explicitly state, but the default value varies with the number of processors/cores the platform has, and I think the number is equal to the number of CPU cores.

So far, this was the answer of "why JVM creates that many GC task threads.

Does this cause any memory issues? The answer is no. In fact, each of the GC threads will have very low memory footprints, and thus they are not expected to cause any considerable memory issues. However, you may want to finetune the number of garbage collection threads by using the parameter described above.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文