OutOfMemoryError系列(3): Permgen space

简介: 说明: Permgen(永久代) 属于 JDK1.7 及之前版本的概念; 为了适应Java程序的发展, JDK8以后的版本采用限制更少的 MetaSpace 来代替, 详情请参考下一篇文章: OutOfMemoryError系列(4): Metaspace。

说明: Permgen(永久代) 属于 JDK1.7 及之前版本的概念; 为了适应Java程序的发展, JDK8以后的版本采用限制更少的 MetaSpace 来代替, 详情请参考下一篇文章: OutOfMemoryError系列(4): Metaspace

这是本系列的第三篇文章, 相关文章列表:

JVM限制了Java程序的最大内存使用量, 可以通过启动参数来配置。而Java的堆内存被划分为多个区域, 如下图所示:

java.lang.outofmemoryerror: Permgen space

这些区域的最大值, 由JVM启动参数 -Xmx-XX:MaxPermSize 指定. 如果没有明确指定, 则根据操作系统平台和物理内存的大小来确定。

java.lang.OutOfMemoryError: PermGen space 错误信息所表达的意思是: 永久代(Permanent Generation) 内存区域已满

原因分析

我们先看看 PermGen 是用来干什么的。

在JDK1.7及之前的版本, 永久代(permanent generation) 主要用于存储加载/缓存到内存中的 class 定义, 包括 class 的 名称(name), 字段(fields), 方法(methods)和字节码(method bytecode); 以及常量池(constant pool information); 对象数组(object arrays)/类型数组(type arrays)所关联的 class, 还有 JIT 编译器优化后的class信息等。

很容易看出, PermGen 的使用量和JVM加载到内存中的 class 数量/大小有关。可以说 java.lang.OutOfMemoryError: PermGen space 的主要原因, 是加载到内存中的 class 数量太多或体积太大。

示例

最简单的例子

我们知道, PermGen 空间的使用量, 与JVM加载的 class 数量有很大关系。下面的代码演示了这种情况:

import javassist.ClassPool;

public class MicroGenerator {
  public static void main(String[] args) throws Exception {
    for (int i = 0; i < 100_000_000; i++) {
      generate("eu.plumbr.demo.Generated" + i);
    }
  }

  public static Class generate(String name) throws Exception {
    ClassPool pool = ClassPool.getDefault();
    return pool.makeClass(name).toClass();
  }
}

这段代码在 for 循环中, 动态生成了很多class。可以看到, 使用 javassist 工具类生成 class 是非常简单的。

执行这段代码, 会生成很多新的 class 并将其加载到内存中, 随着生成的class越来越多,将会占满Permgen空间, 然后抛出 java.lang.OutOfMemoryError: Permgen space 错误, 当然, 也有可能会抛出其他类型的 OutOfMemoryError。

要快速看到效果, 可以加上适当的JVM启动参数, 如: -Xmx200M -XX:MaxPermSize=16M 等等。

Redeploy 时产生的 OutOfMemoryError

说明: 如果在开发时Tomcat产生警告,可以忽略。 生产环境建议不要 redploy,直接关闭/或Kill相关的JVM,然后从头开始启动即可。

下面的情形更常见,在重新部署web应用时, 很可能会引起 java.lang.OutOfMemoryError: Permgen space 错误. 按道理说, redeploy 时, Tomcat之类的容器会使用新的 classloader 来加载新的 class, 让垃圾收集器 将之前的 classloader (连同加载的class一起)清理掉,。

但实际情况可能并不乐观, 很多第三方库, 以及某些受限的共享资源, 如 thread, JDBC驱动, 以及文件系统句柄(handles), 都会导致不能彻底卸载之前的 classloader. 那么在 redeploy 时, 之前的class仍然驻留在PermGen中, 每次重新部署都会产生几十MB,甚至上百MB的垃圾

假设某个应用在启动时, 通过初始化代码加载JDBC驱动连接数据库. 根据JDBC规范, 驱动会将自身注册到 java.sql.DriverManager, 也就是将自身的一个实例(instance) 添加到 DriverManager 中的一个 static 域。

那么, 当应用从容器中卸载时, java.sql.DriverManager 依然持有 JDBC实例(Tomcat经常会发出警告), 而JDBC驱动实例又持有 java.lang.Classloader 实例, 那么 垃圾收集器 也就没办法回收对应的内存空间。

