Java内存溢出(OOM)异常完全指南3

来源:互联网 发布:sql拒绝访问 编辑:程序博客网 时间:2024/05/19 23:59

java.lang.OutOfMemoryError:Unable to create new native thread

一个思考线程的方法是将线程看着是执行任务的工人,如果你只有一个工人,那么他同时只能执行一项任务,但如果你有十几个工人,就可以同时完成你几个任务。就像这些工人都在物理世界,JVM中的线程完成自己的工作也是需要一些空间的,当有足够多的线程却没有那么多的空间时就会像这样:


图片来源:Plumbr

出现java.lang.OutOfMemoryError:Unable to create new native thread就意味着Java应用程序已达到其可以启动线程数量的极限了。

原因分析

当JVM向OS请求创建一个新线程时,而OS却无法创建新的native线程时就会抛出Unable to create new native thread错误。一台服务器可以创建的线程数依赖于物理配置和平台,建议运行下文中的示例代码来测试找出这些限制。总体上来说,抛出此错误会经过以下几个阶段:

  • 运行在JVM内的应用程序请求创建一个新的线程

  • JVM向OS请求创建一个新的native线程

  • OS尝试创建一个新的native线程,这时需要分配内存给新的线程

  • OS拒绝分配内存给线程,因为32位Java进程已经耗尽内存地址空间(2-4GB内存地址已被命中)或者OS的虚拟内存已经完全耗尽

  • Unable to create new native thread错误将被抛出

示例

下面的示例不能的创建并启动新的线程。当代码运行时,很快达到OS的线程数限制,并抛出Unable to create new native thread错误。

while(true){    new Thread(new Runnable(){        public void run() {            try {                Thread.sleep(10000000);            } catch(InterruptedException e) { }                }        }).start();}

解决方案

有时,你可以通过在OS级别增加线程数限制来绕过这个错误。如果你限制了JVM可在用户空间创建的线程数,那么你可以检查并增加这个限制:

// macOS 10.12上执行$ ulimit -u709

当你的应用程序产生成千上万的线程,并抛出此异常,表示你的程序已经出现了很严重的编程错误,我不觉得应该通过修改参数来解决这个问题,不管是OS级别的参数还是JVM启动参数。更可取的办法是分析你的应用是否真的需要创建如此多的线程来完成任务?是否可以使用线程池或者说线程池的数量是否合适?是否可以更合理的拆分业务来实现.....

6、java.lang.OutOfMemoryError:Out of swap space?

Java应用程序在启动时会指定所需要的内存大小,可以通过-Xmx和其他类似的启动参数来指定。在JVM请求的总内存大于可用物理内存的情况下,操作系统会将内存中的数据交换到磁盘上去。


图片来源:plumbr

Out of swap space?表示交换空间也将耗尽,并且由于缺少物理内存和交换空间,再次尝试分配内存也将失败。

原因分析

当应用程序向JVM native heap请求分配内存失败并且native heap也即将耗尽时,JVM会抛出Out of swap space错误。该错误消息中包含分配失败的大小(以字节为单位)和请求失败的原因。

Native Heap Memory是JVM内部使用的Memory,这部分的Memory可以通过JDK提供的JNI的方式去访问,这部分Memory效率很高,但是管理需要自己去做,如果没有把握最好不要使用,以防出现内存泄露问题。JVM 使用Native Heap Memory用来优化代码载入(JTI代码生成),临时对象空间申请,以及JVM内部的一些操作。

这个问题往往发生在Java进程已经开始交换的情况下,现代的GC算法已经做得足够好了,当时当面临由于交换引起的延迟问题时,GC暂停的时间往往会让大多数应用程序不能容忍。

java.lang.OutOfMemoryError:Out of swap space?往往是由操作系统级别的问题引起的,例如:

  • 操作系统配置的交换空间不足。

  • 系统上的另一个进程消耗所有内存资源。

还有可能是本地内存泄漏导致应用程序失败,比如:应用程序调用了native code连续分配内存,但却没有被释放。

解决方案

