性能文章>jvm堆内存溢出后,其他线程是否可继续工作>

jvm堆内存溢出后,其他线程是否可继续工作原创

2年前
7532311

背景

之前网上出现一个面试题:“一个线程OOM后,其他线程还能运行吗?”。我看网上出现了很多不靠谱的答案。这道题其实很有难度,涉及的知识点有jvm内存分配、作用域、gc等,不是简单的是与否的问题。

由于题目中给出的OOM,java中OOM又分很多类型;比如:堆溢出(“java.lang.OutOfMemoryError: Java heap space”)、永久带溢出(“java.lang.OutOfMemoryError:Permgen space”)、不能创建线程(“java.lang.OutOfMemoryError:Unable to create new native thread”)等很多种情况。

本文主要是分析堆溢出对应用带来的影响。

直接实验验证

image.png

日志输入:

image.png

image.png

image.png

image.png

从日志可以看出在thead-0发生OOM之后,thread-1仍旧能够继续申请内存工作。使用jconsole监控发现,thread-0开始慢慢把heap压满,发生OOM之后神奇的事情发生了,heap基本上被清空了,通过查看jconsole看到的线程信息,发现没有thead-0线程了。这就很明确了,因为thead-0没有捕获该异常,跳出了while循环,导致thead-0线程运行结束,该线程持有的对象也就能被释放了。

那如果thread-0发生了OOM,但是该线程仍旧存活并且持有这些对象会怎么样呢?

image.png

在线程thread-0我们捕获了该ERROR,然后让该线程暂停(不要让他结束,不然又像上面那样了)输出日志如下:

image.png

在thread-0发生OOM之后,thread-1在申请内存也就发生了OOM,这个很容易理解的。

原理分析

我们知道java对象基本上都是在堆上分配(有特殊情况下,不在我们讨论的范围内)。小对象都是直接在Eden区域中分配。如果此时内存不够,就会发生young gc,如果释放之后还是内存不够,此时jvm会进行full gc。如果发生full gc之后内存还是不够,此时就会抛出“java.lang.OutOfMemoryError: Java heap space”。大对象jvm会直接在old 区域中申请,但是和小对象分配的原理类似。

一般情况下,java对象内存分配跟线程无关(TLAB例外),能够申请成功至于当前只和当前heap空余空间有关。

清楚了内存分配原理之后,我们就可以以此为基础来分析各种情况。比如:在MyThread0中bytesList放在try中,代码如下:

image.png

MyThread0发生OOM之后,bytesList其实就不属于存活对象,gc的时候就被释放了。

再比如发生OOM捕获该异常之后,因为日志输入的string需要占用heap空间,也可能导致MyThread0再次发生OOM,MyThread0线程终结。

image.png

再比如MyThread0中一次性申请的内存太大,比如超过heap大小;其他申请小内存的线程肯定不会受到影响。

总结

发生OOM之后会不会影响其他线程正常工作需要具体的场景分析。但是就一般情况下,发生OOM的线程都会终结(除非代码写的太烂),该线程持有的对象占用的heap都会被gc了,释放内存。

因为发生OOM之前要进行gc,就算其他线程能够正常工作,也会因为频繁gc产生较大的影响。

请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

不起眼,但是足以让你有收获的JVM内存分析案例
分析 这个问题说白了,就是说有些int[]对象不知道是哪里来的,于是我拿他的例子跑了跑,好像还真有这么回事。点该 dump 文件详情,查看相关的 int[] 数组,点该对象的“被引用对象”,发现所
从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
协助美团kafka团队定位到的一个JVM Crash问题
概述 有挺长一段时间没写技术文章了,正好这两天美团kafka团队有位小伙伴加了我微信,然后咨询了一个JVM crash的问题,大家对crash的问题都比较无奈,因为没有现场,信息量不多,碰到这类问题我
又发现一个导致JVM物理内存消耗大的Bug(已提交Patch)
概述 最近我们公司在帮一个客户查一个JVM的问题(JDK1.8.0_191-b12),发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个B
JVM实战:优化我的IDEA GC
IDEA是个好东西,可以说是地球上最好的Java开发工具,但是偶尔也会卡顿,仔细想想IDEA也是Java开发的,会不会和GC有关,于是就有了接下来对IDEA的GC进行调优 IDEA默认JVM参数: -
不起眼,但是足以让你收获的JVM内存案例
今天的这个案例我觉得应该会让你涨姿势吧,不管你对JVM有多熟悉,看到这篇文章,应该还是会有点小惊讶的,不过我觉得这个案例我分享出来,是想表达不管多么奇怪的现象请一定要追究下去,会让你慢慢变得强大起来,
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得