Tomcat 内存溢出 "OutOfMemoryError" 问题总结 (JVM参数说明）

时间 2019-11-10

标签 tomcat 内存溢出 outofmemoryerror 问题总结 jvm 参数说明栏目 Tomcat 繁體版

原文原文链接

问题说明：
公司内网环境中部署的jenkins代码发版平台忽然不能访问了，查看tomcat的catalina.out日志发现报错以下：java

[root@redmine logs]# tail -f /srv/apache-tomcat-7.0.67/logs/catalina.out
......
Exception in thread "http-bio-8080-exec-5" java.lang.OutOfMemoryError: PermGen space
Exception in thread "http-bio-8080-exec-5" java.lang.OutOfMemoryError: PermGen space
Exception in thread "http-bio-8080-exec-5" java.lang.OutOfMemoryError: PermGen space
......

上面报错是因为tomcat内存溢出引发的：程序员

[root@redmine logs]# ps -ef|grep tomcat
root     23615     1 14 15:15 ?        00:04:45 /usr/java/jdk1.7.0_79/bin/java -Djava.util.logging.config.file=/srv/apache-tomcat-7.0.67/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/srv/apache-tomcat-7.0.67/endorsed -classpath /srv/apache-tomcat-7.0.67/bin/bootstrap.jar:/srv/apache-tomcat-7.0.67/bin/tomcat-juli.jar -Dcatalina.base=/srv/apache-tomcat-7.0.67 -Dcatalina.home=/srv/apache-tomcat-7.0.67 -Djava.io.tmpdir=/srv/apache-tomcat-7.0.67/temp org.apache.catalina.startup.Bootstrap start
root     24191 24013  0 15:49 pts/6    00:00:00 grep tomcat

Tomcat默承认以使用的内存为128MB，在较大型的应用项目中，这点内存显然是不够的，从而有可能致使系统没法运行！
其中常见的内存问题是报Tomcat内存溢出错误，Out of Memory(系统内存不足)的异常，从而致使客户端显示500错误。
在生产环境中，tomcat内存设置很差很容易出现JVM内存溢，解决方法就是：修改Tomcat中的catalina.sh文件（windows系统下修改的文件时catalina.bat）。在catalina.sh文件中，找到cygwin=false，在这一行的前面加入参数，具体以下：web

[root@redmine bin]# pwd
/srv/apache-tomcat-7.0.67/bin
[root@redmine bin]# vim catalina.sh     //在cygwin=false这一行的上面添加下面内容
......
JAVA_OPTS='-Xms1024m -Xmx1024m -XX:PermSize=256M -XX:MaxNewSize=512m -XX:MaxPermSize=512m'
cygwin=false
......

其中，-Xms设置初始化内存大小，-Xmx设置可使用的最大内存。通常把-Xms和-Xmx设为同样大算法

接着重启tomcat便可，重启后查看tomcat服务进程，就能看到内存信息了：数据库

[root@redmine bin]# ps -ef|grep tomcat|grep -v grep|awk -F" " '{print $2}'|xargs kill -9

[root@redmine bin]# /srv/apache-tomcat-7.0.67/bin/startup.sh 

[root@redmine bin]# ps -ef|grep tomcat
root     24547     1  3 15:53 pts/6    00:01:02 /usr/java/jdk1.7.0_79/bin/java -Djava.util.logging.config.file=/srv/apache-tomcat-7.0.67/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms1024m -Xmx1024m -XX:PermSize=256M -XX:MaxNewSize=512m -XX:MaxPermSize=512m -Djava.endorsed.dirs=/srv/apache-tomcat-7.0.67/endorsed -classpath /srv/apache-tomcat-7.0.67/bin/bootstrap.jar:/srv/apache-tomcat-7.0.67/bin/tomcat-juli.jar -Dcatalina.base=/srv/apache-tomcat-7.0.67 -Dcatalina.home=/srv/apache-tomcat-7.0.67 -Djava.io.tmpdir=/srv/apache-tomcat-7.0.67/temp org.apache.catalina.startup.Bootstrap start
root     24982 24013  0 16:22 pts/6    00:00:00 grep tomcat

Tomcat链接数设置：在tomcat配置文件server.xml中的<Connector ... />配置中，和链接数相关的参数有：
minProcessors：最小空闲链接线程数，用于提升系统处理性能，默认值为10
maxProcessors：最大链接线程数，即：并发处理的最大请求数，默认值为75
maxThreads 最大并发线程数，即同时处理的任务个数，默认值是200
acceptCount：容许的最大链接数，应大于等于maxProcessors，默认值为100
enableLookups：是否反查域名，取值为：true或false。为了提升处理能力，应设置为false
connectionTimeout：网络链接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。一般可设置为30000毫秒。apache

其中和最大链接数相关的参数为maxProcessors和acceptCount。若是要加大并发链接数，应同时加大这两个参数。
web server容许的最大链接数还受制于操做系统的内核参数设置，一般Windows是2000个左右，Linux是1000个左右。Unix中如何设置这些参数，请参阅Unix经常使用监控和管理命令编程

例如:bootstrap

<Connector port="8888" protocol="HTTP/1.1" 
maxThreads="500" minSpareThreads="50" maxSpareThreads="100" enableLookups="false" acceptCount="2000" 
connectionTimeout="20000" 
redirectPort="8443" />

Tomcat内存溢出，堆栈配置的JVM参数说明：Xmn、Xms、Xmx、Xss都是JVM对内存的配置参数，能够根据不一样须要区修改这些参数，以达到运行程序的最好效果。
-Xms：堆内存的最小大小，默认为物理内存的1/64。即初始堆大小。
-Xmx：堆内存的最大大小，默认为物理内存的1/4。即最大堆大小。
-Xmn：堆内新生代的大小。经过这个值也能够获得老生代的大小：-Xmx减去-Xmn。即新生代大小。
-Xss：设置每一个线程可以使用的内存大小，即栈的大小。在相同物理内存下，减少这个值能生成更多的线程，固然操做系统对一个进程内的线程数仍是有限制的，不能无限生成。线程栈的大小是个双刃剑，若是设置太小，可能会出现栈溢出，特别是在该线程内有递归、大的循环时出现溢出的可能性更大，若是该值设置过大，就有影响到建立栈的数量，若是是多线程的应用，就会出现内存溢出的错误。vim

除了这些配置，JVM还有很是多的配置，经常使用的梳理以下：
1、堆设置
-XX:NewRatio: 设置新生代和老年代的比值。如：为3，表示年轻代与老年代比值为1：3
-XX:SurvivorRatio: 新生代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：为3，表示Eden：Survivor=3：2，一个Survivor区占整个新生代的1/5
-XX:MaxTenuringThreshold: 设置转入老年代的存活次数。若是是0，则直接跳过新生代进入老年代
-XX:PermSize、-XX:MaxPermSize: 分别设置永久代最小大小与最大大小（Java8之前）。即第一个是设定内存的永久保存区域，第二个是设定最大内存的永久保存区域。
-XX:MetaspaceSize、-XX:MaxMetaspaceSize: 分别设置元空间最小大小与最大大小（Java8之后）windows

2、收集器设置
-XX:+UseSerialGC: 设置串行收集器
-XX:+UseParallelGC: 设置并行收集器
-XX:+UseParalledlOldGC: 设置并行老年代收集器
-XX:+UseConcMarkSweepGC: 设置并发收集器

3、垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename

4、并行收集器设置
-XX:ParallelGCThreads=n: 设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis=n: 设置并行收集最大暂停时间
-XX:GCTimeRatio=n: 设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

5、并发收集器设置
-XX:+CMSIncrementalMode: 设置为增量模式。适用于单CPU状况。
-XX:ParallelGCThreads=n: 设置并发收集器新生代收集方式为并行收集时，使用的CPU数。并行收集线程数。

以下面是一个jvm进程是查询出来(ps -ef)的参数设置状况：
-Xmx256m -Xms256m -Xmn64m -XX:PermSize=64m -Xss256k -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

TOMCAT组件一概使用平滑启停模式，请确保全部应用系统能够平滑启停。
启动命令：
$ CATALINA_HOME/bin/startup.sh
中止命令：
$ CATALINA_HOME/bin/shutdown.sh
 
 
TOMCAT配置：
TOMCAT组件使用标准化部署，对于jvm基本配置的调整有如下两个途径：
1）在tomcat安装目录的bin/catalina.sh脚本里调整（添加下面内容）
[app@kevin bin]$ vim ../bin/catalina.sh
#!/bin/sh
#
export JAVA_OPTS="
-server                       # -server：必定要做为第一个参数，在多个CPU时性能佳
-Xms2048M                     # 初始Heap大小，使用的最小内存,cpu性能高时此值应设的大一些
-Xmx2048M                     # java heap最大值，使用的最大内存
-Xmn512M                      # young generation的heap大小，通常设置为Xmx的三、4分之一
-Xss1024K                     # 每一个线程的Stack大小
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=256m
-XX:SurvivorRatio=8
-XX:TargetSurvivorRatio=90
-XX:MaxTenuringThreshold=7
-XX:GCTimeRatio=19
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:+DisableExplicitGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/var/log/bsp/tomcat_8082_servicefront/gc.log"
..............
..............

2）在tomcat安装目录的bin/setenv.sh脚本里调整
[app@kevin bin]$ vim ../bin/catalina.sh
JAVA_HOME=/root/base/jdk8
JAVA_OPTS="
-server
-Xms2048M
-Xmx2048M
-Xmn521M
-Xss1024K
-XX:MetaspaceSize=256m 
-XX:MaxMetaspaceSize=256m
-XX:SurvivorRatio=8
-XX:TargetSurvivorRatio=90
-XX:MaxTenuringThreshold=7
-XX:GCTimeRatio=19
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:+DisableExplicitGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:SoftRefLRUPolicyMSPerMB=0
-XX:+PrintClassHistogram
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/var/log/tomcat_19090_jenkins/gc.log
-Dhudson.model.ParametersAction.keepUndefinedParameters=true 
-DJENKINS_HOME='/mnt/jenkins_config' 
-Djava.awt.headless=true"

Tomcat常见内存溢出的几种状况：
OutOfMemoryError：Java heap space
OutOfMemoryError：GC overhead limit exceeded
OutOfMemoryError：Permgen space
OutOfMemoryError：Metaspace

1）OutOfMemoryError：Java heap space
每一个Java程序都只能使用必定量的内存, 这种限制是由JVM的启动参数决定的。而更复杂的状况在于, Java程序的内存分为两部分: 堆内存(Heap space)和永久代(Permanent Generation, 简称 Permgen):

这两个区域的最大内存大小, 由JVM启动参数 -Xmx 和 -XX: MaxPermSize 指定. 若是没有明确指定, 则根据平台类型(好比OS版本+ JVM版本)和物理内存的大小来肯定。假如在建立新的对象时, 堆内存中的空间不足以存放新建立的对象, 就会引起java.lang.OutOfMemoryError: Java heap space 错误。无论机器上还有没有空闲的物理内存, 只要堆内存使用量达到最大内存限制, 就会抛出 java.lang.OutOfMemoryError: Java heap space 错误。

缘由分析
产生 java.lang.OutOfMemoryError: Java heap space 错误的缘由, 不少时候, 就相似于将 XXL 号的对象,往 S 号的 Java heap space 里面塞。其实清楚了缘由, 就很容易解决。只要增长堆内存的大小, 程序就能正常运行. 另外还有一些比较复杂的状况, 主要是由代码问题致使的:
a）超出预期的访问量/数据量。应用系统设计时,通常是有 “容量” 定义的, 部署这么多机器, 用来处理必定量的数据/业务。若是访问量忽然飙升, 超过预期的阈值, 相似于时间坐标系中针尖形状的图谱, 那么在峰值所在的时间段, 程序极可能就会卡死、并触发 java.lang.OutOfMemoryError: Java heap space 错误。

b）内存泄露(Memory leak). 这也是一种常常出现的情形。因为代码中的某些错误, 致使系统占用的内存愈来愈多. 若是某个方法/某段代码存在内存泄漏的, 每执行一次, 就会（有更多的垃圾对象）占用更多的内存. 随着运行时间的推移, 泄漏的对象耗光了堆中的全部内存, 那么 java.lang.OutOfMemoryError: Java heap space 错误就爆发了。

解决方案
若是设置的最大内存不知足程序的正常运行, 只须要增大堆内存便可。但不少状况下, 增长堆内存空间并不能解决问题。好比存在内存泄漏, 增长堆内存只会推迟 java.lang.OutOfMemoryError: Java heap space 错误的触发时间。固然, 增大堆内存, 可能会增长 GC pauses 的时间, 从而影响程序的吞吐量或延迟。

2）OutOfMemoryErro: GC overhead limit exceeded
Java运行时环境内置了垃圾收集(GC) 模块. 上一代的不少编程语言中并无自动内存回收机制, 须要程序员手工编写代码来进行内存分配和释放, 以重复利用堆内存。在Java程序中, 只须要关心内存分配就行。若是某块内存再也不使用, 垃圾收集(Garbage Collection) 模块会自动执行清理。通常来讲, JVM内置的垃圾收集算法就可以应对绝大多数的业务场景。java.lang.OutOfMemoryError: GC overhead limit exceeded 这种状况发生的缘由是, 程序基本上耗尽了全部的可用内存, GC也清理不了。暂时解决这个问题de 方法: 1）增长参数，-XX:-UseGCOverheadLimit，关闭这个特性；2）同时增长heap大小：-Xmx1024m。

缘由分析
JVM抛出 java.lang.OutOfMemoryError: GC overhead limit exceeded 错误就是发出了这样的信号: 执行垃圾收集的时间比例太大, 有效的运算量过小. 默认状况下, 若是GC花费的时间超过 98%, 而且GC回收的内存少于 2%, JVM就会抛出这个错误。

须要注意：java.lang.OutOfMemoryError: GC overhead limit exceeded 错误只在连续屡次 GC 都只回收了不到2%的极端状况下才会抛出。假如不抛出 GC overhead limit 错误会发生什么状况呢? 那就是GC清理的这么点内存很快会再次填满, 迫使GC再次执行. 这样就造成恶性循环, CPU使用率一直是100%, 而GC却没有任何成果. 系统用户就会看到系统卡死 - 之前只须要几毫秒的操做, 如今须要好几分钟才能完成。

解决方案
有一种应付了事的解决方案, 就是不想抛出 “java.lang.OutOfMemoryError: GC overhead limit exceeded” 错误信息, 则添加下面启动参数:

#不推荐
-XX:-UseGCOverheadLimit

强烈建议不要指定该选项: 由于这不能真正地解决问题，只能推迟一点 out of memory 错误发生的时间，到最后还得进行其余处理。指定这个选项, 会将原来的 java.lang.OutOfMemoryError: GC overhead limit exceeded 错误掩盖，变成更常见的 java.lang.OutOfMemoryError: Java heap space 错误消息。

须要注意: 有时候触发 GC overhead limit 错误的缘由, 是由于分配给JVM的堆内存不足。这种状况下只须要增长堆内存大小便可。在大多数状况下, 增长堆内存并不能解决问题。例如程序中存在内存泄漏, 增长堆内存只能推迟产生 java.lang.OutOfMemoryError: Java heap space 错误的时间。固然, 增大堆内存, 还有可能会增长 GC pauses 的时间, 从而影响程序的吞吐量或延迟。若是想从根本上解决问题, 则须要排查内存分配相关的代码. 简单来讲, 须要回答如下问题:

能够根据内存分析的结果, 以及Plumbr生成的报告（下面会提到）, 若是发现对象占用的内存很合理, 也不须要修改源代码的话, 那就增大堆内存吧。在这种状况下,修改JVM启动参数, (按比例)增长下面的值:

-Xmx1024m

这里配置了最大堆内存为 1024MB。能够根据实际状况修改这个值. 若是JVM仍是会抛出 OutOfMemoryError, 那么可能还须要查询手册, 或者借助工具再次进行分析和诊断。也可使用 g/G 表示 GB, m/M 表明 MB, k/K 表示 KB.下面的这些形式都是等价的, 设置Java堆的最大空间为 1GB:

# 等价形式: 最大1GB内存
java -Xmx1073741824 com.mycompany.MyClass
java -Xmx1048576k com.mycompany.MyClass
java -Xmx1024m com.mycompany.MyClass
java -Xmx1g com.mycompany.MyClass

3）OutOfMemoryError: Permgen space
PermGen space是指内存的永久保存区域。OutOfMemoryError: PermGen space从表面上看就是内存益出，解决方法也必定是加大内存。说说为何会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不一样,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，因此若是你的APP会LOAD不少CLASS的话,就极可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。

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

这些区域的最大值, 由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 数量太多或体积太大。

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

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

以上配置容许JVM使用的最大 PermGen 空间为 512MB, 若是还不够, 就会抛出 OutOfMemoryError。

b）解决运行时产生的 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

经过来讲，java.lang.OutOfMemoryError: PermGen space有效解决方法：手动设置MaxPermSize大小修改TOMCAT_HOME/bin/catalina.sh

在 catalina.sh 文件 echo "Using CATALINA_BASE:   $CATALINA_BASE"上面或者第一行加入如下行：
set JAVA_OPTS=%JAVA_OPTS% -server -XX:PermSize=256M -XX:MaxPermSize=512m

4）OutOfMemoryError: Metaspace
Metaspace能够简单理解为为存放的类元信息和方法信息的一个JVM 块，Metaspace是JDK1.8的新特性，能够把它理解为JDK1.6的PermGen区域（可是二者也有很大区别的）。JVM限制了Java程序的最大内存, 修改/指定启动参数能够改变这种限制。Java将堆内存划分为多个部分, 以下图所示:

[Java8及以上版本]这些内存池的最大值, 由 -Xmx 和 -XX:MaxMetaspaceSize 等JVM启动参数指定. 若是没有明确指定, 则根据平台类型(OS版本+JVM版本)和物理内存的大小来肯定。java.lang.OutOfMemoryError: Metaspace 错误所表达的信息是: 元数据区(Metaspace) 已被用满

缘由分析
若是你是Java老司机, 应该对 PermGen 比较熟悉. 但从Java 8开始,内存结构发生重大改变, 再也不使用Permgen, 而是引入一个新的空间: Metaspace. 这种改变基于多方面的考虑, 部分缘由列举以下:Permgen空间的具体多大很难预测。指定小了会形成 java.lang.OutOfMemoryError: Permgen size 错误, 设置多了又形成浪费。
a）为了 GC 性能的提高, 使得垃圾收集过程当中的并发阶段再也不停顿, 另外对 metadata 进行特定的遍历(specific iterators)。
b）对 G1垃圾收集器的并发 class unloading 进行深度优化。
c）在Java8中,将以前 PermGen 中的全部内容, 都移到了 Metaspace 空间。例如: class 名称, 字段, 方法, 字节码, 常量池, JIT优化代码, 等等。

Metaspace 使用量与JVM加载到内存中的 class 数量/大小有关。能够说java.lang.OutOfMemoryError: Metaspace 错误的主要缘由,是加载到内存中的 class 数量太多或者体积太大。

解决方案
若是抛出与 Metaspace 有关的 OutOfMemoryError , 第一解决方案是增长 Metaspace 的大小. 使用下面这样的启动参数:

-XX:MaxMetaspaceSize=512m

这里将 Metaspace 的最大值设置为 512MB, 若是没有用完, 就不会抛出 OutOfMemoryError。

有一种看起来很简单的方案：直接去掉 Metaspace 的大小限制。但须要注意：不限制Metaspace内存的大小, 倘若物理内存不足, 有可能会引发内存交换(swapping), 严重拖累系统性能。此外,还可能形成native内存分配失败等问题。在现代应用集群中,宁肯让应用节点挂掉, 也不但愿其响应缓慢。若是不想收到报警, 能够像鸵鸟同样, 把 java.lang.OutOfMemoryError: Metaspace 错误信息隐藏起来。但这不能真正解决问题, 只会推迟问题爆发的时间。若是确实存在内存泄露, 请参考前面的文章, 认真寻找解决方案。

要从根本上解决上面说到的这四种Tomcat 内存溢出 "OutOfMemoryError" 问题, 则需排查分配内存的代码. 简单来讲, 须要解决这些问题:
a）哪类对象占用了最多内存？
b）这些对象是在哪部分代码中分配的。

要搞清出这一点, 可能须要好几天时间。下面是大体的流程:
a）得到在生产服务器上执行堆转储(heap dump)的权限。"转储"(Dump)是堆内存的快照, 稍后能够用于内存分析. 这些快照中可能含有机密信息, 例如密码、信用卡帐号等, 因此有时候, 因为企业的安全限制, 要得到生产环境的堆转储并不容易。
b）在适当的时间执行堆转储。通常来讲,内存分析须要比对多个堆转储文件, 假如获取的时机不对, 那就多是一个"废"的快照. 另外, 每次执行堆转储, 都会对JVM进行"冻结", 因此生产环境中,也不能执行太多的Dump操做,不然系统缓慢或者卡死,你的麻烦就大了。
c）用另外一台机器来加载Dump文件。通常来讲, 若是出问题的JVM内存是8GB, 那么分析 Heap Dump 的机器内存须要大于 8GB. 打开转储分析软件(咱们推荐Eclipse MAT , 固然你也可使用其余工具)。
d）检测快照中占用内存最大的 GC roots。

接下来, 找出可能会分配大量对象的代码. 若是对整个系统很是熟悉, 可能很快就能定位了。这里推荐一款检查内存泄露工具 plumbr 。 Plumbr 能捕获全部java.lang.OutOfMemoryError , 并找出其余的性能问题, 例如最消耗内存的数据结构等等。Plumbr 在后台负责收集数据 —— 包括堆内存使用状况(只统计对象分布图, 不涉及实际数据),以及在堆转储中不容易发现的各类问题。若是发生 java.lang.OutOfMemoryError , 还能在不停机的状况下, 作必要的数据处理. 下面是Plumbr 对一个 java.lang.OutOfMemoryError 的提醒:

以上能直接看到:
a) 哪类对象占用了最多的内存(此处是 271 个 com.example.map.impl.PartitionContainer 实例, 消耗了 173MB 内存, 而堆内存只有 248MB)
b）这些对象在何处建立(大部分是在 MetricManagerImpl 类中,第304行处)
c）当前是谁在引用这些对象(从 GC root 开始的完整引用链)
得知这些信息, 就能够定位到问题的根源, 例如是当地精简数据结构/模型, 只占用必要的内存便可。

