- 示例
- 结果
Exception in thread "main" java.lang.OutOfMemoryError: unable to create native thread
出现SOF时，会有明确错误堆栈可供分析，相对容易定位问题。如果使用HotSpot虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的）到达1000~2000没有问题，对于正常的方法调用（包括不能做尾递归优化的递归调用），这个深度应该完全够用。但如果是建立过多线程导致的内存溢出，在不能减少线程数量或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量换取更多的线程。这种通过“减少内存”手段解决内存溢出的方式，如果没有这方面处理经验，一般比较难以想到。也是由于这种问题较为隐蔽，从 JDK 7起，以上提示信息中“unable to create native thread”后面，虚拟机会特别注明原因可能是“possibly
//
#define OS_NATIVE_THREAD_CREATION_FAILED_MSG "unable to create native thread: possibly out of memory or process/resource limits reached"
3 方法区和运行时常量池溢出
运行时常量池是方法区的一部分，所以这两个区域的溢出测试可以放到一起。
HotSpot从JDK 7开始逐步“去永久代”，在JDK 8中完全使用元空间代替永久代，那么方法区使用“永久代”还是“元空间”来实现，对程序有何影响呢。
String::intern()是一个本地方法：若字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象的引用；否则，会将此String对象包含的字符串添加到常量池，并且返回此String对象的引用。
在JDK6或之前HotSpot虚拟机，常量池都是分配在永久代，可以通过如下两个参数：
限制永久代的大小，即可间接限制其中常量池的容量，
- 实例
- 结果
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java: 18)
可见，运行时常量池溢出时，在OutOfMemoryError异常后面跟随的提示信息是“PermGen space”，说明运行时常量池的确是属于方法区（即JDK 6的HotSpot虚拟机中的永久代）的 一部分。
而使用JDK 7或更高版本的JDK来运行这段程序并不会得到相同的结果，无论是在JDK 7中继续使 用-XX：MaxPermSize参数或者在JDK 8及以上版本使用-XX：MaxMeta-spaceSize参数把方法区容量同样限制在6MB，也都不会重现JDK 6中的溢出异常，循环将一直进行下去，永不停歇。
这种变化是因为自JDK 7起，原本存放在永久代的字符串常量池被移至Java堆，所以在JDK 7及以上版 本，限制方法区的容量对该测试用例来说是毫无意义。
这时候使用-Xmx参数限制最大堆到6MB就能看到以下两种运行结果之一，具体取决于哪里的对象分配时产生了溢出：
// OOM异常一： Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.base/java.lang.Integer.toString(Integer.java:440) at java.base/java.lang.String.valueOf(String.java:3058) at RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:12) // OOM异常二： Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.base/java.util.HashMap.resize(HashMap.java:699) at java.base/java.util.HashMap.putVal(HashMap.java:658) at java.base/java.util.HashMap.put(HashMap.java:607) at java.base/java.util.HashSet.add(HashSet.java:220) at RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java from InputFile-Object:14)
字符串常量池的实现位置还有很多趣事：
JDK 6中运行，结果是两个false
JDK 7中运行，一个true和一个false
因为JDK6的intern()会把首次遇到的字符串实例复制到永久代的字符串常量池中，返回的也是永久代里这个字符串实例的引用，而由StringBuilder创建的字符串对象实例在 Java 堆，所以不可能是同一个引用，结果将返回false。
JDK 7及以后的intern()无需再拷贝字符串的实例到永久代，字符串常量池已移到Java堆，只需在常量池里记录一下首次出现的实例引用，因此intern()返回的引用和由StringBuilder创建的那个字符串实例是同一个。
str2比较返回false，这是因为“java”这个字符串在执行String-Builder.toString()之前就已经出现过了，字符串常量池中已经有它的引用，不符合intern()方法要求“首次遇到”的原则，而“计算机软件”这个字符串则是首次 出现的，因此结果返回true！
对于方法区的测试，基本的思路是运行时产生大量类去填满方法区，直到溢出。虽然直接使用Java SE API也可动态产生类（如反射时的 GeneratedConstructorAccessor和动态代理），但操作麻烦。
借助了CGLib直接操作字节码运行时生成大量动态类。 当前的很多主流框架，如Spring、Hibernate对类进行增强时，都会使用到 CGLib字节码增强，当增强的类越多，就需要越大的方法区以保证动态生成的新类型可以载入内存。
很多运行于JVM的动态语言（例如Groovy）通常都会持续创建新类型来支撑语言的动态性，随着这类动态语言的流行，与如下代码相似的溢出场景也越来越容易遇到
在JDK 7中的运行结果：
Caused by: java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
JDK8及以后：可以使用
-XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10M
设置元空间初始大小以及最大可分配大小。
1.如果不指定元空间的大小，默认情况下，元空间最大的大小是系统内存的大小，元空间一直扩大，虚拟机可能会消耗完所有的可用系统内存。
2.如果元空间内存不够用，就会报OOM。
3.默认情况下，对应一个64位的服务端JVM来说，其默认的-XX:MetaspaceSize值为21MB，这就是初始的高水位线，一旦元空间的大小触及这个高水位线，就会触发Full GC并会卸载没有用的类，然后高水位线的值将会被重置。
4.从第3点可以知道，如果初始化的高水位线设置过低，会频繁的触发Full GC，高水位线会被多次调整。所以为了避免频繁GC以及调整高水位线，建议将-XX:MetaspaceSize设置为较高的值，而-XX:MaxMetaspaceSize不进行设置。
JDK8 运行结果：
一个类如果要被gc，要达成的条件比较苛刻。在经常运行时生成大量动态类的场景，就应该特别关注这些类的回收状况。
这类场景除了之前提到的程序使用了CGLib字节码增强和动态语言外，常见的还有：
- 大量JSP或动态产生JSP 文件的应用（JSP第一次运行时需要编译为Java类）
- 基于OSGi的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）
JDK8后，永久代完全废弃，而使用元空间作为其替代者。在默认设置下，前面列举的那些正常的动态创建新类型的测试用例已经很难再迫使虚拟机产生方法区OOM。
为了让使用者有预防实际应用里出现类似于如上代码那样的破坏性操作，HotSpot还是提供了一些参数作为元空间的防御措施：
- -XX:MetaspaceSize
指定元空间的初始空间大小，以字节为单位，达到该值就会触发垃圾收集进行类型卸载，同时收集器会对该值进行调整。如果释放了大量的空间，就适当降低该值，如果释放了很少空间，则在不超过-XX:MaxMetaspaceSize（如果设置了的话）的情况下，适当提高该值
- -XX:MaxMetaspaceSize
设置元空间最大值，默认-1，即不限制，或者说只受限于本地内存的大小 - -XX:MinMetaspaceFreeRatio
在GC后控制最小的元空间剩余容量的百分比，可减少因为元空间不足导致的GC频率 - -XX:Max-MetaspaceFreeRatio
控制最大的元空间剩余容量的百分比
本机直接内存溢出
直接内存（Direct Memory）的容量大小可通过-XX:MaxDirectMemorySize指定，若不指定，则默认与Java堆最大值（-Xmx）一致。
这里越过DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配。
Unsafe类的getUnsafe()指定只有引导类加载器才会返回实例，体现了设计者希望只有虚拟机标准类库里面的类才能使用Unsafe，JDK10时才将Unsafe的部分功能通过VarHandle开放给外部。
因为虽然使用DirectByteBuffer分配内存也会抛OOM，但它抛异常时并未真正向os申请分配内存，而是通过计算得知内存无法分配，就在代码里手动抛了OOM，真正申请分配内存的方法是Unsafe::allocateMemory()
- 使用unsafe分配本机内存
- 结果
由直接内存导致的内存溢出，一个明显的特征是在Heap Dump文件中不会看见有什么明显异常，若发现内存溢出之后产生的Dump文件很小，而程序中又直接或间接使用了 DirectMemory（比如使用NIO），则该考虑直接内存了。
