【发布时间】：2020-06-04 19:27:09
【问题描述】：
在处理 Java 8 应用程序的性能后，JMS 使用者线程的数量增加了，这增加了并行处理，其中更大的一部分是对 DB 的并行请求。应用程序开始使用更多内存。它被赋予了更多的内存，但副作用开始出现。在高负载（生产力提高很多）下输入 2-3 批消息后，垃圾收集开始大量使用 CPU。由于应用程序的性质、文本消息处理、新（巨大）文本变量的密集创建以及流程结束时的垃圾收集，这在以前并不小。但它清楚地看到它在某个时间点变得巨大并且应用程序无法摆脱这种状态。
在上图中，它发生在 18:58。注意内存图，没有有序的“内存选择”使用情况，它一直在进行垃圾收集，因此是 CPU 图。我之前在应用程序内存不足时看到过这种情况，并且在 OOE 之前的片刻，您通常可以看到完全相同的图片。它被赋予了另一个 GB 的内存，但图片没有改变，请注意最大使用量约为 5000 MB，但在此 JVM 释放了一半 GB 之后，这意味着它不需要它。但它的行为就像缺少内存一样。
值得一提的是，在同一台机器上启动的多个 JVM 相互协作。另一个“大”正在做初步处理并且工作正常，具有相似的架构但内存消耗更少。
您可以注意到此应用的所有三个批次的“内存选择”，同时运行。
我搜索了一下，发现它可能是 Meta Space，这可能会导致额外的 GC 触发和不稳定的应用程序行为，所以我故意将最大 Meta Space 大小增加到应用程序通常采用的更大值，注意 max 并在下面使用
问题：这里发生了什么，持续 GC 活动的原因可能是什么，我该如何解决？
【问题讨论】：
-
您是否创建了很多短命的对象？
-
我会说它通过处理另一个变量来创建很多文本变量。其中一些可能与输入 xml 一样大。这是具有自己的 DSL 语言的文本处理应用程序。如果是很多短命的对象，为什么不使用所有可用内存，而是使用常量 GC？
-
我读过你的第一句话：在努力提高 java 8 应用程序的性能之后，JMS 消费者线程的数量增加了，这增加了并行处理，其中更大的部分是并行请求DB 我不太明白。你可能不是以英语为母语的人（我也是），但你能用更简单的语言解释发生了什么吗？您的问题充其量是模糊的，就像现在写的那样
-
简单来说，GC 活动从 15% 增加到 45%，我想解决这个问题。如果有不清楚的地方，请提出其他问题
-
1）你需要用
@标记我，否则我不知道你回复了2）你的意思是增加CPU？
标签： java performance garbage-collection jvm