解决这个问题有几个办法,通常最简单的方法就是增加交换空间,不同平台实现的方式会有所不同,比如在Linux下可以通过如下命令实现:

# 原作者使用,由于我手里并没有Linux环境,所以并未测试# 创建并附加一个大小为640MB的新交换文件swapoff -a dd if=/dev/zero of=swapfile bs=1024 count=655360mkswap swapfileswapon swapfile

Java GC会扫描内存中的数据,如果是对交换空间运行垃圾回收算法会使GC暂停的时间增加几个数量级,因此你应该慎重考虑使用上文增加交换空间的方法。

如果你的应用程序部署在JVM需要同其他进程激烈竞争获取资源的物理机上,建议将服务隔离到单独的虚拟机中

但在许多情况下,您唯一真正可行的替代方案是:

  • 升级机器以包含更多内存

  • 优化应用程序以减少其内存占用

当您转向优化路径时,使用内存转储分析程序来检测内存中的大分配是一个好的开始。

7、java.lang.OutOfMemoryError:Requested array size exceeds VM limit

Java对应用程序可以分配的最大数组大小有限制。不同平台限制有所不同,但通常在1到21亿个元素之间。


图片来源:plumbr

当你遇到Requested array size exceeds VM limit错误时,意味着你的应用程序试图分配大于Java虚拟机可以支持的数组。

原因分析

该错误由JVM中的native code抛出。 JVM在为数组分配内存之前,会执行特定于平台的检查:分配的数据结构是否在此平台中是可寻址的。

你很少见到这个错误是因为Java数组的索引是int类型。 Java中的最大正整数为2 ^ 31 - 1 = 2,147,483,647。 并且平台特定的限制可以非常接近这个数字,例如:我的环境上(64位macOS,运行Jdk1.8)可以初始化数组的长度高达2,147,483,645(Integer.MAX_VALUE-2)。如果再将数组的长度增加1到Integer.MAX_VALUE-1会导致熟悉的OutOfMemoryError:

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit

但是,在使用OpenJDK 6的32位Linux上,在分配具有大约11亿个元素的数组时,您将遇到Requested array size exceeded VM limit的错误。 要理解你的特定环境的限制,运行下文中描述的小测试程序。

示例

for (int i = 3; i >= 0; i--) {    try {        int[] arr = new int[Integer.MAX_VALUE-i];        System.out.format("Successfully initialized an array with %,d elements.\n", Integer.MAX_VALUE-i);    } catch (Throwable t) {        t.printStackTrace();    }}

该示例重复四次,并在每个回合中初始化一个长原语数组。 该程序尝试初始化的数组的大小在每次迭代时增加1,最终达到Integer.MAX_VALUE。 现在,当使用Hotspot 7在64位Mac OS X上启动代码片段时,应该得到类似于以下内容的输出:

java.lang.OutOfMemoryError: Java heap space    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)java.lang.OutOfMemoryError: Java heap space    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)java.lang.OutOfMemoryError: Requested array size exceeds VM limit    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)java.lang.OutOfMemoryError: Requested array size exceeds VM limit    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)

注意,在出现Requested array size exceeded VM limit之前,出现了更熟悉的java.lang.OutOfMemoryError: Java heap space。 这是因为初始化2 ^ 31-1个元素的数组需要腾出8G的内存空间,大于JVM使用的默认值。

解决方案

java.lang.OutOfMemoryError:Requested array size exceeds VM limit可能会在以下任一情况下出现:

  • 数组增长太大,最终大小在平台限制和Integer.MAX_INT之间

  • 你有意分配大于2 ^ 31-1个元素的数组

在第一种情况下,检查你的代码库,看看你是否真的需要这么大的数组。也许你可以减少数组的大小,或者将数组分成更小的数据块,然后分批处理数据。

在第二种情况下,记住Java数组是由int索引的。因此,当在平台中使用标准数据结构时,数组不能超过2 ^ 31-1个元素。事实上,在编译时就会出错:error:integer number too large

8、Out of memory:Kill process or sacrifice child

