JVM在执行Java程序时过程中会把内存划分为几个数据区域，报考方法区、虚拟机栈、本地方法栈、堆、程序计数器等。如下图所示
图片
- 程序计数器：当前线程所执行的字节码的行号指示器，每条线程都需要一个独立的程序计数器；执行的是java方法，该记录是正在执行的虚拟机字节码指令地址，执行的是native方法，计数器值为空（Undefined），无OOM情况。
- 虚拟机栈：方法执行并创建栈帧，存储局部变量表，操作数栈、动态链接、方法出口等信息；具有64位长度占有2个局部变量空间，其余的占有1个，并且其空间在编译的期间完成分配。在线程请求栈深度大于虚拟机允许的深度会抛出StackOverflowError，在扩展无法申请足够内存会跑出OutOfMemoryError。
- 本地方法栈：跟虚拟机栈类型，但执行的Native方法，也会抛出StackOverflowError和OutOfMemoryError。
- 堆：所有对象实例以及数组都要在堆上分配，堆内存不够或无法扩展会抛出OutOfMemoryError。
- 方法区：存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，内存不够分配时也会抛出OutOfMemoryError。
SO和OOM常见异常解决方法
- Java堆溢出：展示“Java heap space”，需要分清楚是溢出还是泄露，溢出的话重点在确认内存中的对象是否是必须的，如果是必要的，就需要调整虚拟机参数（-Xmx，-Xms）；而泄露需要查看对象的GC Roots的引用链，看对象的具体引用信息，分析泄露情况
- 虚拟机栈和本地方法栈溢出：会抛出“java.lang.StackOverflowError”或者“java.lang.OutOfMemoryError”异常，出现这种情况一般都是操作系统分配给进程的内存都是有限制的，可分配内存=操作系统剩余内存-最大堆容量-最大方法去容量，这样就会导致可分配内存过小，而每个线程的栈容量越大，可创建的线程数量越小；在不减少线程数的情况下，只能减少最大堆容量和栈容量来获取更多线程
- 方法区和运行时常量池溢出：在JDK1.7以后，不会报错相关错误信息，直到系统内存被占满，但一个类的要被回收是比较困难的，这样也会导致方法区的内存溢出，在动态生成类中需要注意类的回收。
- 本机直接内存溢出：会抛出“java.lang.OutOfMemoryError”异常，在DirectMemory申请内存，计算得知内存无法分配会手动抛出异常，真正申请内存unsafe.allocateMemory()，在OOM之后发现Dump文件很小，而程序中又直接或间接使用了NIO，可以考虑该方面原因
常见导致OOM
- 内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
- 集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
- 未关闭InputStream/OutputStream；
- Bitmap使用后未调用recycle()
- static关键字
- 代码中存在死循环或循环产生过多重复的对象实体；
- 使用的第三方软件中的BUG；
- 启动参数内存值设定的过小；
- 数据库的cursor没有关闭；
- 加载太多资源到内存，导致GC耗时较多