java.lang.ClassLoader 实例持有着其加载的所有 class, 通常是几十/上百 MB的内存。可以看到, redeploy时会占用另一块差不多大小的 PermGen 空间, 多次 redeploy 之后, 就会造成 java.lang.OutOfMemoryError: PermGen space 错误, 在日志文件中, 你应该会看到相关的错误信息。

解决方案

1. 解决程序启动时产生的 OutOfMemoryError

在程序启动时, 如果 PermGen 耗尽而产生 OutOfMemoryError 错误, 那很容易解决. 增加 PermGen 的大小, 让程序拥有更多的内存来加载 class 即可. 修改 -XX:MaxPermSize 启动参数, 类似下面这样:

java -XX:MaxPermSize=512m com.yourcompany.YourClass

以上配置允许JVM使用的最大 PermGen 空间为 512MB, 如果还不够, 就会抛出 OutOfMemoryError

2. 解决 redeploy 时产生的 OutOfMemoryError

我们可以进行堆转储分析(heap dump analysis) —— 在 redeploy 之后, 执行堆转储, 类似下面这样:

jmap -dump:format=b,file=dump.hprof <process-id>

然后通过堆转储分析器(如强悍的 Eclipse MAT)加载 dump 得到的文件。找出重复的类, 特别是类加载器(classloader)对应的 class. 你可能需要比对所有的 classloader, 来找出当前正在使用的那个。

Eclipse MAT 在各个平台都有独立安装包. 大约50MB左右, 官网下载地址: http://www.eclipse.org/mat/downloads.php

对于不使用的类加载器(inactive classloader), 需要先确定最短路径的 GC root , 看看是哪一个阻止其被 垃圾收集器 所回收. 这样才能找到问题的根源. 如果是第三方库的原因, 那么可以搜索 Google/StackOverflow 来查找解决方案. 如果是自己的代码问题, 则需要在恰当的时机来解除相关引用。

3. 解决运行时产生的 OutOfMemoryError

如果在运行的过程中发生 OutOfMemoryError, 首先需要确认 GC是否能从PermGen中卸载class。 官方的JVM在这方面是相当的保守(在加载class之后,就一直让其驻留在内存中,即使这个类不再被使用). 但是, 现代的应用程序在运行过程中, 会动态创建大量的class, 而这些class的生命周期基本上都很短暂, 旧版本的JVM 不能很好地处理这些问题。那么我们就需要允许JVM卸载class。使用下面的启动参数:

-XX:+CMSClassUnloadingEnabled

默认情况下 CMSClassUnloadingEnabled 的值为false, 所以需要明确指定。 启用以后, GC 将会清理 PermGen, 卸载无用的 class. 当然, 这个选项只有在设置 UseConcMarkSweepGC 时生效。 如果使用了 ParallelGC, 或者 Serial GC 时, 那么需要切换为CMS:

-XX:+UseConcMarkSweepGC

如果确定 class 可以被卸载, 假若还存在 OutOfMemoryError, 那就需要进行堆转储分析了, 类似下面这种命令:

jmap -dump:file=dump.hprof,format=b <process-id> 

然后通过堆转储分析器(如 Eclipse MAT) 加载 heap dump。找出最重的 classloader, 也就是加载 class 数量最多的那个. 通过加载的 class 及对应的实例数量, 比对类加载器, 找出最靠前的部分, 挨个进行分析。

对于每个有嫌疑的类, 都需要手动跟踪到生成这些类的代码中, 以定位问题。

扩展阅读: 跟OOM:Permgen说再见吧

原文链接: https://plumbr.eu/outofmemoryerror/permgen-space

翻译日期: 2017年8月28日

翻译人员: 铁锚: http://blog.csdn.net/renfufei

