在日常中我们经常遇到这样的错误:java.lang.OutOfMemoryError: Java heap space。
但是除了heap space 的OutOfMemoryError，还有其它几种OutOfMemoryError情况。今天我们就来了解一下：
1、java.lang.OutOfMemoryError: Java heap space。
这是因为虚拟机堆的空间所剩不多。当准备创建的对象需要的内存已经超过虚拟机堆所剩的空间。虚拟机会尝试通过full GC来回收内存，如果不行的话，就会抛出OutOfMemoryError。
导致OutOfMemoryError异常的常见原因有以下几种：
内存中加载的数据量过于庞大，如一次性从DB取出过多数据；
集合类中有对象的引用，使用完后未清空，使得JVM不能回收；
代码中存在死循环或循环产生过多重复的对象实体；
启动参数内存值设定的过小。
举一个常见的OutOfMemoryError场景：先从DB读取数据存放到内存中，然后遍历处理。
public class HeapSpaceOutOfMemory {
private static List<byte[]> getDataFromDb() {
List<byte[]> list = new ArrayList<>();
for (int i = 0; i < 500; i++) {
byte[] data = new byte[1024 * 1024];// 1M的对象
list.add(data);
}
return list;
}
public static void main(String[] args) {
// 1、从db取数据，大小为500M
List<byte[]> list = getDataFromDb();
// 2、遍历处理list
for (byte[] data : list) {
//do something
}
System.out.println("success");
}
}
JVM参数： -Xms64M -Xmx128M -XX:+PrintGCDetails -Xloggc:/apps/logs/heap_demo.log
运行结果：
查看GC Log，可以看到有Full GC 的痕迹，但是Full GC的收效果不明显，年轻代和年老代都没有足够的空间为即将创建的对象分配空间。
解决OOM最快的方法就是调整-Xmx参数，增加堆的大小。
调整JVM参数： -Xms64M -Xmx1024M -XX:+PrintGCDetails -Xloggc:/apps/logs/heap_demo.log
虽然通过调整-Xmx参数解决了上面OutOfMemoryError的问题，但是如果DB的数据突然暴涨到5G、50G、500G的时候，还是会出现OutOfMemoryError。此时通过调整-Xmx参数就不合适了，先不说机器有没有这么大的内存分配，就算机器的内存够分配，Full GC导致程序停顿的时间也会很长。因此我们要从代码下手，分批次处理数据，“小步快跑”，将5G的数据拆分成10个批次，50G的数据拆分成100个批次，500G的数据拆分成1000个批次，每个批次处理500M的数据，一个批次处理完后内存回收。这样的话就不用再担心突然暴涨的数据量导致程序OutOfMemoryError。
2、java.lang.OutOfMemoryError: Metaspace
JDK1.7中，存储在永久代的部分数据就已经转移到了Java Heap或者是 Native Heap，譬如符号引用(Symbols)转移到了native heap；字面量(interned strings)转移到了java heap；类的静态变量(class statics)转移到了java heap。但永久代仍存在于JDK1.7中，并没完全移除。
JDK 8.HotSpot JVM使用本地化的内存存放类的元数据，这个空间叫做元空间（Metaspace）。官方定义："In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace"。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制，但可以通过以下参数来指定元空间的大小：-XX:MetaspaceSize、-XX:MaxMetaspaceSize。
测试代码：
public class MetaspaceOutOfMemory {
public static void main(String[] args) throws Exception {
ClassPool cp = ClassPool.getDefault();
for (int i = 0;; i++) {
cp.makeClass("com.demo.MetaspaceClass" + i).toClass();
Thread.sleep(1);
}
}
}
JVM参数：-XX:MetaspaceSize=32m -XX:MaxMetaspaceSize=64m -Xloggc:/apps/logs/heap_demo.log
打开VisualVm工具，可以发现Metaspace使用的空间大小随类装入的数量增加而增加，这也说明了Metaspace是用来存放类的元数据的。
3、java.lang.OutOfMemoryError: PermGen space
修改JVM参数为：-XX:PermSize=32M -XX:MaxPermSize=64M -Xloggc:/apps/logs/heap_demo.log，切换到JDK7下运行MetaspaceOutOfMemory。打开VisualVm工具，此时出现了PermGen标签页。随着类装载的数量增加，最终出现了java.lang.OutOfMemoryError: PermGen space，进程退出。
4、java.lang.OutOfMemoryError: GC overhead limit exceeded
GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常。官方定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存"。JVM默认启动的时候-XX:+UseGCOverheadLimit，即启用了该特性。
测试程序：
public class GCOverheadLimit {
public static void main(String[] args) {
List list = new ArrayList();
String str = "1";
for (int i = 0; i < 1000000; i++) {
for (int j = 0; j < 100; j++) {
str += "$" + i;
}
list.add(str);
}
}
}
JVM参数：-Xms64M -Xmx128M -XX:+UseGCOverheadLimit
运行结果：
最近项目有一个程序，因为频繁Full GC导致程序僵死现象，一致耗着，如果加上-XX:+UseGCOverheadLimit参数就可以让程序提前退出，避免僵死程序长期占用资源。
5、java.lang.OutOfMemoryError: unable to create new native thread
如果JVM正在请求操作系统创建一个本地线程，而操作系统无法创建的时候，就会出现这个报错信息。JVM中可以生成的最大线程数量由JVM的堆内存大小、Thread的Stack内存大小、系统最大可创建的线程数量（Java线程的实现是基于底层系统的线程机制来实现的，Windows下_beginthreadex，Linux下pthread_create）三个方面影响。
6、java.lang.OutOfMemoryError: Requested array size exceeds VM limit
当你正准备创建一个超过虚拟机允许的大小的数组时，这条错误就会出现在你眼前。64位的操作系统上，JDK7，如果数组的长度是Integer.MAX_VALUE-1,就会出现。
byte a[] = new byte[Integer.MAX_VALUE-1];
7、java.lang.OutOfMemoryError: request bytes for . Out of swap space？
这个错误是当虚拟机向本地操作系统申请内存失败时抛出的。这和你用完了堆或者持久化中的内存的情况有些不同。这个错误通常是在你的程序已经逼近平台限制的时候产生的。这个信息告诉你的是你可能已经用光了物理内存以及虚拟内存了。由于虚拟内存通常是用磁盘作为交换分区，因此你最先想到的解决方法可能是先增加交换分区的大小。不过我从没见过一个程序在频繁进行内存交换还能正常运行的，所以这个方法可能不会起到什么作用。
