Atitit.提升稳定性-----分析内存泄漏PermGen OOM跟解决之道...java

1. 内存区域的划分 1

2. PermGen内存溢出深入分析 1

3. PermGen OOM原因总结 2

4. 常见的类加载器和类型卸载的可能性总结 2

5. PermGen内存溢出的应对措施 3

6. 第二种就是使用oracle的BEA JDK，因为这个里面的JVM没有PermGen space
3

7. 参考 3

1. 内存区域的划分

java的内存泄漏基本上按照内存区域的划分可以分为：

1 堆（heap）内存泄漏：大家都比较熟悉

2 栈（stack）内存泄漏：当前线程运行期间维护的中间变量等信息过多，例如常见的死循环引起stack over flow

3 方法区（permanent heap）内存泄漏：分析其原因的文章较少，本文的着重点。

作者:: 老哇的爪子 Attilax 艾龙，  EMAIL:[email protected]

转载请注明来源： http://blog.csdn.net/attilax

2. PermGen内存溢出深入分析

在本部分，首先交代一下必要的前提知识，这也为理解后面的测试程序做铺垫。

前提知识

4 由不同的类加载器实例加载的类型可以等价为完全不同的类型，哪怕时同一类型类加载器的不同实例加载的，都会在PermGen区域分配相应的空间来存储类型信息

5 新类型加载时，会在PermGen区域申请相应的空间来存储类型信息，类型被卸载后，PermGen区域上的垃圾收集会释放对应的内存空 间。PermGen区域和普通的堆空间一样，也遵循垃圾收集的规律，所以，网上很多资料种关于PermGen区域空间的大小是只增不减的说法是不正确的， 后面会用相应的测试代码来验证和分析。

6 一种类型被卸载的前提条件是：加载此类型的类加载器实例变为不可达（unreachable）状态，

7 结合上面的[虚拟机运行时数据区的介绍|]，可以得出结论：类型对应的普通实例、类型对应的java.lang.Class实例、加载此类型的ClassLoader实例，三者中有任何一种或者多种是reachable状态的，那么此类型就不可能被卸载。

8 JMX协议提供了相应的API接口，用来在运行时查询当前虚拟机实例的内存使用和类型加载等信息。这也是很多Java性能监控和分析工具的基础，后面的测试程序中也有相应的代码使用了JMX协议。

9

3. PermGen OOM原因总结

通过上面的测试程序分析，我们发现PermGen OOM发生的原因和类型装载、类型卸载有直接的关系，可以对PermGen OOM发生的原因做如下大致的总结：

10 为PermGen区域分配的堆空间过小，可以通过合理的设置-XX: PermSize参数和-XX:MaxPermSize参数来解决。

11 类型卸载不及时，过时无效的类型信息占用了空间，我们不妨称其为"永久堆"的内存泄漏，需要通过深入分析类型卸载的原理来寻找对应的防范措施

4. 常见的类加载器和类型卸载的可能性总结

通过前面的讨论，我们知道如果加载某种类型的类加载器实例没有处于unreachable状态，则该类型就不会被卸载，该类型不被卸载， 则对应的类型信息在PermGen区域中占有的堆内存就不会被释放。下面，针对典型的Java应用分类，分析一下常用类加载器加载的类型被下载的可能性。

系统类加载器：负责加载程序类路径上面的类型，由其加载的类型在整个程序运行期间基本上不可能被卸载，对应类型信息占用的PermGen区域堆空间基本不可能得到释放。

用户自定义类加载器：对于其加载的类型，满足类型卸载要求的可能性比较容易控制，只要是其实例本身处于unreachable状态，其加载的类型会被卸载，PermGen区域中对应的空间占有也会被释放。

5. PermGen内存溢出的应对措施

通过上面的PermGen OOM的原因的分析，不难看出对应的应对措施：

12 合理的设置-XX: PermSize和-XX:MaxPermSize参数（主要的有效措施）

13 有效的利用的虚拟机类型卸载的机制（针对程序进行调优）

6. 第二种就是使用oracle的BEA JDK，因为这个里面的JVM没有PermGen space

这样的区域，所以也就不存在这样溢出的问题。但是因为jrockit比较消耗

资源，所以我只推荐在生产环境中使用，开发环境还是sun的比较省。

从这个角度来说sun jvm这个不能动态增加PermGen space大小

7. 参考

Java内存溢出之PermGen OOM深入分析 - zhu xing - 博客园.htm

Java 8 新特性探究（九）跟 OOM：Permgen 说再见吧 - 推酷.htm