浅析Java OutOfMemoryError 淩亂°似流年 2022-05-31 09:00 131阅读 0赞 在日常中我们经常遇到这样的错误:java.lang.OutOfMemoryError: Java heap space。 但是除了heap space 的OutOfMemoryError,还有其它几种OutOfMemoryError情况。今天我们就来了解一下: -------------------- ### 1、java.lang.OutOfMemoryError: Java heap space。 ### 这是因为虚拟机堆的空间所剩不多。当准备创建的对象需要的内存已经超过虚拟机堆所剩的空间。虚拟机会尝试通过full GC来回收内存,如果不行的话,就会抛出OutOfMemoryError。 导致OutOfMemoryError异常的常见原因有以下几种: 内存中加载的数据量过于庞大,如一次性从DB取出过多数据; 集合类中有对象的引用,使用完后未清空,使得JVM不能回收; 代码中存在死循环或循环产生过多重复的对象实体; 启动参数内存值设定的过小。 举一个常见的OutOfMemoryError场景:先从DB读取数据存放到内存中,然后遍历处理。 public class HeapSpaceOutOfMemory { private static List<byte[]> getDataFromDb() { List<byte[]> list = new ArrayList<>(); for (int i = 0; i < 500; i++) { byte[] data = new byte[1024 * 1024];// 1M的对象 list.add(data); } return list; } public static void main(String[] args) { // 1、从db取数据,大小为500M List<byte[]> list = getDataFromDb(); // 2、遍历处理list for (byte[] data : list) { //do something } System.out.println("success"); } } JVM参数: -Xms64M -Xmx128M -XX:+PrintGCDetails -Xloggc:/apps/logs/heap\_demo.log ![image.png][] 运行结果: ![image.png][image.png 1] 查看GC Log,可以看到有Full GC 的痕迹,但是Full GC的收效果不明显,年轻代和年老代都没有足够的空间为即将创建的对象分配空间。 ![image.png][image.png 2] 解决OOM最快的方法就是调整-Xmx参数,增加堆的大小。 调整JVM参数: -Xms64M -Xmx1024M -XX:+PrintGCDetails -Xloggc:/apps/logs/heap\_demo.log ![image.png][image.png 3] ![image.png][image.png 4] 虽然通过调整-Xmx参数解决了上面OutOfMemoryError的问题,但是如果DB的数据突然暴涨到5G、50G、500G的时候,还是会出现OutOfMemoryError。此时通过调整-Xmx参数就不合适了,先不说机器有没有这么大的内存分配,就算机器的内存够分配,Full GC导致程序停顿的时间也会很长。因此我们要从代码下手,分批次处理数据,“小步快跑”,将5G的数据拆分成10个批次,50G的数据拆分成100个批次,500G的数据拆分成1000个批次,每个批次处理500M的数据,一个批次处理完后内存回收。这样的话就不用再担心突然暴涨的数据量导致程序OutOfMemoryError。 ### 2、java.lang.OutOfMemoryError: Metaspace ### JDK1.7中,存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap,譬如符号引用(Symbols)转移到了native heap;字面量(interned strings)转移到了java heap;类的静态变量(class statics)转移到了java heap。但永久代仍存在于JDK1.7中,并没完全移除。 JDK 8.HotSpot JVM使用本地化的内存存放类的元数据,这个空间叫做元空间(Metaspace)。官方定义:”In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace”。元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于:元空间并不在虚拟机中,而是使用本地内存。因此,默认情况下,元空间的大小仅受本地内存限制,但可以通过以下参数来指定元空间的大小:-XX:MetaspaceSize、-XX:MaxMetaspaceSize。 测试代码: public class MetaspaceOutOfMemory { public static void main(String[] args) throws Exception { ClassPool cp = ClassPool.getDefault(); for (int i = 0;; i++) { cp.makeClass("com.demo.MetaspaceClass" + i).toClass(); Thread.sleep(1); } } } JVM参数:-XX:MetaspaceSize=32m -XX:MaxMetaspaceSize=64m -Xloggc:/apps/logs/heap\_demo.log 打开VisualVm工具,可以发现Metaspace使用的空间大小随类装入的数量增加而增加,这也说明了Metaspace是用来存放类的元数据的。 ![image.png][image.png 5] ![image.png][image.png 6] ![image.png][image.png 7] ### 3、java.lang.OutOfMemoryError: PermGen space ### 修改JVM参数为:-XX:PermSize=32M -XX:MaxPermSize=64M -Xloggc:/apps/logs/heap\_demo.log,切换到JDK7下运行MetaspaceOutOfMemory。打开VisualVm工具,此时出现了PermGen标签页。随着类装载的数量增加,最终出现了java.lang.OutOfMemoryError: PermGen space,进程退出。 ![image.png][image.png 8] ![image.png][image.png 9] ![image.png][image.png 10] ### 4、java.lang.OutOfMemoryError: GC overhead limit exceeded ### GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略,通过统计GC时间来预测是否要OOM了,提前抛出异常。官方定义是:“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是,超过98%的时间用来做GC并且回收了不到2%的堆内存”。JVM默认启动的时候-XX:+UseGCOverheadLimit,即启用了该特性。 测试程序: public class GCOverheadLimit { public static void main(String[] args) { List list = new ArrayList(); String str = "1"; for (int i = 0; i < 1000000; i++) { for (int j = 0; j < 100; j++) { str += "$" + i; } list.add(str); } } } JVM参数:-Xms64M -Xmx128M -XX:+UseGCOverheadLimit 运行结果: ![image.png][image.png 11] 最近项目有一个程序,因为频繁Full GC导致程序僵死现象,一致耗着,如果加上-XX:+UseGCOverheadLimit参数就可以让程序提前退出,避免僵死程序长期占用资源。 ### 5、java.lang.OutOfMemoryError: unable to create new native thread ### 如果JVM正在请求操作系统创建一个本地线程,而操作系统无法创建的时候,就会出现这个报错信息。JVM中可以生成的最大线程数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大可创建的线程数量(Java线程的实现是基于底层系统的线程机制来实现的,Windows下\_beginthreadex,Linux下pthread\_create)三个方面影响。 ### 6、java.lang.OutOfMemoryError: Requested array size exceeds VM limit ### 当你正准备创建一个超过虚拟机允许的大小的数组时,这条错误就会出现在你眼前。64位的操作系统上,JDK7,如果数组的长度是Integer.MAX\_VALUE-1,就会出现。 byte a[] = new byte[Integer.MAX_VALUE-1]; ### 7、java.lang.OutOfMemoryError: request bytes for . Out of swap space? ### 这个错误是当虚拟机向本地操作系统申请内存失败时抛出的。这和你用完了堆或者持久化中的内存的情况有些不同。这个错误通常是在你的程序已经逼近平台限制的时候产生的。这个信息告诉你的是你可能已经用光了物理内存以及虚拟内存了。由于虚拟内存通常是用磁盘作为交换分区,因此你最先想到的解决方法可能是先增加交换分区的大小。不过我从没见过一个程序在频繁进行内存交换还能正常运行的,所以这个方法可能不会起到什么作用。 [image.png]: /images/20220531/1f76783f999045da9486af45876b0c01.png [image.png 1]: /images/20220531/7d01ee8f3bb240b4b251e6ecac906b07.png [image.png 2]: /images/20220531/4e956cc4a0354f1997c8d5001b48c33a.png [image.png 3]: /images/20220531/33d7737cc7f44a1babf6e154a43592f5.png [image.png 4]: /images/20220531/d258d7af669e4ee9a1a8909b5e60a11f.png [image.png 5]: /images/20220531/07d1fe0f26b14a709009290821e5ef7b.png [image.png 6]: /images/20220531/0b1388b213a245c7bd984f69f13c20b2.png [image.png 7]: /images/20220531/9031a253102140d284a48cd8178ebfaa.png [image.png 8]: /images/20220531/acb7c5a0720c44f7bbdc32143b8f5a5e.png [image.png 9]: /images/20220531/9a853a325609401bab5ca436c630e4df.png [image.png 10]: /images/20220531/4fc4f31c1ce543deb58f8bb128bf35ce.png [image.png 11]: /images/20220531/e19cb18a3f2f461f9507b026906e4311.png
还没有评论,来说两句吧...