这个问题比较常见，我把过程中的日志记录下来了，希望后续大家遇到类似的能快速定位。
1、平均三秒一次FullFC
sudo -u admin java/bin/jstat -gcutil `pgrep java -u admin` 1000 2000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.53 71.69 9.19 92.42 6183 901.265 54986 48865.327 49766.592
0.00 0.53 72.34 9.19 92.42 6183 901.265 54986 48866.617 49767.881
0.00 0.53 72.68 9.19 92.42 6183 901.265 54986 48866.617 49767.881
0.00 0.53 73.08 9.19 92.42 6183 901.265 54987 48866.617 49767.881
0.00 0.53 73.08 9.19 92.42 6183 901.265 54987 48866.617 49767.881
0.00 0.53 73.68 9.19 92.42 6183 901.265 54987 48867.875 49769.140
0.00 0.53 73.87 9.19 92.42 6183 901.265 54988 48867.875 49769.140
0.00 0.53 73.87 9.19 92.42 6183 901.265 54988 48869.260 49770.525
0.00 0.53 74.90 9.19 92.42 6183 901.265 54988 48869.260 49770.525
0.00 0.53 75.32 9.19 92.42 6183 901.265 54988 48869.260 49770.525
0.00 0.53 75.39 9.19 92.42 6183 901.265 54989 48869.260 49770.525
0.00 0.53 76.07 9.19 92.42 6183 901.265 54989 48870.539 49771.804
0.00 0.53 76.34 9.19 92.42 6183 901.265 54990 48870.539 49771.804
0.00 0.53 76.34 9.19 92.42 6183 901.265 54990 48870.539 49771.804
0.00 0.53 77.36 9.19 92.42 6183 901.265 54990 48871.973 49773.238
0.00 0.53 77.65 9.19 92.42 6183 901.265 54990 48871.973 49773.238
0.00 0.53 77.76 9.19 92.42 6183 901.265 54991 48871.973 49773.238
2、重启应用之后发现Perm区一直在上涨
sudo -u admin /java/bin/jstat -gcutil `pgrep java -u admin` 5000 200
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 71.04 14.28 0.00 71.46 5 0.467 0 0.000 0.467
0.00 71.04 16.19 0.00 71.47 5 0.467 0 0.000 0.467
0.00 71.04 18.30 0.00 71.54 5 0.467 0 0.000 0.467
0.00 71.04 20.82 0.00 71.54 5 0.467 0 0.000 0.467
0.00 71.04 22.77 0.00 71.54 5 0.467 0 0.000 0.467
0.00 71.04 24.46 0.00 71.54 5 0.467 0 0.000 0.467
0.00 71.04 26.24 0.00 71.54 5 0.467 0 0.000 0.467
0.00 71.04 29.01 0.00 72.66 5 0.467 0 0.000 0.467
0.00 71.04 30.84 0.00 72.66 5 0.467 0 0.000 0.467
0.00 71.04 32.65 0.00 72.68 5 0.467 0 0.000 0.467
0.00 71.04 34.48 0.00 72.68 5 0.467 0 0.000 0.467
0.00 71.04 36.40 0.00 72.69 5 0.467 0 0.000 0.467
0.00 71.04 38.10 0.00 72.69 5 0.467 0 0.000 0.467
0.00 71.04 39.76 0.00 72.70 5 0.467 0 0.000 0.467
3、Btrace查看后发现HSF的一个类在调用ClassLoader的defineClass方法来创建类：
sudo -u admin sh btrace -cp /home/admin/btrace/build 4955 /home/admin/btrace/BtraceAll.java
===========================================================================
java.lang.ClassLoader.defineClass
Time taken : 2
java thread method trace:---------------------------------------------------
java.lang.ClassLoader.defineClass(ClassLoader.java:615)
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165)
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554)
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524)
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455)
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443)
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423)
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368)
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33)
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:432)
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
java.lang.ClassLoader.loadClass(ClassLoader.java:247)
com.taobao.hsf.rpc.tbremoting.provider.ProviderProcessor.handleRequest(ProviderProcessor.java:117)
com.taobao.hsf.rpc.tbremoting.provider.ProviderProcessor.handleRequest(ProviderProcessor.java:55)
com.taobao.remoting.impl.DefaultMsgListener$1.run(DefaultMsgListener.java:98)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
4、Perm区配置都是128M，有点小，之前占比90%的时候开始FullGC
VM Flags:
-Dprogram.name=run.sh -Xms4g -Xmx4g -XX:PermSize=128m -XX:MaxPermSize=128m -Xmn2500m -XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection
5、应用中war包的lib目录就有177M
在应用刚开始启动的时候，占比70% 左右，也就是90M左右的样子，之后有些类动态加载进来了，到90% 后就回收不了了。
临时解决办法：调大Perm区，增大至256m
后续考虑：优化jar包依赖，目前太多没用的被依赖进来，导致包很大。
相关推荐
在本篇文章中，我们将分享一个 Full GC 问题排查过程，通过示例代码和实际操作，介绍了如何快速定位 Full GC 问题的原因和解决方案。 问题描述 在我们的服务中，突然出现了频繁的 Full GC 问题，而服务本身没有...
"Jvm Old区过高排查过程...在这篇文章中，我们探索了Jvm Old区过高的排查过程，了解了Jvm的内存结构和垃圾回收机制，并使用jstat、jmap和jvisualvm工具来分析Jvm的内存情况，最后发现了Jvm Old区过高的原因和解决方案。
理解JVM的工作原理对于优化代码性能、排查问题至关重要。本文将详细探讨JVM的内存模型以及垃圾收集（Garbage Collection，简称GC）机制。 1. **JVM内存结构** JVM内存主要分为堆（Heap）、栈（Stack）、方法区...
JVM性能优化与问题排查经验总结 本文总结了线上adplatform集群机器CPU飙升问题的排查经验，并对JVM性能优化与问题排查进行了详细的分析和总结。 JVM性能优化 在排查线上adplatform集群机器CPU飙升问题时，我们...
最近项目中出现了这样一个问题，有5台虚机上面运行着同样的微服务，每台机器都挂载着8-9个服务，其中一台不知道为什么就挂掉了，不是服务挂了，是机器挂了，shell连不上的那种。 初步诊断思路考虑是不是这台机器上的...
然而，在实际运行过程中，由于复杂的运行环境和技术栈的多样性，JVM可能会遇到各种各样的问题，如性能瓶颈、内存泄漏、CPU占用过高、网络延迟等。这些问题不仅会影响服务的稳定性和响应速度，还可能导致严重的业务...
同时，掌握JVM的调试工具，如jstack、jmap、jhat等，可以帮助我们在开发过程中进行问题排查。 总的来说，《JVM笔记（阳哥）》是一份全面、实用的参考资料，无论是初级开发者还是经验丰富的工程师，都能从中获益。...
《JVM故障排查指南》是一本深入探讨Java虚拟机（JVM）调优实践的珍贵资源，对于Java开发者和系统管理员来说，它是提升性能优化技能的重要参考资料。这本书涵盖了从基本概念到高级技巧的各种主题，旨在帮助读者理解...
这些只是JVM面试题的一部分，实际面试中可能会涉及更深入的问题，如JVM内存模型的细节、JIT编译器、内存溢出问题的处理等。通过深入学习和实践，开发者可以更好地理解和优化JVM，提升Java应用的性能和稳定性。
2. jmap -histo:live <pid>：此命令用于查看当前存活的实例，执行过程中可能会触发一次Full GC。 当需要对JVM进行内存溢出处理时，可以通过两个参数来实现自动导出堆内存信息。这两个参数为： 1. -XX:+...
包括用户创建对象、JVM 实例化对象、对象分配在堆内存中、minor GC、full GC 等阶段。 9. 排查 JVM 问题 排查 JVM 问题可以使用 jmap 查看 JVM 中各个区域的使用情况，可以使用 jstack 查看 JVM 中的线程信息。
本文将针对一个具体案例——浪潮烟草技术人员处理的广东烟草12月10日内存溢出事件，深入探讨Java虚拟机(JVM)中的Class类加载器内存泄露问题，并提出相应的解决方案。 #### 问题描述 在该事件中，技术人员发现了一...
在企业级应用开发和运维过程中，WebLogic作为一个广泛使用的Java应用服务器，其性能优化和故障排查至关重要。特别是在面对复杂的企业级应用时，合理地进行JVM（Java虚拟机）调优能够显著提升系统的稳定性和响应速度...
深入理解JVM内核对于优化应用性能、排查问题至关重要。本教程将聚焦于JVM的垃圾收集（Garbage Collection, 简称GC）参数，这是JVM性能调优的重要一环。 GC的主要任务是自动回收不再使用的内存空间，避免内存泄漏，...
本套JVM视频教程针对2020年的技术趋势和面试需求进行了全面更新，旨在帮助学员深入理解JVM的工作原理，提升性能调优和问题排查能力。 首先，课程会从基础理论入手，详细阐述JVM的内存模型。这包括了程序计数器、...
新生代的Minor GC、老年代的Major GC以及Full GC是垃圾回收的主要过程。理解这些内存区域的分配和回收策略对优化内存使用至关重要。 3. **垃圾收集器**：JVM提供了多种垃圾收集器，如Serial、Parallel、CMS和G1等。...
JDK提供了一系列的工具，如jps（Java进程查看）、jstat（统计信息）、jmap（内存映射）、jhat（堆分析）、jstack（线程堆栈快照）等，用于监控JVM的状态、分析性能问题和排查错误。 七、JVM内存模型 Java内存模型...
常见的问题包括内存泄漏、垃圾回收效率低下、Full GC频繁等。针对这些问题，我们可以调整JVM的启动参数，如-Xms和-Xmx设置初始堆和最大堆大小，-XX:NewRatio设定新生代与老年代的比例，-XX:SurvivorRatio设定新生代...
在本篇《记一次公司JVM堆溢出抽丝剥茧定位的过程解析》中，作者详细阐述了一次处理公司线上JVM堆溢出问题的排查和解决过程。问题发生在线上Tomcat服务中，该服务合并部署了8个微服务，以节省服务器资源。在上线后...
在这个全面理解JVM并掌握常规JVM调优的教程中，我们将深入探讨JVM的工作原理、内存模型、垃圾收集机制、类加载过程以及如何进行性能优化。 一、JVM工作原理 JVM的运行过程包括编译、加载、验证、解析、初始化、执行...