内存溢出OOM

1, OutOfMemoryError异常

除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能,

javaHeap 溢出

一般的异常信息:java.lang.OutOfMemoryError:Java heap spacess

java堆用于存储对象实例,我们只要不断的创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,就会在对象数量达到最大堆容量限制后产生内存溢出异常。

出现这种异常,一般手段是先通过内存映像分析工具(如Eclipse Memory Analyzer)对dump出来的堆转存快照进行分析,重点是确认内存中的对象是否是必要的,先分清是因为内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。

如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。

如果不存在泄漏,那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。

2, 虚拟机栈和本地方法栈溢出

如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常。

如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常

这里需要注意当栈的大小越大可分配的线程数就越少

3, 运行时常量池溢出

异常信息:java.lang.OutOfMemoryError:PermGen space

如果要向运行时常量池中添加内容,最简单的做法就是使用String.intern()这个Native方法。该方法的作用是:如果池中已经包含一个等于此String的字符串,则返回代表池中这个字符串的String对象;否则,将此String对象包含的字符串添加到常量池中,并且返回此String对象的引用。由于常量池分配在方法区内,我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小,从而间接限制其中常量池的容量。

4, 方法区溢出

方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。

异常信息:java.lang.OutOfMemoryError:PermGen space

方法区溢出也是一种常见的内存溢出异常,一个类如果要被垃圾收集器回收,判定条件是很苛刻的。在经常动态生成大量Class的应用中,要特别注意这点。

【情况一】: 
  Java.lang.OutOfMemoryError: Javaheap space:这种是java堆内存不够,一个原因是真不够,另一个原因是程序中有死循环; 
  如果是java堆内存不够的话,可以通过调整JVM下面的配置来解决: 
  < jvm-arg>-Xms3062m < / jvm-arg> 
  < jvm-arg>-Xmx3062m < / jvm-arg> 
   
【情况二】 
  java.lang.OutOfMemoryError: GC overhead limit exceeded 
  【解释】:JDK6新增错误类型,当GC为释放很小空间占用大量时间时抛出;一般是因为堆太小,导致异常的原因,没有足够的内存。 
  【解决方案】: 
  1、查看系统是否有使用大内存的代码或死循环; 
  2、通过添加JVM配置,来限制使用内存: 
  < jvm-arg>-XX:-UseGCOverheadLimit< /jvm-arg> 
   
【情况三】: 
  java.lang.OutOfMemoryError: PermGen space:这种是P区内存不够,可通过调整JVM的配置: 
  < jvm-arg>-XX:MaxPermSize=128m< /jvm-arg> 
  < jvm-arg>-XXermSize=128m< /jvm-arg> 
  【注】: 
  JVM的Perm区主要用于存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space,这个区域成为年老代,GC在主程序运行期间不会对年老区进行清理,默认是64M大小,当程序需要加载的对象比较多时,超过64M就会报这部分内存溢出了,需要加大内存分配,一般128m足够。 
   
【情况四】: 
  java.lang.OutOfMemoryError: Direct buffer memory 
  调整-XX:MaxDirectMemorySize= 参数,如添加JVM配置: 
  < jvm-arg>-XX:MaxDirectMemorySize=128m< /jvm-arg> 
   
【情况五】: 
  java.lang.OutOfMemoryError: unable to create new native thread 
  【原因】:Stack空间不足以创建额外的线程,要么是创建的线程过多,要么是Stack空间确实小了。 
  【解决】:由于JVM没有提供参数设置总的stack空间大小,但可以设置单个线程栈的大小;而系统的用户空间一共是3G,除了Text/Data/BSS /MemoryMapping几个段之外,Heap和Stack空间的总量有限,是此消彼长的。因此遇到这个错误,可以通过两个途径解决: 
  1.通过 -Xss启动参数减少单个线程栈大小,这样便能开更多线程(当然不能太小,太小会出现StackOverflowError); 
  2.通过-Xms -Xmx 两参数减少Heap大小,将内存让给Stack(前提是保证Heap空间够用)。 
   
【情况六】: 
  java.lang.StackOverflowError 
  【原因】:这也内存溢出错误的一种,即线程栈的溢出,要么是方法调用层次过多(比如存在无限递归调用),要么是线程栈太小。 
  【解决】:优化程序设计,减少方法调用层次;调整-Xss参数增加线程栈大小。

时间: 2024-10-23 22:56:23

内存溢出OOM的相关文章

内存溢出(Oom)和内存泄露(Memory leak)

内存溢出(Oom):运行内存大于可用内存的情况.比如申请了一个integer空间,结果存放下了只有long才能存放的数据 内存泄露(Memory leak):程序员忘记释放已用内存的情况,是内存管理较为常见的现象 以发生的方式来分类,内存泄漏可以分为4类: 1. 常发性内存泄漏.发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏. 2. 偶发性内存泄漏.发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生.常发性和偶发性是相对的.对于特定的环境,偶发性的也许就变成了常发性