来看一个案例：公司的jenkins在使用过程当中出现报错 "java.lang.OutOfMemoryError: Metaspace"

解决办法：

[root@kevin ~]# ps -ef|grep tomcat_jenkins
root      59446   4761 12 May27 ?        5-12:10:08 /root/base/jdk8/bin/java -Djava.util.logging.config.file=/root/tomcat_jenkins/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -Xms5120M -Xmx5120M -Xmn1500M -Xss1024K -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m 
-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=7 -XX:GCTimeRatio=19 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled 
-XX:-CMSParallelRemarkEnabled -XX:+DisableExplicitGC -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -Xloggc:/var/log/tomcat_19090_jenkins/gc.log -Dhudson.model.ParametersAction.keepUndefinedParameters=true 
-DJENKINS_HOME=/mnt/jenkins_config -Djava.awt.headless=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -classpath 
/root/tomcat_jenkins/bin/bootstrap.jar:/root/tomcat_jenkins/bin/tomcat-juli.jar -Dcatalina.base=/root/tomcat_jenkins -Dcatalina.home=/root/tomcat_jenkins -Djava.io.tmpdir=/root/tomcat_jenkins/temp org.apache.catalina.startup.Bootstrap start

发现当前Metaspace元数据区设置为512M，查看配置：
[root@kevin ~]# cat /root/tomcat_jenkins/bin/setenv.sh
JAVA_HOME=/root/base/jdk8
.......
.......
-XX:MetaspaceSize=512m 
-XX:MaxMetaspaceSize=512m

