1.JVM的内存区域是怎么划分的?
2.OOM可能发生在哪些区域上?
根据javadoc的描述,OOM是指JVM的内存不够用了,同时垃圾收集器也无法提供更多的内存。从描述中可以看出,在JVM抛出OutOfMemoryError之前,垃圾收集器一般会出马先尝试回收内存。
从上面分析的Java数据区来看,除了程序计数器不会发生OOM外,哪些区域会发生OOM的情况呢?
第一,堆内存。堆内存不足是最常见的发送OOM的原因之一
如果在堆中没有内存完成对象实例的分配,并且堆无法再扩展时,将抛出OutOfMemoryError异常,抛出的错误信息是"java.lang.OutOfMemoryError:Java heap space"。
当前主流的JVM可以通过-Xmx和-Xms来控制堆内存的大小,发生堆上OOM的可能是存在内存泄露,也可能是堆大小分配不合理。
第二,Java虚拟机栈和本地方法栈,这两个区域的区别不过是虚拟机栈为虚拟机执行Java方法服务,而本地方法栈则为虚拟机使用到的Native方法服务,在内存分配异常上是相同的。
在JVM规范中,对Java虚拟机栈规定了两种异常:
-
如果线程请求的栈大于所分配的栈大小,则抛出StackOverFlowError错误,比如进行了一个不会停止的递归调用;
-
如果虚拟机栈是可以动态拓展的,拓展时无法申请到足够的内存,则抛出OutOfMemoryError错误。
第三,直接内存。直接内存虽然不是虚拟机运行时数据区的一部分,但既然是内存,就会受到物理内存的限制。
在JDK1.4中引入的NIO使用Native函数库在堆外内存上直接分配内存,但直接内存不足时,也会导致OOM。
第四,元空间 。随着Metaspace元数据区的引入,方法区的OOM错误信息也变成了"java.lang.OutOfMemoryError:Metaspace"。
内存区域 | 是否线程私有 | 是否可能发生OOM |
程序计数器 | 是 | 否 |
虚拟机栈 | 是 | 是 |
本地方法栈 | 是 | 是 |
方法区 | 否 | 是 |
直接内存 | 否 | 是 |
堆 | 否 | 是 |
3.堆内存的结构?
1.所有新生成的对象首先都是放在年轻代的。
2.新生代内存按照8:1:1的比例分为一个eden区和两个Survivor(s0,s1)区。大部分对象在Eden区中生成。回收时先将eden区存活的对象复制到一个survivor0区,然后清空eden区,当这个survivor0区,也存放满了时,则将eden区和survivor0区存活对象复制到另一个survivor1区,然后清空eden和这个survivor0区,此时survivor0区是空的,然后将survivor0区和survivor1区交换,即保持survivor1区为空,如此往复。
3.在年轻代中经历了 N次垃圾回收后仍然存活的对象,就会被放到年老代中。因此,可以认为年老代中存放的都是一些生命周期较长的对象。默认是15次
4.内存比新生代也大很多(大概是2倍),当老年代内存满时触发MajorGC【meɪdʒə(r)】即FullGC,
FullGC发生频率比较低,老年代对象存活时间比较长,存活率比较高。
4.常用的性能监控与问题定位工具有哪些?
在系统的性能分析中,CPU、内存与IO是主要的关注项。很多时候服务出现问题,在这三者上会体现出现,比如CPU飙升,内存不足发生OOM等,这时候需要使用对应的工具,来对性能进行监控,对问题进行定位。对于CPU的监控,首先可以使用top命令来进行查看,下面是使用top查看负载的一个截图:
load average 代表1分钟、5分钟、15分钟的系统平均负载,从这三个数字,可以判断系统负荷是大还是小。
当CPU完全空闲的时候,平均负荷为0;当CPU工作量饱和的时候,平均负荷为1。因此 load average 这三个数值越低,代表系统负荷越小。
那么什么时候能看出系统负荷比较重呢?
从top命令的截图中可以看到这三个值机器的load average非常低。如果这三个值非常高,比如超过了50%或60%,就应当引起注意。
从时间维度上来说,如果发现CPU负荷慢慢升高,也需要警惕。
其他的内存、CPU等性能监控工具的使用,以一张脑图来展示: