康师傅没有眼泪

"org.apache.hadoop.fs.FileSystem$Cache"”的一个实例文件系统被"sun.misc.Launcher$AppClassLoader @ 0xc04e9290"加载。问题的源头在于 org.apache.hadoop.fs.FileSystem 这个类，程序运行了5天， conf 类就产生了几千个实例。配置”，由“sun.misc”加载。.hrpof文件，这里是二进制的格式，你不能直接打开看的，其把这一时刻JVM堆内存里所有对象的快照放到文件里去了，供你后续去分析。

何时用hrpof文件分析内存其实如果只是要了解JVM的运行状况，然后去进行JVM GC优化，通常来说jstat就完全够用了。但是有的时候可能我们会发现JVM新增对象的速度很快，然后就想要去看看，到底什么对象占据了那么多的内存。如果发现有的对象在代码中可以优化一下创建的时机，避免那种对象对内存占用过大，那么也许可以去反过来优化一下代码。

GCViewer介绍业界较为流行分析GC日志的两个工具——GCViewer、GCEasy。GCEasy部分功能还是要收费的，今天笔者给大家介绍一下GCViewer的使用与功能点。二、GCViewer 使用。

从结果来看打印的这段时间内YGC没有增加，就说明没有进行young gc ，而FGC，名字增加很快，说明这么几秒中内进行了多次FullGc，如果没有配置gc的回收机制的情况下用的串行回收器，fullgc是会影响所有线程，gc频繁就会占用大量的cpu时间片，从而导致其他服务变慢，超时等。从上面jstack中看，并没有我预期的jstack中的***Class 正在运行 ，就是打印出有问题的代码，由此判断应该是程序 GC问题。可以在上面的页面中输入 H （大写的），可以看到线程信息，我忘了截图。

按照线程数量来分：串行 串行垃圾回收器一次只使用一个线程进行垃圾回收并行 并行垃圾回收器一次将开启多个线程同时进行垃圾回收。按照工作模式来分：并发 并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间独占 一旦运行，就停止应用程序中的其他所有线程，直到垃圾回收过程完全结束按照碎片处理方式：压缩式 压缩式垃圾回收器会在回收完成后，对存活对象进行压缩整消除回收...