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等性能监控工具的使用，以一张脑图来展示：
