Java内存区域与内存溢出异常

Java虚拟机五块内存区

1、方法区（线程共享）

用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虚拟机规范把方法区描述为堆的一个逻辑部分，但它却有一个别名叫Non-Heap（非堆)，目的应该是与Java堆区分开。

2、虚拟机栈（线程私有，生命周期与线程相同）

Java方法执行的内存模型，每个方法执行的同时会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
PS：通常口中所指的“栈”就是虚拟机栈，或者说是虚拟机栈中局部变量表部分。
1）、局部变量表：表中存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、long、float、double）、对象引用（reference类型，指针）

3、本地方法栈

与虚拟机栈发挥的作用相似，区别为虚拟机栈为虚拟机执行Java方法（字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。

4、堆（线程共享）

Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的目的是存放对象实例，几乎所有对象实例都在这里分配内存。
Java堆是垃圾收集器管理的主要区域，因此很多时候也被成为“GC堆”（Garbage Collected Heap）。现在收集器基本采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。（进行划分是为了更好的回收内存，或者更快地分配内存。

5、程序计数器（线程私有，生命周期与线程相同）

程序计数器是一块较小的内存空间、可以看作是当前线程所执行的字节码的行号指示器。
理论上来说（各虚拟机不同，会有更高效的方法来实现）字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成

StackOverflowError异常：

1、线程请求栈的深度大于虚拟机所允许的深度

OutOfMemoryError 内存溢出（OOM）

1、无法申请到足够内存时
2、方法区无法满足内存分配需求时
3、常量池无法再申请到内存时

解决异常一般先通过内存映像分析工具（例如Eclipse Memory Analyzer）堆Dump出来的堆转储快照进行分析，重点先确认内存中的对象是否是有必要的，分清楚是内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）

内存泄漏：垃圾未成功回收，无法释放内存空间。系统分配的内存未及时归还。
内存溢出：程序申请内存时没有足够的内存空间。你要的内存空间超过了系统实际分配给你的内存空间。
内存泄漏堆积后最终会导致内存溢出。

内存溢出原因：

1.内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
2.集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；
3.代码中存在死循环或循环产生过多重复的对象实体；
4.使用的第三方软件中的BUG；
5.启动参数内存值设定的过小

内存溢出的解决方案：

第一步，修改JVM启动参数，直接增加内存。(-Xms，-Xmx参数一定不要忘记加。)
第二步，检查错误日志，查看“OutOfMemory”错误前是否有其 它异常或错误。
第三步，对代码进行走查和分析，找出可能发生内存溢出的位置。
第四步，使用内存查看工具动态查看内存使用情况。

重点排查以下几点：

1.检查对数据库查询中，是否有一次获得全部数据的查询。一般来说，如果一次取十万条记录到内存，就可能引起内存溢出。这个问题比较隐蔽，在上线前，数据库中数据较少，不容易出问题，上线后，数据库中数据多了，一次查询就有可能引起内存溢出。因此对于数据库查询尽量采用分页的方式查询。
2.检查代码中是否有死循环或递归调用。
3.检查是否有大循环重复产生新对象实体。
4.检查List、MAP等集合对象是否有使用完后，未清除的问题。List、MAP等集合对象会始终存有对对象的引用，使得这些对象不能被GC回收。

PS：如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。（通过减少内存来解决内存溢出0.0）