java常见内存溢出(OOM)

jvm内存区域 程序计数器一块很小的内存空间,作用是当前线程所执行的字节码的行号指示器. java栈与程序计数器一样,java栈(虚拟机栈)也是线程私有的,其生命周期与线程相同.通常存放基本数据类型,对象引用(一个指向对象起始地址的引用指针或一个代表对象的句柄),reeturnAddress类型(指向一条字节码指令的地址) 栈区域有两种异常类型:如果线程请求的栈深度大于虚拟机所允许的深度,将抛StrackOverflowError异常:如果虚拟机栈可以动态扩展(大部分虚拟机都可动态扩展),当扩展

bitmap 内存溢出OOM的解决办法分享

昨天遇到这个问题就是从一个输入流里调用BitmapFactory.decodeStream(this.getContentResolver().openInputStream(uri))得到一个bitmap报的错.第一次调用都没问题,第二次再次调用就会报上面那个内存溢出的问题.而且有的手机报有的手机不报.研究了半天终于解决.首先分析了下原因,应该是图片占用的内存超过了系统虚拟机可分配的最大限制.不同手机可能分配的最大值不一样.后来找到解决办法主要是设置BitmapFactory.Options.

android 内存溢出OOM问题

好久没有进cnblogs了,都快长草了.之前对接某度要求我司的插件 monkey test满8小时无OOM 无crash 虐哭了...各种OOM 下面把当时写的一篇笔记po上来防止长草. 1.什么是OOM,为什么会有OOM Android主要应用在嵌入式设备中,所以因为嵌入式设备本身的一些限制,通常内存都会比较有限.JAVA拥有自己的一套垃圾回收机制,但并不是说用java编写的程序就不会程序溢出.java运行在虚拟机中,虚拟机在初始化时会给它的对内存(Heap)设置一个上限值,android中这

viewPager--viewpager时,发生内存溢出OOM问题

两个问题:1.如果图片达到500kb每张,你这个划屏会有顿卡:2.快速滑动有出现0.几秒的白屏.图片越大,顿卡越明显. 回复parcool:500kb的背景算大的了,如果是想做图片墙,viewpager不适合,可以使用开源的图片墙工具,内存+硬盘缓存 还有哦,你这个图片根本没有手动回收,依然会OOM! 今天在制作应用某个功能的引导页时,使用了ViewPager进行页面切换,每个页面就放了一个ImageView,使用背景图来进行展示,由于多图(11张)的原因,导致了OOM问题,这里总结一下. 代码

防止.NET应用程序内存溢出(OOM)的一些措施

批量和分页 在典型的互联网web应用中,数据量较大且高并发的情况下,不分页,或者不进行批量处理,每次总是取出很多用户数据,很容易造成内存开销过大,系统内存吃紧.再比如我们有时候进行文件操作,读取文件内容的时候就要斟酌考虑文件有多大. 慎用静态 比起大数据查询造成的常发性的内存不足,使用静态太多的应用程序一时半会也不会内存泄露.可随着系统的运行,静态的东西越来越多,内存开销也就越大,由于GC的回收策略,无效的静态所占内存又不容易及时释放,久而久之就造成了内存不足. 二方库.三方库,非托管资源,优先

android图片加载内存优化方法,有效解决大图片内存溢出(oom)

低内存的手机如果直接加载大图片,往往会出现OOM的情况.即便是主流手机,也不能无限制的加载大图片.所以在显示图片之前,需要对图片处理,把图片缩放为最合适的尺寸再显示. 网上很大方法都是不管三七二十一,直接压缩图片.这样可能会导致图片失真,显示模糊.我采用的方式是,显示尺寸有多大,就等比例压缩成多大尺寸的图片,关键关于在于如何寻找最合适的尺寸,下面分享两个关键方法,提取至google开源框架volley private static int getResizedDimension(int maxP

使用ViewPager时,发生内存溢出OOM问题

今天在制作应用某个功能的引导页时,使用了ViewPager进行页面切换,每个页面就放了一个ImageView,使用背景图来进行展示,由于多图(11张)的原因,导致了OOM问题,这里总结一下. 代码如下: public class GuideActivity extends Activity implements OnPageChangeListener{ private ViewPager viewPager; private GuideAdapter adapter; private Line

13.缓存、三级缓存、内存溢出、AsyncTask

SharePreference工具类 /** * SharePreference封装 * */ public class PrefUtils { public static final String PREF_NAME = "config"; public static boolean getBoolean(Context ctx, String key, boolean defaultValue) { SharedPreferences sp = ctx.getSharedPrefe