JVM源码分析之自定义类加载器如何拉长YGC

HeapDump性能社区

已于 2022-04-15 11:06:24 修改

阅读量878

点赞数

文章标签： java jvm gc

于 2020-02-13 16:25:18 首次发布

本文链接：https://blog.csdn.net/PerfMa6/article/details/104297880

版权

本文通过分析一个特定的GC问题，探讨了自定义类加载器如何影响垃圾收集，特别是年轻代GC（YGC）的性能。问题源于一个使用XStream的Demo，随着类加载器的使用，YGC时间逐渐增加。分析指出，类加载器和SystemDictionary在GC过程中的作用，以及如何通过调整VM参数或修改代码来验证这一现象。

摘要由CSDN通过智能技术生成

概述

本文重点讲述毕玄大师在其公众号上发的一个GC问题一个jstack/jmap等不能用的case，对于毕大师那篇文章，题目上没有提到GC的那个问题，不过进入到文章里可以看到，既然文章提到了jstack/jmap的问题，这里也简单回答下jstack/jmap无法使用的问题，其实最常见的场景是使用jstack/jmap的用户和目标进程不是同一个用户，哪怕你执行jstack/jmap的动作是root用户也无济于事，不过毕大师这里主要提到的是jmap -heap/histo这两个参数带来的问题，如果使用-heap/histo的参数，其实和大家使用-F参数是一样的，底层都是通过serviceability agent来实现的，并不是jvm attach的方式，通过sa连上去之后会挂起进程，在serviceability agent里存在bug可能导致detach的动作不会被执行，从而会让进程一直挂着，可以通过top命令验证进程是否处于T状态，如果是说明进程被挂起了，如果进程被挂起了，可以通过kill -CONT [pid]来恢复。

再回到那个GC的问题，用的参数如下：