一次使用EclipseMemoryAnalyzer分析Tomcat内存溢出
tomcat内存溢出分析及解决方案
Tomcat内存溢出的原因在生产环境中tomcat内存设置不好很容易出现内存溢出。
造成内存溢出是不一样的，当然处理方式也不一样。
这里根据平时遇到的情况和相关资料进行一个总结。
常见的一般会有下面三种情况：1.OutOfMemoryError：Java heap space2.OutOfMemoryError：PermGen space3.OutOfMemoryError：unable to create new native thread.Tomcat内存溢出解决方案对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。
（-Xms -Xmx -XX：PermSize -XX：MaxPermSize）最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。
第一种：是堆溢出。
原因分析：JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。
可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。
Heap size 的大小是Young Generation 和Tenured Generaion 之和。
在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。
没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。
-Xms：初始堆大小-Xmx：最大堆大小但堆的大小受下面三方面影响：1.相关操作系统的数据模型（32-bt还是64-bit）限制；（32位系统下，一般限制在1.5G~2G；我在2003 server 系统下（物理内存：4G和6G，jdk：1.6）测试1612M，64位操作系统对内存无限制。
JVM：全面理解线上服务器内存溢出(OOM)问题处理方案
JVM：全面理解线上服务器内存溢出（OOM）问题处理方案在现代应用程序开发中，内存管理是一个非常重要的方面。
虽然现代计算机中的内存容量已经非常大，但是在高负载和大数据量的情况下，仍然可能遇到内存溢出（OOM）。
内存溢出是指程序在运行过程中使用的内存量超过了系统设置的限制，导致程序运行失败。
这对生产环境的服务器是非常严重的，因为它可能导致服务器崩溃，进而影响用户体验。
JVM是Java程序的运行时环境，一旦发生线上服务器内存溢出问题，我们需要处理这个问题的步骤如下：一、分析内存溢出错误日志JVM在发生内存溢出时会产生错误日志，这些日志信息提供了非常有用的信息，有助于分析问题的原因。
在分析日志的时候，需要关注以下几个方面：1.错误信息：内存溢出错误的类型，以及导致错误的相关代码。
2.内存使用情况：分析 JVM 中各个方面的内存使用情况，例如堆内存、非堆内存、元数据内存等。
3.内存泄漏：分析可能导致内存泄漏的代码。
二、调整 JVM 参数JVM提供了很多可供调整的参数，通过调整这些参数可以使JVM 在运行过程中使用更少的内存。
例如，调整堆大小、非堆大小、GC策略等。
在选择适当的 JVM 参数时，可以参考JVM 官方文档中提供的建议参数。
但是，需要注意的是，不要随意调整JVM 参数，否则可能会导致系统运行状况更糟糕。
三、检查代码中的内存泄漏内存泄漏是指程序中申请的内存没有被及时释放，导致内存空间被占用，进而导致内存溢出。
在 Java 中，由于 Java 自带GC，因此内存泄漏的问题相对较少，但仍然有可能发生。
在排查内存泄漏问题时，可以使用 Java 堆栈跟踪工具，例如Eclipse Memory Analyzer (MAT) 来分析堆中的对象和数据，从而快速定位内存泄漏的原因。
四、优化代码优化代码是解决内存溢出问题的最重要的一步。
通过优化代码，减少对内存的消耗，可以有效地防止内存溢出问题。
优化代码的方法有很多，例如，使用缓存、避免频繁的创建多个对象、使用数据结构等。
Tomcat内存溢出分析及解决方法
Tomcat内存溢出分析及解决方法Tomcat内存溢出分析及解决方法JVM管理两种类型的内存，堆和非堆。
堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。
它和堆不同，运行期内GC不会释放空间。
一、内存溢出类型1、ng.OutOfMemoryError: PermGen spaceJVM管理两种类型的内存，堆和非堆。
堆是给开发人员用的上面说的就是，是在JVM启动时创建;非堆是留给JVM自己用的，用来存放类的信息的。
它和堆不同，运行期内GC不会释放空间。
如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。
PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。
如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。
一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况)set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m在linux下在tomcathome/conf/catalina.sh中加上如标红所示的一句代码：可以增加tomcat jvm 的内存，这样就不容易出现内存溢出的现象了！# ----- Execute The Requested Command -----------------------------------------JAVA_OPTS="-server -Xms512m -Xmx2048m -XX:PermSize=128m -XX:MaxNewSize=256m -XX:MaxPermSize=256m"# Bugzilla 37848: only output this if we have a TTY2、ng.OutOfMemoryError: Javaheap space第一种情况是个补充，主要存在问题就是出现在这个情况中。
eclipse经常卡死、反应慢、内存溢出的解决方案
eclipse经常卡死、反应慢、内存溢出的解决⽅案开发过程中经常遇到eclipse卡死的问题，所以特此通过⽹上查找和实践总结了以下解决⽅法：1.修改eclipse内存找到eclipse的安装⽬录，在⽬录下有个eclipse.ini⽂件，打开添加如下配置（我的电脑内存3G，可以参考下⾯配置做调整，不⽤太⾼）-Xms1024m-Xmx2048m-XX:MaxPermSize=1024M-XX:-UseGCOverheadLimit2.修改JDK的使⽤内存打开eclipse，window->preference->Java->Installed JREs，选中使⽤的jdk然后点击右侧的edit，在Default VM Arguments中输⼊以下值-Xms512m -Xmx512m -XX:MaxNewSize=512m -XX:MaxPermSize=512m3.取消⼀些不必要的插件启动window->preference->General->Startup and Shutdown ,将插件的启动全部取消4.取消⾃动检测，修改⼀些jsp、html等⽂件保存时会⾃动检测导致eclipse卡掉，所以全部取消掉window->preference->Validation5.关闭拼写检查window->preference->General->Editors->Text Editors->Spelling ,取消掉Enable spelling checking6.取消⾃动编译，java类修改时就不会⾃动编译了Project->Build Automatically 前⾯的勾取消掉7.修改jsp、html等容易卡顿⽂件的编辑⼯具window->preference->General->Editors->File Associations ，选择*.html，下⾯的aSSociated editors 选择Text Editor...然后点击右侧的Default，继续FileTypes选择*.jsp，后续操作⼀样，都改为默认Text Editor...8.修改打开链接的快捷键，将ctrl改为alt9.杜绝jar包访问⽹络window->preference->Java->Installed JREs 选择使⽤的jre并点击右侧的Edit在编辑框中的JRE system libraries找到jre的rt.jar和charsets.jar，将其中的Javadoc location通过右侧的remove按钮置为none.10.代码修改时不重启tomcat在eclipse中打开⽂件server.xml，将reloadable改为false,添加crossContext="true"，这样就能进⾏热启动了，注意需要⽤debug模式启动。
memoryanalyzer 用法
一、什么是memoryanalyzer？Memoryanalyzer 是一个用于分析 Java 程序在运行过程中的内存使用情况的工具。
它可以帮助开发人员识别和解决内存泄漏和内存溢出等问题，以提高程序的性能和稳定性。
二、 memoryanalyzer 的主要功能1. 内存快照分析：通过获取 Java 程序的内存快照，memoryanalyzer 可以帮助开发人员查看程序在不同时间点的内存使用情况，以便分析内存泄漏和内存溢出等问题。
2. 内存泄漏检测：memoryanalyzer 可以帮助开发人员识别程序中存在的内存泄漏问题，从而及时解决这些问题，提高程序的内存利用率和性能。
3. 内存溢出分析：通过分析程序在运行过程中出现的内存溢出情况，memoryanalyzer 可以帮助开发人员定位问题代码，以便进行优化和改进。
三、 memoryanalyzer 的使用方法1. 获取内存快照：使用 memoryanalyzer 工具可以获取 Java 程序的内存快照。
可以使用命令行工具或者图形界面工具来获取内存快照。
2. 分析内存快照：获取内存快照后，可以使用 memoryanalyzer 工具来对内存快照进行分析，以查看程序在不同时间点的内存使用情况，并识别可能存在的内存泄漏和内存溢出问题。
3. 解决内存问题：根据 memoryanalyzer 的分析结果，开发人员可以及时解决程序中存在的内存问题，从而提高程序的性能和稳定性。
四、 memoryanalyzer 的优点和局限性1. 优点：memoryanalyzer 可以帮助开发人员快速定位并解决程序中的内存问题，提高程序的性能和稳定性。
2. 局限性：memoryanalyzer 在使用过程中需要一定的学习成本，而且对于庞大的内存快照的分析可能会消耗较多的时间和计算资源。
五、总结通过以上的介绍，我们可以看到，memoryanalyzer 是一个功能强大的工具，可以帮助开发人员分析 Java 程序的内存使用情况，并解决程序中可能存在的内存问题。
一次Java内存溢出异常的分析过程
一次Java内存溢出异常的分析过程2011-08-28 00:00中国IT实验室佚名字号：A+|A-前些天，服务器上一个服务跑了一个多月突然当掉了。
看了下日志，程序抛出了ng.OutOfMemoryError，之前也出现过同样的错误，服务跑了三个月内存溢出。
出现这个异常，初步判断是程序有内存泄漏，接下来需要利用一些工具来分析具体原因。
首先使用jdk自带的工具jmap转储(dump)java内存堆数据到本地文件中。
jmap转储(dump)命令格式如下：jmap -dump:表示dump选项，表示需要dump的java应用程序的进程IDdump-options可以有以下三种参数，参数之间用逗号隔开：live，只dump活动的object，如果没有指定，表示dump所有objectformat=b，字节流格式file=，是转储文件的保存路径下面是dump命令的一个例子:jmap -dump:format=b,file=heap.bin 8023dump完成后，用Eclipse Memory Analyzer打开转储文件进行分析。
Eclipse Memory Analyzer是一个java内存堆转储文件分析工具，可以生成内存分析报告(包括内存泄露Leak Suspects )。
下面是分析完成后查看Top Consumers所看到的图表:看到这两张图表，问题就比较明朗了。
berkeley db中的数据结点com.sleepycat.je.tree.BIN占用了大量内存，导致内存溢出了。
为了提高访问效率，berkeley db会缓存大量的结点，缓存大小限制可以在EnvironmentConfig设置，默认为jvm 内存大小限制的60%。
而这个应用程序中使用了5个EnvironmentImpl，并且都未单独设置缓存大小，总的缓存限制为jvm内存限制的300%(图表中BIN结点已经占用了94.55%的内存)，远远超出java的内存限制。
使用MAT工具进行内存溢出定位及分析
内存溢出监控及分析问题所在一、内存溢出&内存泄漏的名词解释内存溢出（out of memory）：就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。
内存泄露（memory leak）：是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。
二、何时会抛出内存溢出错误何时会抛出OutOfMemoryException，并不是内存被耗空的时候才抛出∙JVM98%的时间都花费在内存回收∙每次回收的内存小于2%满足这两个条件将触发OutOfMemoryException，这将会留给系统一个微小的间隙以做一些Down之前的操作，比如手动打印Heap Dump。
Q：为什么崩溃前垃圾回收的时间越来越长？A：根据内存模型和垃圾回收算法，垃圾回收分两部分：内存标记、清除（复制），标记部分只要内存大小固定时间是不变的，变的是复制部分，因为每次垃圾回收都有一些回收不掉的内存，所以增加了复制量，导致时间延长。
所以，垃圾回收的时间也可以作为判断内存泄漏的依据Q：为什么Full GC的次数越来越多？A：因此内存的积累，逐渐耗尽了年老代的内存，导致新对象分配没有更多的空间，从而导致频繁的垃圾回收Q：为什么年老代占用的内存越来越大？A：因为年轻代的内存无法被回收，越来越多地被Copy到年老代三、内存溢出的一些现象现象1、后台日志会报错- Out of Memory当Java程序申请内存，超出VM可分配内存的时候，ＶＭ首先可能会垃圾回收(ＧＣ)，如果ＧＣ完还是不够，或者申请的直接超够ＶＭ可能有的，就会抛出内存溢出异常。
从ＶＭ规范中我们可以得到，以下几种异常：ng.StackOverflowError:（很少）ng.OutOfMemoryError：heap space(比较常见)ng.OutOfMemoryError: PermGen space (经常出现)ng.OutOfMemoryError: GC overhead limit exceeded（某项操作使用大量内存时发生）现象2、通过loadrunner的windows监控图的部分指标走势能猜测是否发生内存泄漏。
使用MemoryAnalyzertoolMAT分析内存泄漏
使用Memory Analyzer tool(MAT)分析内存泄漏（一）前言在平时工作过程中，有时会遇到OutOfMemoryError，我们知道遇到Error一般表明程序存在着严重问题，可能是灾难性的。
所以找出是什么原因造成OutOfMemoryError非常重要。
现在向大家引荐Eclipse Memory Analyzer tool(MAT)，来化解我们遇到的难题。
如未说明，本文均使用Java 5.0 on Windows XP SP3环境。
为什么用MAT之前的观点，我认为使用实时profiling/monitoring之类的工具，用一种非常实时的方式来分析哪里存在内存泄漏是很正确的。
年初使用了某profiler工具测试消息中间件中存在的内存泄漏，发现在吞吐量很高的时候profiler工具自己也无法响应，这让人很头痛。
后来了解到这样的工具本身就要消耗性能，且在某些条件下还发现不了泄漏。
所以，分析离线数据就非常重要了，MAT正是这样一款工具。
为何会内存溢出我们知道JVM根据generation(代)来进行GC，根据下图所示，一共被分为young generation(年轻代)、tenured generation(老年代)、permanent generation(永久代, perm gen)，perm gen（或称Non-Heap 非堆）是个异类，稍后会讲到。
注意，heap空间不包括perm gen。
绝大多数的对象都在young generation被分配，也在young generation被收回，当young generation的空间被填满，GC会进行minor collection(次回收)，这次回收不涉及到heap中的其他generation，minor collection根据weak generational hypothesis(弱年代假设)来假设young generation中大量的对象都是垃圾需要回收，minor collection的过程会非常快。
使用Memory Analyzer tool(MAT)分析内存泄漏(二)
使用Memory Analyzer tool(MAT)分析内存泄漏（二）前言的前言写blog就是好，在大前提下可以想说什么写什么，不像投稿那么字字斟酌。
上周末回了趟成都办事，所以本文来迟了。
K117从达州经由达成线往成都方向走的时候，发现铁路边有条河，尽管我现在也不知道其名字，但已被其深深的陶醉。
河很宽且水流平缓，河边山丘森林密布，民房星星点点的分布在河边，河里偶尔些小船。
当时我就在想，在这里生活是多么的惬意，夏天还可以下去畅游一番，闲来无事也可垂钓。
唉，越来越讨厌北漂了。
前言在使用Memory Analyzer tool(MAT)分析内存泄漏（一）中，我介绍了内存泄漏的前因后果。
在本文中，将介绍MAT如何根据heap dump分析泄漏根源。
由于测试范例可能过于简单，很容易找出问题，但我期待借此举一反三。
一开始不得不说说ClassLoader，本质上，它的工作就是把磁盘上的类文件读入内存，然后调用ng.ClassLoader.defineClass方法告诉系统把内存镜像处理成合法的字节码。
Java 提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。
system class loader在没有指定装载器的情况下默认装载用户类，在Sun Java 1.5中既uncher$AppClassLoader。
更详细的内容请参看下面的资料。
准备heap dump请看下面的Pilot类，没啥特殊的。
/*** Pilot class* @author rosen jiang*/package org.rosenjiang.bo;public class Pilot{String name;int age;public Pilot(String a, int b){name = a;age = b;}}然后再看OOMHeapTest类，它是如何撑破heap dump的。
解决Tomcat应用的内存溢出问题-Tomcat-Java-JavaEye论坛
解决Tomcat应用的内存溢出问题-Tomcat-Java-JavaEye论坛维护一个老系统，发现有ng.OutOfMemoryError: Java heap space的情况，内存溢出，以下是大致的解决过程：1.安装JProfiler，并配置成监控本地的tomcat2.修改catalina.bat，添加参数： set JAVA_OPTS= -Xms768m -Xmx1024m -verbose:gc -Xloggc:../logs/gclog.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+HeapDumpOnOutOfMemoryError %JAVA_OPTS%3.使用JProfiler在Tomcat的bin目录下创建的启动脚本startup_jprofiler.bat重启tomcat4.运行JProfiler观察内存状况，未发现问题5.第二天突然发现T omcat再次出现内存溢出，Tomcat的bin目录下自动生成了java_pid107932.hprof文件，将此文件下载到本地，以便分析。
6.下载Memory Analyzer工具，然后打开该hprof文件进行分析，发现是SmartUpload的问题：com.jspsmart.upload.Files占用内存1G多。
7.用Apache的上传组件替换掉smartupload，目前没有发现问题附上Memory Analyzer分析的图片:Leak Suspects显示，有一个东西占了1007.9M的内存：点击底部的Details链接，发现是com.jspsmart.upload.Files占用内存最多：。
Tomcat内存溢出解决办法
Tomcat内存溢出解决办法使⽤Java程序从数据库中查询⼤量的数据时出现异常:ng.OutOfMemoryError: Java heap space在JVM中如果98％的时间是⽤于GC且可⽤的 Heap size 不⾜2％的时候将抛出此异常信息。
JVM堆的设置是指java程序运⾏过程中JVM可以调配使⽤的内存空间的设置.JVM在启动的时候会⾃动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最⼤空间(-Xmx)是物理内存的1/4。
可以利⽤JVM提供的-Xmn -Xms -Xmx等选项可进⾏设置。
解决办法：理⽅法是在myeclipse中设置TOMCAT的内存⼤⼩Tomcat是⽬前应⽤⼗分⼴泛的⼀个Java servlet container与web服务器，但ng.OutOfMemoryError与ng.OutOfMemoryError: PermGen space的异常相信真正⽤过tomcat的⼈都遇到过（⽤户量⼤，应⽤使⽤频繁等），这个异常和JVM默认划分的内存上限是128M有关，如果你的业务⾜够繁忙，128M是远远不够的，所以你可以给JVM分配上1G甚⾄更多，这样就可以避免内存溢出。
分配⽅法：1）linux下编辑tomcat的catalina.sh⽂件，在第⼀⾏的后⾯增加⼀句：JAVA_OPTS='-server -Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxPermSize=256M'注意：单引号不能少，-server表⽰以server模式运⾏(运⾏效率⽐默认的client⾼很多，⾃⼰云去测试)，-Xms256m是最⼩内存，-Xmx512m 是最⼤内存，其中的256与512可根据你⾃⼰的内存做相应调整，PermSize/MaxPermSize最⼩/最⼤堆⼤⼩.⼀般报内存不⾜时,都是说这个太⼩,堆空间剩余⼩于5%就会警告,建议把这个稍微设⼤⼀点,不过要视⾃⼰机器内存⼤⼩来设置,我⾃⼰的⽂件如下：#!/bin/shJAVA_OPTS='-server -Xms1024m -Xmx1024m XX:PermSize=128M -XX:MaxPermSize=256M'# -----------------------------2）windows下编辑tomcat的catalina.bat⽂件，在第⼀⾏的后⾯增加⼀句：set JAVA_OPTS=-server -Xms256m -Xmx512m -XX:PermSize=128M -XX:MaxPermSize=256M注意：没有单引号2.1）如果windows下tomcat被作为⼀种服务安装了，可通过tomcat monitor的java页进⾏配置注：Java Options中每⼀⾏的最后不能有空格。
memoryanalyzer 用法 -回复
memoryanalyzer 用法-回复MemoryAnalyzer（简称MAT）是一个Java堆转储文件分析工具，它提供了一种方式来检测和解决Java应用程序运行时的内存问题。
MAT 可以帮助我们找出内存泄漏、大对象占用、对象生命周期不当等问题，并提供了各种工具和功能来优化应用程序的内存使用。
本文将逐步介绍MemoryAnalyzer的用法，帮助读者更好地了解和使用这个强大的分析工具。
第一步：安装和启动MemoryAnalyzer首先，我们需要从Eclipse官网的MAT插件页面下载并安装MemoryAnalyzer插件。
安装成功后，在Eclipse的菜单栏中选择“Window”-> “Open Perspective”-> “Other”-> “Memory Analyzer”以切换到MemoryAnalyzer的透视图。
第二步：导入Java堆转储文件在MemoryAnalyzer的透视图中，我们可以通过点击工具栏中的“Open Heap Dump”按钮来导入Java堆转储文件。
选择已经生成的Java堆转储文件，点击“OK”按钮即可开始分析。
第三步：分析内存使用情况一旦Java堆转储文件导入成功，MemoryAnalyzer将显示一个面板，其中包含关于内存使用情况的各种信息。
首先，我们可以查看堆转储文件的总体概况，包括堆转储文件的大小、堆大小、垃圾回收器信息等。
在“Histogram”选项卡下，我们可以看到各个类的实例数和内存占用情况。
通过点击某个类，我们可以查看该类的实例列表，并对实例进行进一步的分析。
第四步：查找内存泄漏问题MemoryAnalyzer提供了一个强大的工具来检测内存泄漏问题，即“Leak Suspects”（内存泄漏嫌疑人）。
在MemoryAnalyzer的透视图中，点击工具栏中的“Leak Suspects”按钮，它将分析堆转储文件并生成一个内存泄漏报告。
memory analyzer tools 用法
memory analyzer tools 用法Memory Analyzer Tools (MAT) 是一款用于分析 Java 程序的内存使用情况的工具。
它基于 Eclipse 的 MAT 插件，可以帮助开发人员识别内存泄漏和性能问题。
以下是使用 Memory Analyzer Tools 的基本步骤：1. 下载和安装 Memory Analyzer Tools：从 Eclipse 的更新站点下载并安装 MAT 插件。
2. 配置 Java 应用程序以生成 heap dump 文件：在 Java 应用程序的启动参数中添加`-XX:+HeapDumpOnOutOfMemoryError`，这样当程序出现内存不足错误时，会自动生成一个 heap dump 文件。
3. 打开 Memory Analyzer Tools：在 Eclipse 中选择"Window" -> "Perspective" -> "Open Perspective" -> "Other"，然后选择"Memory Analysis"。
4. 导入 heap dump 文件：单击 MAT 工具栏中的"Open Heap Dump"按钮，然后选择要分析的 heap dump 文件。
5. 分析内存使用情况：在 MAT 工具栏中选择相关的分析工具，如 "Histogram"、"Dominator Tree"、"Leak Suspects" 等，来查看对象的数量、占用内存的大小、对象之间的引用关系等。
6. 识别内存泄漏：使用 MAT 的 "Leak Suspects" 工具来识别可能的内存泄漏。
它会列出潜在的泄漏路径和泄漏对象，并提供详细的分析和推荐解决方案。
如何处理高压运维中的内存溢出问题
如何处理高压运维中的内存溢出问题在高压运维中，内存溢出问题是一种常见但令人头疼的状况。
内存溢出发生时，应用程序试图分配比系统可用内存更多的内存，导致程序崩溃或运行缓慢。
本文将介绍如何处理高压运维中的内存溢出问题，并提供一些实用的解决方法。
一、监控和分析内存溢出问题往往是程序在高负载情况下发生的，因此首先要做的是监控和分析。
通过监控系统的内存使用情况，可以及时发现内存溢出的问题，并采取措施进行处理。
可以利用各种监控工具，如Zabbix、Nagios等，来实时监控系统的内存利用率和内存使用情况。
此外，还可以使用性能分析工具，如Java VisualVM、Eclipse Memory Analyzer 等，来分析内存使用情况，找出导致内存溢出的原因。
二、调整JVM参数JVM是Java应用程序的运行环境，通过调整JVM参数可以有效地解决内存溢出问题。
首先，可以通过增加堆内存的大小来解决内存溢出问题。
可以使用-Xmx和-Xms参数设置Java堆的最大和初始大小，以提供更多的内存给应用程序使用。
其次，可以通过调整新生代和老年代的比例来优化内存分配。
可以使用-XX:NewSize和-XX:MaxNewSize参数调整新生代的大小，使用-XX:PermSize和-XX:MaxPermSize参数调整永久代的大小。
此外，还可以通过调整垃圾收集器的类型和参数来提高内存的利用率和回收效率。
三、优化代码代码的质量和效率对于解决内存溢出问题至关重要。
通过优化代码，可以减少内存的占用，提高程序的性能和稳定性。
首先，可以检查代码中的内存泄漏问题。
内存泄漏是指已经分配的内存无法释放，导致内存占用逐渐增加，最终导致内存溢出。
可以使用内存分析工具来检测和修复内存泄漏问题。
其次，可以优化数据结构和算法，减少内存的使用。
例如，可以使用ArrayList代替LinkedList，使用HashMap代替TreeMap等。
此外，还可以优化数据库查询、避免重复计算等，以降低内存的开销。
Eclipse Memory Analyzer是一个非常棒的堆内存分析工具
Eclipse Memory Analyzer是一个非常棒的堆内存分析工具Eclipse Memory Analyzer是一个非常棒的堆内存分析工具，是JDK自带的堆分析工具jhat的一个非常好的替代品，能够快速地定位Java内存泄露的原因。
可能有的同学会问，JVM不是号称自动内存管理，GC会自动垃圾回收，Java 怎么会有内存泄露，不会搞错吧？当然不会^_^， Java的内存泄露不同于C/C++的内存泄露，C/C++的内存泄露是由于使用了堆内存(new/malloc)却没有释放(delete /free)，导致无法再使用到该内存片，而Java的内存泄露是无谓地引用了一些垃圾的对象，譬如我们有一个Map对象，不断往里面放对象，实际的场景可能是这些对象不会再被使用到，这时候，这部分数据本身是垃圾的（因为不会再被使用），但实际上JVM会不会释放它（因为还被Map）引用着，这就是 Java的内存泄露。
在开始分析之前，我们先想想，在编程这个角度上，我们如何避免堆内存泄露呢？实际上ng.ref这个包已经为我们提供了一种问题解决方案。
Java的引用有4种：强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、幻影引用(Phantom Reference)，关于这部分介绍的文章一大批，此处就不做深入，我们只需要知道如下的信息：强引用：除非将引用置为null，否则JVM不会对它垃圾，这是最常用的引用方式软引用：在堆内存不足的时候，GC会将其垃圾回收弱引用：每次GC都会将其垃圾回收幻影引用：跟没有引用一样，每次获得的都是空的，没有太多使用的意义，仅是为了追踪对象在JVM的状态一般对于大数据量的Cache信息或大对象，使用软引用/弱引用是一种非常好的习惯，或者至少使用一种淘汰算法，避免在堆内存拥挤大量的对象导致内存不足，如下是两个非常好的JDK默认提供的HashMap替代者：mons.collections.map.ReferenceMap：支持强引用/软引用和弱引用来存储key/value对mons.collections.map.LRUMap：可以控制总容量，采用LRU淘汰算法，将不常使用的数据淘汰出去介绍完一些背景，我们开始进入主题。
EclipseMemoryAnalyzer的使用教程最实用
EclipseMemoryAnalyzer的使⽤教程最实⽤原⽂出处：郭霖，Eclipse Memory Analyzer（MAT）是⼀款内存分析⼯具，这个⼯具分为Eclipse插件版和独⽴版两种，如果你是使⽤Eclipse开发的，那么可以使⽤插件版MAT，⾮常⽅便。
如果你是使⽤Android Studio开发的，那么就只能使⽤独⽴版的MAT了下载好了之后下⾯我们开始学习如何去分析内存泄露的原因，⾸先还是进⼊到DDMS界⾯，然后在左侧⾯板选中我们要观察的应⽤程序进程，接着点击Dump HPROF file按钮，如下图所⽰：点击这个按钮之后需要等待⼀段时间，然后会⽣成⼀个HPROF⽂件，这个⽂件记录着我们应⽤程序内部的所有数据。
但是⽬前MAT还是⽆法打开这个⽂件的，我们还需要将这个HPROF⽂件从Dalvik格式转换成J2SE格式，使⽤hprof-conv命令就可以完成转换⼯作，如下所⽰：hprof-conv dump.hprof converted-dump.hprof1hprof-conv命令⽂件存放于/platform-tools⽬录下⾯。
另外如果你是使⽤的插件版的MAT，也可以直接在Eclipse中打开⽣成的HPROF⽂件，不⽤经过格式转换这⼀步。
好的，接下来我们就可以来尝试使⽤MAT⼯具去分析内存泄漏的原因了，这⾥需要提醒⼤家的是，MAT并不会准确地告诉我们哪⾥发⽣了内存泄漏，⽽是会提供⼀⼤堆的数据和线索，我们需要⾃⼰去分析这些数据来去判断到底是不是真的发⽣了内存泄漏。
那么现在运⾏MAT⼯具，然后选择打开转换过后的converted-dump.hprof⽂件，如下图所⽰：MAT中提供了⾮常多的功能，这⾥我们只要学习⼏个最常⽤的就可以了。
上图最中央的那个饼状图展⽰了最⼤的⼏个对象所占内存的⽐例，这张图中提供的内容并不多，我们可以忽略它。
在这个饼状图的下⽅就有⼏个⾮常有⽤的⼯具了，我们来学习⼀下。
使用Memory Analyzer tool(MAT)分析内存泄漏(二)
使用Memory Analyzer tool(MAT)分析内存泄漏（二）前言的前言写blog就是好，在大前提下可以想说什么写什么，不像投稿那么字字斟酌。
上周末回了趟成都办事，所以本文来迟了。
K117从达州经由达成线往成都方向走的时候，发现铁路边有条河，尽管我现在也不知道其名字，但已被其深深的陶醉。
河很宽且水流平缓，河边山丘森林密布，民房星星点点的分布在河边，河里偶尔些小船。
当时我就在想，在这里生活是多么的惬意，夏天还可以下去畅游一番，闲来无事也可垂钓。
唉，越来越讨厌北漂了。
前言在使用Memory Analyzer tool(MAT)分析内存泄漏（一）中，我介绍了内存泄漏的前因后果。
在本文中，将介绍MAT如何根据heap dump分析泄漏根源。
由于测试范例可能过于简单，很容易找出问题，但我期待借此举一反三。
一开始不得不说说ClassLoader，本质上，它的工作就是把磁盘上的类文件读入内存，然后调用ng.ClassLoader.defineClass方法告诉系统把内存镜像处理成合法的字节码。
Java 提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。
system class loader在没有指定装载器的情况下默认装载用户类，在Sun Java 1.5中既uncher$AppClassLoader。
更详细的内容请参看下面的资料。
准备heap dump请看下面的Pilot类，没啥特殊的。
/*** Pilot class* @author rosen jiang*/package org.rosenjiang.bo;public class Pilot{String name;int age;public Pilot(String a, int b){name = a;age = b;}}然后再看OOMHeapTest类，它是如何撑破heap dump的。
mat工具MemoryAnalyzer进行分析java内存溢出hprof文件
mat⼯具MemoryAnalyzer进⾏分析java内存溢出hprof⽂件java服务端程序报错后会⽣成hprof⽂件，我们可以通过mat⼯具MemoryAnalyzer进⾏分析下载地址：/mat/downloads.php说明：查看HPROF快照 JProfiler能打开⽤JVM⼯具（⽐如jconsole、 jmap或通过-XX:+HeapDumpOnOutOfMemoryError JVM参数触发）创建的HPROF快照⽂件⽰例：#!/bin/bashLANG="zh_CN.UTF-8"APP_HOME=$(echo `pwd` | sed 's/bin//')APPPIDFILE=$APP_HOME/app.pidcase $1 instart)echo "Starting server... "HEAP_MEMORY=512mPERM_MEMORY=64mJMX_PORT=8888JMX_HOST=1.1.1.1JAVA_OPTS="-server -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider -XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false " shiftARGS=($*)for ((i=0; i<${#ARGS[@]}; i++)); docase "${ARGS[$i]}" in-D*) JAVA_OPTS="${JAVA_OPTS} ${ARGS[$i]}" ;;-Heap*) HEAP_MEMORY="${ARGS[$i+1]}" ;;-Perm*) PERM_MEMORY="${ARGS[$i+1]}" ;;-JmxPort*) JMX_PORT="${ARGS[$i+1]}" ;;-JmxHost*) JMX_HOST = "${ARGS[$i+1]}" ;;esacdoneJAVA_OPTS="${JAVA_OPTS} -Xms${HEAP_MEMORY} -Xmx${HEAP_MEMORY} -XX:PermSize=${PERM_MEMORY} -XX:MaxPermSize=${PERM_MEMORY} -Dcom.sun.management.jmxremote.port=${JMX_PORT} -Djava.rmi.server.host echo "start jvm args ${JAVA_OPTS}"nohup java -classpath .:./aa-media-2.0.0.jar:$CLASSPATH $JAVA_OPTS com.aaa.media.aaaMediaServer&echo $! > $APPPIDFILEecho STARTED;;stop)echo "Stopping server ... "if [ ! -f $APPPIDFILE ]thenecho "error: count not find file $APPPIDFILE"exit 1elsekill -15 $(cat $APPPIDFILE)rm $APPPIDFILEecho STOPPEDfi;;*)echo "Please enter start|stop ... ";;esacexit 0。
检测内存溢出的方法
检测内存溢出的方法
内存溢出是一种常见的程序错误，它通常发生在程序运行过程中，当程序试图分配超过其可用内存容量的对象时。
这种错误会导致程序崩溃或异常终止，严重影响程序的功能和稳定性。
为了避免这种错误的发生，我们需要及时检测和解决内存溢出问题。
以下是一些常用的检测内存溢出的方法：
1. 监控内存使用情况
通过监控程序的内存使用情况，及时发现内存泄漏或使用过度的情况。
可以使用系统工具或第三方工具来监控内存使用情况，例如Linux下的top、htop命令或者Java VisualVM等工具。
2. 执行代码分析
通过执行代码分析工具，可以检测出代码中存在的内存泄漏等问题。
常用的代码分析工具有Valgrind、Eclipse Memory Analyzer等。
3. 进行压力测试
通过模拟实际运行环境下的高负载情况，检测程序在压力下是否会发生内存溢出等错误。
可以使用JMeter等工具进行压力测试。
4. 使用断言
在程序中加入断言语句，判断内存分配是否成功，避免程序在分配内存失败时继续运行而导致崩溃。
总之，内存溢出是一个非常棘手的问题，需要我们及时发现和修复。
以上提到的方法只是其中一部分，更多的解决方法需要我们在实际开发中积累和总结。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
前言
在平时开发、测试过程中、甚至是生产环境中，有时会遇到OutOfMemoryError，Java堆溢出了，这表明程序有严重的问题。
我们需要找造成OutOfMemoryError原因。
一般有两种情况：
1、内存泄露，对象已经死了，无法通过垃圾收集器进行自动回收，通过找出泄露的代码位置和原因，才好确定解决方案；
2、内存溢出，内存中的对象都还必须存活着，这说明Java堆分配空间不足，检查堆设置大小（-Xmx与-Xms），检查代码是否存在对象生命周期太长、持有状态时间过长的情况。
以上是处理Java堆问题的思路，具体是怎么进行分析，这里介绍的是使用Eclipse Memory Analyzer tool(MAT)工具分析的过程。
生成dump文件
通过jvm参数--XX:-HeapDumpOnOutOfMemoryError可以让JVM在出现内存溢出是Dump出当前的内存转储快照；
或者，用jmap生产dump文件，win通过任务管理器查看tomcat的进程pid，linux用ps命令查看进程pid,然后用jmap命令（Java5：jmap -heap:format=b <pid>；Java6：jmap -dump:format=b,file= <pid>）。
我这里使用的是，我一生产环境项目，运行一段时间大概3周的样子，就会报OutOfMemoryError。
（ps：这个项目出现这种情况已经有好长一段时间了，我们之前的做法是定期的重启tomcat，没有去分析它的原因。
）JDK64位主要参数：
-Xmx3078M -Xms3078M -XX:PermSize=1024M -XX:MaxPermSize=1024M，内存还是蛮大的。
MAT安装与介绍
下载地址：。
通过MAT打开dump出来的内存文件，打开后如下图：
从上图可以看到它的大部分功能。
1. Histogram可以列出内存中的对象，对象的个数以及大小。
2. Dominator Tree可以列出那个线程，以及线程下面的那些对象占用的空间。
consumers通过图形列出最大的object。
Suspects通过MA自动分析泄漏的原因。
Histogram如下图：
Objects:类的对象的数量。
Shallow size：就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。
Retained size：是该对象自己的shallow size，加上从该对象能直接或间接访问到对象的shallow size之和。
换句话说，retained size是该对象被GC之后所能回收到内存的总和。
我们发现ThreadLocal和类的对象占用了很多空间。
Dominator Tree如下图：
我们发现quartz的定时器的工作线程（10个）占了很多的内存空间
Top consumers如下图：
这里显示了内存中最大的对象有哪些，他们对应的类是哪些，类加载器classloader是哪些。
有些时候，我们在这里就可以看到代码泄露的位置。
Leak Suspects如下图：
从那个饼图，该图深色区域被怀疑有内存泄漏，可以发现整个heap才250M内存，深色区域就占了34%。
后面的描述，告诉我们quartz线程占用了大量内存，并指出system class loader加载的""实例的内存中聚集（消耗空间），并建议用关键字""进行检查。
所以，MAT通过简单的报告就说明了问题所在。
通过Leak Suspects的Problem Suspect 1点击【Details »】，
如下图如下图所示的上下文菜单中选择 List objects -> with outgoning references, 查看ThreadLocal都应用了些什么对象。
现在看到ThreadLocal中引用的对象如下图：
是dao对象
ps：该dao对象包含一个轻量级的ORM关系内容，所以Retained size比较大。
下面继续查看dao的gc ROOT
如下图所示的上下文菜单中选择 Path To GC Roots -> exclude weak references, 过滤掉弱引用，因为在这里弱引用不是引起问题的关键。
从下图中，可以看到在中保存了daos的引用。
所以可以得出是是因为定时器在运行的过程中持有大量的Daos对象应起了内存泄露。
为什么会有那么多的Daos呢,Daos不是一个无状态的单例的、可以重用的吗？继续查看spring配置文件发现Daos的bean 配置成scope="prototype"，导致定时任务又是每次调用都生产新的Daos实例。
由于是Daos是无状态的，修改为单例的，问题解决。
以上是通过MAT分析Tomcat应用程序，找到内存泄露的原因，并解决。