垃圾回收 （GC） 在 Java 的内存照应中起着勤快作用。它有助于回收不再使用的内存。垃圾回收器使用我方的线程集走动收内存。这些线程称为 GC 线程。未必，JVM 最终可能会有太多或太少的 GC 线程。在这篇著述中，咱们将商量为什么 JVM 最终会领有太多/太少的 GC 线程，它的后果正规买球的app，以及贬责这些问题的潜在贬责决议。
若何查找应用设施的 GC 线程计数
你不错通过实行线程转储分析来细目应用设施的 GC 线程计数，如下所述：
从分娩事业器拿获线程转储。
使用线程转储分析器具分析转储。
fastThread 器具GC 线程计数，如下图所示。
若何建树 GC 线程数
你不错通过建树以下两个 JVM 参数来手动调遣 GC 线程数：
-XX:ParallelGCThreads=n：建树垃圾回收器的并行阶段中使用的线程数
-XX:ConcGCThreads=n：法规垃圾回收器的并发阶段使用的线程数
默许的 GC 线程计数是若干？
如若你莫得使用上述两个 JVM 参数显式建树 GC 线程计数，则默许 GC 线程计数将凭证事业器/容器中的 CPU 数目得出。
–XX:ParallelGCThreads Default：在 Linux/x86 机器上，凭证以下公式不错得出：
if (num of processors <=8) { return num of processors; } else { return 8+(num of processors-8)*(5/8); }
因此，如若你的 JVM 在具有 32 个处理器的事业器上启动，那么该值将为：23（即 8 + （32 – 8）*（5/8））。ParallelGCThread
-XX:ConcGCThreads Default：凭证以下公式推敲：
max((ParallelGCThreads+2)/4, 1)
因此，如若你的 JVM 在具有 32 个处理器的事业器上启动，则：
ParallelGCThread值将为：23（即 8 + （32 – 8）*（5/8））。
ConcGCThreads值将为：6 （i.e. max（25/4， 1）。
JVM 最终会有太多的 GC 线程吗？
你的 JVM 可能会不测中领有太多的 GC 线程，而你鄙俗不会坚定到。这鄙俗是因为默许的 GC 线程数是凭证事业器或容器中的 CPU 数目自动细想法。
举例，在具有 128 个 CPU 的机器上，JVM 可能会为垃圾回收的并行阶段分派能够 80 个线程，为并发阶段分派能够 20 个线程，从而系数分派能够 100 个 GC 线程。
如若你在这台 128 CPU 的推敲机上启动多个 JVM，则每个 JVM 最终可能会有能够 100 个 GC 线程。这可能会导致资源使用过多，因为系数这些线程齐在争夺相通的 CPU 资源。这个问题在容器化环境中尤为显著，因为多个应用设施分享相通的 CPU 内核。这将导致 JVM 分派的 GC 线程数独特必要数目，这可能会镌汰举座性能。
为什么 GC 线程过多是一个问题？
天然 GC 线程关于高效的内存照应至关勤快，但领有过多的 GC 线程可能会导致 Java 应用设施濒临要紧的性能挑战。
增强的高下文切换： 当 GC 线程数过多时，操作系统必须在这些线程之间时时切换。这会导致高下文切换支拨增多，其中更多的 CPU 周期用于照应线程，而不是实行应用设施的代码。因此，你的应用设施可能会显着放慢速率。
CPU 支拨： 每个 GC 线程齐会滥用 CPU 资源。如若同期处于手脚情状的线程太多，它们可能会争夺 CPU 期间，从而减少可用于应用设施主要任务的处理智力。这种竞争会镌汰应用设施的性能，尤其是在 CPU 资源有限的环境中。
内存争用： 如若 GC 线程数目过多，则内存资源争用可能会增多。多个线程尝试同期走访和修改内存可能会导致锁争用，这会进一步镌汰应用设施的速率，并可能导致性能瓶颈。
GC 暂停期间增多，通量镌汰： 当过多的 GC 线程处于手脚情状时，垃圾回收流程的收尾可能会镌汰，从而导致应用设施暂时罢手的 GC 暂停期间更长。这些永劫间的暂停可能会导致应用设施出现显著的延伸或卡顿。此外，随吐花在垃圾回收而不是处理央求上的期间越来越多，应用设施的举座朦拢量可能会镌汰，每秒处理的事务或央求更少，并影响其在负载下推广和实行的智力。
更高的延伸： 由于线程数过多而导致 GC 手脚增多，这可能会导致反馈用户央求或处理任务的延伸增多。这关于需要低延伸的应用设施（举例及时系统或高频往来平台）来说尤其成问题，在这些应用设施中，即使是幽微的延伸也可能产生要紧后果。
递减： 独特某个点后，添加更多 GC 线程不会素质性能。相悖，它会导致收益递减，其中照应这些线程的支拨独特了更快垃圾回收的平允。这可能会导致应用设施性能下跌，而不是预期的优化。
为什么 GC 线程太少是一个问题？
天然 GC 线程过多会产素性能问题，但 GC 线程太少对 Java 应用设施来说一样会出现问题。原因如下：
更长的垃圾回收期间： 如若 GC 线程较少，垃圾回收流程可能需要更长的期间才能完成。由于可用于处理责任负载的线程较少，因此回收内存所需的期间会增多，从而导致 GC 暂停期间延长。
应用设施延伸增多： 较长的垃圾回收期间会导致延伸增多，尤其是关于需要低延伸操作的应用设施。用户可能会碰到延伸，因为应用设施在恭候垃圾回收完成时变得无反馈。
镌汰朦拢量： 较少的 GC 线程数意味着垃圾回收器无法高效责任，从而导致举座朦拢量镌汰。你的应用设施每秒处理的央求或事务可能会减少，从而影响其在负载下推广的智力。
CPU 欺诈率低下： 如若 GC 线程太少，CPU 中枢在垃圾回收期间可能无法得到充分欺诈。这可能会导致可用资源的使用收尾低下，因为某些内核保捏幽闲情状，而其他内核则包袱过重。
OutOfMemoryErrors:和内存知道的风险增多：如若垃圾回收器由于线程太少而无法跟上内存分派的速率，则它可能无法填塞快地回收内存。这会增多应用设施内存不及的风险，从而导致潜在的崩溃。此外，GC 线程不及会放慢垃圾回收流程，从而允许更多未使用的对象在内存中积蓄，从而加重内存知道。跟着期间的推移，这可能会导致内存使用过多并进一步镌汰应用设施性能。OutOfMemoryErrors
优化 GC 线程数的贬责决议
如若你的应用设施由于 GC 线程数目过多或不及而出现性能问题，请洽商使用上述 JVM 参数手动建树 GC 线程计数：
-XX:ParallelGCThreads=n
-XX:ConcGCThreads=n
在分娩环境中进行这些革新之前，必须揣度应用设施的 GC 手脚。领先使用器具相聚和分析 GC 日记。此分析将匡助你细目现时方程计数是否导致性能瓶颈。凭证这些宗旨，你不错对 GC 线程数进行理智的调遣，而不会引入新问题
阻碍：永远先在受控环境中测试革新，以证明它们素质了性能，然后再将其部署到分娩环境中。
论断
均衡 GC 线程的数目是确保 Java 应用设施牢固启动的时弊。通过仔细监控和调遣这些建树正规买球的app，你不错幸免潜在的性能问题并保捏应用设施高效启动。