为了理解这个错误,我们需要补充一点操作系统的基础知识。操作系统是建立在进程的概念之上,这些进程在内核中作业,其中有一个非常特殊的进程,名叫“内存杀手(Out of memory killer)”。当内核检测到系统内存不足时,OOM killer被激活,然后选择一个进程杀掉。哪一个进程这么倒霉呢?选择的算法和想法都很朴实:谁占用内存最多,谁就被干掉。如果你对OOM Killer感兴趣的话,建议你阅读参考资料2中的文章。


OOM Killer,图片来源:plumbr

当可用虚拟虚拟内存(包括交换空间)消耗到让整个操作系统面临风险时,就会产生Out of memory:Kill process or sacrifice child错误。在这种情况下,OOM Killer会选择“流氓进程”并杀死它。

原因分析

默认情况下,Linux内核允许进程请求比系统中可用内存更多的内存,但大多数进程实际上并没有使用完他们所分配的内存。这就跟现实生活中的宽带运营商类似,他们向所有消费者出售一个100M的带宽,远远超过用户实际使用的带宽,一个10G的链路可以非常轻松的服务100个(10G/100M)用户,但实际上宽带运行商往往会把10G链路用于服务150人或者更多,以便让链路的利用率更高,毕竟空闲在那儿也没什么意义。

Linux内核采用的机制跟宽带运营商差不多,一般情况下都没有问题,但当大多数应用程序都消耗完自己的内存时,麻烦就来了,因为这些应用程序的内存需求加起来超出了物理内存(包括 swap)的容量,内核(OOM killer)必须杀掉一些进程才能腾出空间保障系统正常运行。就如同上面的例子中,如果150人都占用100M的带宽,那么总的带宽肯定超过了10G这条链路能承受的范围。

示例

当你在Linux上运行如下代码:

public static void main(String[] args){    List<int[]> l = new java.util.ArrayList();    for (int i = 10000; i < 100000; i++) {        try {            l.add(new int[100000000]);        } catch (Throwable t) {            t.printStackTrace();        }    }}

在Linux的系统日志中/var/log/kern.log会出现以下日志:

Jun  4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice childJun  4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB

注意:你可能需要调整交换文件和堆大小,否则你将很快见到熟悉的Java heap space异常。在原作者的测试用例中,使用-Xmx2g指定的2g堆,并具有以下交换配置:

# 注意:原作者使用,由于我手里并没有Linux环境,所以并未测试swapoff -a dd if=/dev/zero of=swapfile bs=1024 count=655360mkswap swapfileswapon swapfile

解决方案

解决这个问题最有效也是最直接的方法就是升级内存,其他方法诸如:调整OOM Killer配置、水平扩展应用,将内存的负载分摊到若干小实例上..... 我们不建议的做法是增加交换空间,具体原因已经在前文说过。参考资料②中详细的介绍了怎样微调OOM Killer配置以及OOM Killer选择进程算法的实现,建议你参考阅读。



如果你想学习Java工程化、高性能及分布式、高性能、深入浅出。性能调优、Spring,MyBatis,Netty源码分析和大数据等知识点可以来找我。


而现在我就有一个平台可以提供给你们学习,让你在实践中积累经验掌握原理。主要方向是JAVA架构师。如果你想拿高薪,想突破瓶颈,想跟别人竞争能取得优势的,想进BAT但是有担心面试不过的,可以加我的Java架构进阶群:554355695


注:加群要求


1、具有2-5工作经验的,面对目前流行的技术不知从何下手,需要突破技术瓶颈的可以加。 
2、在公司待久了,过得很安逸,但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。 
3、如果没有工作经验,但基础非常扎实,对java工作机制,常用设计思想,常用java开发框架掌握熟练的,可以加。 
4、觉得自己很牛B,一般需求都能搞定。但是所学的知识点没有系统化,很难在技术领域继续突破的可以加。 
5.阿里Java高级大牛直播讲解知识点,分享知识,多年工作经验的梳理和总结,带着大家全面、科学地建立自己的技术体系和技术认知! 
6.小号加群一律不给过,谢谢。

原创粉丝点击