将setenv.sh文件中的Metaspace相关的jvm值大点
[root@kevin ~]# cat /root/tomcat_jenkins/bin/setenv.sh
.......
.......
-XX:MetaspaceSize=1024m 
-XX:MaxMetaspaceSize=1024m

而后重启这个tomcat_jenkins服务便可

Java内存溢出（java.lang.OutOfMemoryError）常见问题运维总结

在解决java内存溢出问题以前，须要对jvm（java虚拟机）的内存管理有必定的认识。jvm管理的内存大体包括三种不一样类型的内存区域：Permanent Generation space（永久保存区域）、Heap space(堆区域)、Java Stacks(Java栈）。其中：
- Permanent Generation space主要存放Class(类)和Meta信息，Class第一次被Load时被放入PermGen space区域，Class须要存储的内容主要包括方法和静态属性。
- Heap space用来存放Class实例(即对象), 对象需存储的内容主要是非静态属性。每次用new建立一个对象实例后，对象实例存储在堆区域中，这部分空间被jvm垃圾回收机制管理。
- Java StacksJava栈跟大多数编程语言包括汇编语言的栈功能类似，主要基本类型变量以及方法的输入输出参数。Java程序的每一个线程中都有一个独立的堆栈。

注意：容易发生内存溢出问题的内存空间包括：Permanent Generation space和Heap space。

1）第一种 OutOfMemoryError： PermGen space (1.8后更新为Metaspace，不存在)
PermSpace主要是存放静态的类信息和方法信息，静态的方法和变量，final标注的常量信息等。发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。解决这类问题有如下两种办法：
a）增长java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。如针对tomcat6.0，在catalina.sh 或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右）增长一行：
JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m"
b）清理应用程序中web-inf/lib下的jar，若是tomcat部署了多个应用，不少应用都使用了相同的jar，能够将共同的jar移到tomcat共同的lib下，减小类的重复加载。

第二种 OutOfMemoryError： Java heap space
发生这种问题的缘由是java虚拟机建立的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heap space有关。解决这类问题有两种思路：
a）检查代码中是否有死循环或递归调用；检查是否有大循环重复产生新对象实体；检查对数据库查询中是否有一次得到所有数据的查询。通常来讲，若是一次取十万条记录到内存，就可能引发内存溢出。这个问题比较隐蔽，在上线前数据库中数据较少，不容易出问题，上线后数据库中数据多了，一次查询就有可能引发内存溢出。所以对于数据库查询尽可能采用分页的方式查询；检查List、MAP等集合对象是否有使用完后未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。
b）增长Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m

第三种 OutOfMemoryError：unable to create new native thread
在java应用中有时候会出现这样的错误：OutOfMemoryError: unable to create new native thread。这种怪事是由于JVM已经被系统分配了大量的内存(好比1.5G)，而且它至少要占用可用内存的一半。有人发现，在线程个数不少的状况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。对于这个异常咱们首先须要判断下，发生内存溢出时进程中到底都有什么样的线程，这些线程是不是应该存在的，是否能够经过优化来下降线程数；另一方面默认状况下java为每一个线程分配的栈内存大小是1M，一般状况下，这1M的栈内存空间是足足够用了，由于在一般在栈上存放的只是基础类型的数据或者对象的引用，这些东西都不会占据太大的内存，咱们能够经过调整jvm参数，下降为每一个线程分配的栈内存大小来解决问题，例如在jvm参数中添加-Xss128k将线程栈内存大小设置为128k。