目录
相关文章
|
监控 安全 网络安全
局域网
一、局域网 局域网(Local Area Network,简称LAN)是指在一个相对较小的地理范围内,如家庭、办公室、学校等建立的局部网络。局域网通常由一组相互连接的计算机、服务器、打印机和其他网络设备组成,这些设备通过网络传输介质(如以太网、无线局域网等)连接在一起。 局域网的特点包括以下几点: 1. 地理范围较小:局域网的范围通常限制在一个建筑物、校园或办公区域内,距离通常不超过几百米。 2. 高速传输:局域网通常采用高速传输介质,如以太网,以提供快速的数据传输速度。这使得局域网内的设备可以快速地共享文件、打印机、互联网连接等资源。 3. 共享资源:局域网内的设备可以共享资源,如共享文件、
1718 0
|
Cloud Native 数据可视化 数据安全/隐私保护
云原生之部署Docker可视化管理工具docker.ui
云原生之部署Docker可视化管理工具docker.ui
957 2
|
存储 数据挖掘 大数据
详解阿里云数据中台,一篇文章全面了解大数据“网红”
一直想写一篇关于数据中台正面文章,现在有闲时做些总结,想充分诠释一下DT内部人如何看待数据中台。 数据中台的概念是最早由阿里巴巴首次提出,是为了应对内部众多业务部门千变万化的数据需求和高速时效性的要求而成长起来的,它既要满足业务部门日常性的多个业务前台的数据需求,又要满足像双十一,六一八这样的业务高峰、应对大规模数据的线性可扩展问题、应对复杂活动场景业务系统的解耦问题,而在技术、组织架构等方面采取的一些变革。
27319 0
|
10月前
|
人工智能 自然语言处理 搜索推荐
02_用LLM写文章:从提示到生成高质量内容
在2025年的今天,大语言模型(LLM)已经从实验性技术发展成为内容创作者的强大助手。随着GPT-5、Claude 3.5、Llama 3等先进模型的出现,AI辅助写作不仅变得更加普及,而且质量也达到了前所未有的高度。本文将深入探讨如何利用LLM进行高效、高质量的内容创作,从提示设计到内容优化的全过程,帮助你在这个AI时代掌握内容创作的新技能。
1086 156
|
6月前
|
机器学习/深度学习 决策智能 开发者
从单 Agent 到多智能体系统:工程复杂度如何指数级上升
多智能体系统工程难点不在模型调用,而在协作复杂度的指数级增长:状态组合爆炸、交互路径不可枚举、调试成本非线性上升。其本质是“协调问题”而非“执行问题”,成败关键在于统一状态管理与协作协议设计。
|
人工智能 自然语言处理 资源调度
蚂蚁百宝箱“一箱搞定”会展智能,「桐小乌」为乌镇互联网大会提供全天候一站式向导服务
2025世界互联网大会·乌镇峰会圆满落幕,蚂蚁百宝箱依托智能体开发平台,快速打造会展专属智能体“桐小乌”,实现会前、会中、会后全链路智能化服务。通过“碰一下”打卡、AR导览、智能问答等功能,提升参会体验;基于行业模板与零代码能力,助力展会高效运营,推动智能会展“一箱搞定”。
494 0
|
7月前
|
存储 人工智能 安全
重构认知——AI智能体来了从0到1的落地工程全指南
本文系统阐述AI智能体开发方法论:突破“调参”思维,以感知、决策、执行、记忆四大架构为基,提出从场景锁定到评估优化的“五步跃迁法”,助力开发者构建具备行业深度与自主行动力的数字生命。(239字)
513 0
|
8月前
|
传感器 存储 人工智能
2026年企业级网络监控选型指南
2026年十大IT监控工具深度解析:从OpManager的全能均衡,到Zabbix的极致灵活,再到Datadog的云原生领先,覆盖混合云、AIOps与成本控制。无论你是中小企业求稳,还是大型企业追优,亦或技术极客自研,都能找到适配之选。选型不再盲从,洞察趋势方能致远。
646 0
|
9月前
|
Java Swift Android开发
Kotlin vs Swift:现代移动开发的“双子星”全面对比
Kotlin与Swift是现代移动开发的两大主流语言,分别主导Android与iOS生态。本文全面对比二者在语法、空安全、并发、性能及跨平台等方面的异同,深入解析其设计理念与适用场景,助你根据平台需求与技术战略做出最优选择。
693 0
|
消息中间件 运维 安全
C5GAME 游戏饰品交易平台借助 RocketMQ Serverless 保障千万级玩家流畅体验
游戏行业蓬勃发展,作为国内领先的 STEAM 游戏饰品交易的服务平台,看 C5GAME 如何利用 RocketMQ Serverless 技术,为千万级玩家提供流畅的游戏体验,同时降低成本并提升运维效率。
1332 152
C5GAME 游戏饰品交易平台借助 RocketMQ Serverless 保障千万级玩家流畅体验

热门文章

最新文章