一)方法区:
java虚拟机中有一个方法区，该区域被所有的java线程都是共享，虚拟机一启动，运行时数据区就被开辟好了，官网上说了方法区可以不压缩还可以不进行GC，JAVA虚拟机就相当于是接口，具体的HotSpot就是虚拟机的实现，因为永久代还是使用的是JAVA虚拟机的内存，
方法区域可以是固定大小的，也可以根据计算的需要扩展，如果不需要更大的方法区域，则可以收缩，物理上是不连续的，在逻辑上是连续的；
1)方法区和JAVA堆一样，是各个线程共享的内存区域
2)方法区在JVM启动的时候就被创建，并且它的实际的物理内存空间和JAVA队去一样都可以是不连续的
3)方法区的大小和堆空间一样，可以选择固定大小或者是可扩展
4)方法去的大小决定了系统可以保存多少各类，如果系统定义了太多的类，导致方法去溢出，虚拟机同样也会抛出内存溢出错误，java.lang.OutOfMemory:perm space(永久代空间溢出)或者是java.lang.OutOfMemeory:MeatSpace(元空间空间溢出)，比如说大量加载第三方jar包，Tomact部署的工程过多，大量的动态生成反射类，加载大量第三方jar包，Tomact部署的应用程序太多，一个简单的代码可能要加载很多类，动态生成反射类，比如说动态代理，元空间不在虚拟机设置的内存中，而是使用本地内存物理内存，字符串常量池和静态变量也会变化，但是如果超过本地内存上限，也会发生OOM metaSpace，因为方法区是不共享的，所以说只能有一个类可以调用类加载器实现类加载；
5)关闭JVM就会释放这个区域的内存，JDK7以前，习惯上把方法区称之为是永久代，JDK8开始使用元空间替代了永久代，本质上方法区和永久代并不是等价的，但是仅仅是针对于HotSpot虚拟机而言的；也就是JAVA虚拟机规范，对于如何实现方法区不会做统一要求，现在来看使用永久代共容易出现OOM；
6)元空间的本质和永久代类似，都是对JVM规范中方法去的实现，不过元空间和永久代最大的区别在于元空间不在虚拟机设置的内存中，二时使用的是本地内存，永久代和元空间不光名字变了，况且内部结构也调整了，根据JAVA虚拟机规范规定，如果方法去无法满足新的内存分配的需求的时候，会抛出OOM异常，本地内存是无限大的，况且静态变量字符串常量池等等也会变化；
-XX:MetaspaceSize=100m，-XX:MaxMetaspaceSize=100m
一般在实际开发中会进行设置MetaspaceSize，不会设置MaxMetaspaceSize是默认值-1即可，这个Metaspace一开始要设置的大一些，为了避免频繁的发生FullGC导致调整水平线
方法区用于存放已经被虚拟机加载的类型信息，常量，静态变量以及即时编译器编译过后的代码缓存
1)类型信息:对于每一个加载的类型(类 class，接口 interface，枚举Enum，注解 annoation)，JVM必须在方法中存放一下类型信息:
1)这个类型的完整有效名称(全名=包名+类名)
2)这个类型直接的父类的完整有效名字(对于interface和java.lang.object，都是没有父类的)
3)这个类型的修饰符
4)这个类直接接口的有效列表
2)域信息:就是成员变量的属性，JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序，域的相关信息包括，修饰符，关键字等等，名称类型，修饰符，在方法区中也是保留着这个类信息是被哪一个类加载器加载进来的，类加载器的信息也是在类的信息中是有纪录的，同时类加载也会记录他都加载过那些类，彼此相互记录；
3)方法信息:操作数栈的深度，方法的权限，形参，局部变量表的深度，以及try catch包裹的代码范围信息；
上面的这段代码执行也不会出现空指针异常，被static和final修饰的量是在编译过程中的准备阶段就被附上初值了
Class文件常量池:每个.Java源文件编译后生成.Class文件中会保存当前类中的字面常量以及符号信息
运行时常量池：在.Class文件被加载时，.Class文件中的常量池被加载到内存中称为运行时常量池，运行时常量池每个类都有一份
字符串常量池(StringTable) :字符串常量池在JVM中是StringTable类，实际是一个固定大小的HashTable(一种高效用来进行查找的数据结构)，不同JDK版本下字符串常量池的位置以及默认大小是不同的；
二)运行时常量池:
方法区中包含了字符串常量池，字节码文件内部包含了常量池，要想弄清楚方法区，需要清楚的理解ClassFile，因为本身加载类的信息都在方法区，所以要想弄清楚方法区的运行时常量池，就需要先学会ClassFile中的常量池
常量池:字面量(10，20)，字符串本身，System，out等等类型信息这些都会对应着一个符号
类型信息，方法引用，接口信息，只是存储一份，节省空间，通过符号引用就可以直接找到对应的常量池对应字段的位置
class文件常量池:this也是以字面量的方式及进行存储的
1)方法区的运行时常量池:就是字节码文件中每一个类的接口对应的常量池表在运行时后的一个表示形式，类型信息，方法，字段，常量字段，属性引用，方法引用\
2)常量池就相当于是一张表，JVM指令需要根据这张表来找到要执行的类名，方法名，参数类型，字面量等类型，连方法名都被符号引用所代替了class文件常量池被加载到方法去以后就变成了运行时常量池；
3)运行时常量池是方法区的一部分，常量池表是Class文件的一部分，用于存放编译器的生成的各种字面量和符号引用，这部分内容将被类加载以后存放到方法区的运行时常量池中
4)运行时常量池在加载类和接口到虚拟机以后，就会创建对应的运行时常量池
JVM为每一个已经加载的类型，类或者是接口都维护一个常量池，池子中的数据项像数组项一样，都是通过索引来进行访问的，比如说#7；
5)运行时常量池中包含着多种不同的常量，包括编译时期就已经确定的数值字面量，也包括到运行时期解析才可以获得的方法或者是字段引用，此时就不是常量池中的符号引用了，而是转化成了真实地址，运行时常量池，相比于class文件常量池的另一个重要特征就是具备动态性，String.intern()，运行时常量池类似于传统编程语言中的符号表，但是它所包含的数据要比符号表要更丰富一些；
6)当创建类或者是接口的运行时常量池的时候，如果构建运行时常量池的所需要的内存空间方法去所能提供的最大值，JVM会抛出OOM异常；
三)方法区的迭代:
1)首先先明确一下，只有HotsSpot才存在永久代，BEA JRockit，IBM J9等来说，是不存在永久代的概念的，原则上如何实现方法区属于虚拟机实现的内部细节，不受JAVA虚拟机规范约束，并不要求统一
2)JDK6以前，只有永久代，静态变量就存放在永久代上面
3)JDK7存在永久代，但是已经逐步去除永久代，字符串常量池，静态变量仍然在堆里面
4)JDK8没有永久代，类型信息，字段方法，常量仍然保存在本地内存的元空间，但是字符串常量池，静态变量仍然在堆空间里面；
1)之所以要取消永久代是因为JAVA官方收购了JRocket，之后将JRocket和HotSpot进行整合的时候，因为JROCKet没有永久代，所以就把永久代给移除了；
2)为什么JRocket没有永久代呢？
随着JAVA8的到来，HotSpot VM中再也见不到永久代了，但是这并不意味着类的元数据信息也消失了，这些数据被动到了一个和堆没有任何关系的本地内存区域，这个区域叫做元空间，由于类的元数据信息分配在本地内存中，元空间最大可分配空间就是系统可用内存空间，这项改动是非常有必要的，因为:
2.1)为永久代设置空间大小很难确定:在某些场景下，如果说动态的加载类过多，很容易产生Perm区的OOM，比如说在某一个Web工程中，因为功能点比较多，那么在运行过程中，要不断地加载很多类，但是具体加载的类的多少和大小程序员是很难进行确定的，经常出现致命错误，空间小容易出现FullGC，STW时间比较长，如果发生FullGC以后没有回收什么类，就容易出现OOM，分配大了浪费空间，但是元空间max=-1，更不容易发生fullGC
2.2)对永久代的调优很困难，永久代发生FGC，JVM判断常量池废弃的常量和不再使用的类也很浪费时间，影响程序执行的性能，所以说要尽量少出现FullGC
在JAVA7中方法区的实现是依靠永久代来实现的，主要存储的是运行时常量池，class类信息等等，永久代是JVM运行时运行数据区的一块内存空间，可以通过-XX PermSize来设置永久代的大小，当内存不够的时候就会触发垃圾回收，但是JDK1.8使用元空间来替代方法区的数据存储，元空间不属于JVM内存，而是本地内存，正常情况下元空间是可以无限制的使用本地内存的，但是还是可以通过参数来设置JVM元空间的使用内存大小
1)在JDK1.7的永久代是有内存限制的，是虚拟内存，虽然可以通过参数来进行设置，但是JVM加载的class总数是很难确定的，所以很容易出现OOM的问题，但是元空间是存储在本地内存里面，内存的上限是比较大的，很好的避免这个问题；
2)永久代的对象是通过fullGC进行垃圾回收的也就是和老年代同时实现垃圾回收，替换以后简化了fullGC的过程，可以不再进行暂停的情况下去并发释放类的数据，同时也提升了GC的性能
3)Orcle公司要合并Hotspot和Jrockit的代码，但是Jrockit没有永久代
方法区使用的是虚拟机内存，和本地内存有一个映射关系，JDK8使用本地内存，此时元空间大小只是受本地内存的影响，是不是虚拟内存是程序员本身设置的，通过一定的方式将虚拟内存映射到直接内存中，类多，方法多，不确定到底开辟多大的永久代，空间小，引起fullGC，STW时间长，但是又不能回收，最后只能造成OOM，如果开辟空间越大，也会造成浪费永久代出现full GC，对永久代调优是很困难的，永久代万一进行垃圾回收，判断类和常量不再使用，所以说尽量少出现full gc
元空间默认的初始值是21M，各种加载的类信息都要存放到方法区里面，如果Web应用系统加载的类信息直接大量存放在方法区达到了21M，那么此时会触发Full GC，不光会回收堆还会回收方法区，会对方法区中某一些无用的信息进行回收；
方法区容量分配大小的自动扩容机制:
1)假设一次FullGC之后方法区的垃圾回收回收了很多对象，剩余的方法区的空间大小是1M，那么此时的方法区下一次触发FullGC的内存大小就是回比21M小，也就是15M；
2)假设这一次FullGC方法区的垃圾回收基本没回收对象，那么下一次触发FullGC的达到的空间就会变得更高，会根据方法区这一次回收的大小自动做扩容
3)推荐设置此值，很容易放满，就有可能频繁触发FullGC，必须设置此值，不要说让方法区进行自动扩容，就不会让他每一次进行FullGC，进行动态扩容，防止大量进行FullGC；
静态变量staticObj和Class对象存放在一起，而Class对象又是存放在堆空间中的
方法区和永久代有什么区别？
方法区是JAVA虚拟机规范时候给的一个概念，包括JAVA虚拟机的运行时数据区
但是Hotspot针对于方法区的实现给出了不同的名称
JDK1.7永久代=方法区实现，但是JDK1.8元空间=方法区实现
方法区是定义的名称，但是永久代和元空间都是方法区的实现而已
五)JDK1.8方法区有什么优化？
1)将元空间改成了直接内存
2)将字符串常量池移动到了堆上
在JAVA开发中最常用的两个类型就是对象和String类型，字符串常量池比较大，最大的地方就要放在运行数据区的堆空间上
为什么把字符串常量池移动到堆上呢？
JDK7中将StringTable存放到了堆空间中，因为永久代的回收效率很低，在FullGC的时候才会被触发，但是FullGC是老年代的空间不足，永久代不足的时候才会触发，这就导致StringTable回收效率不高，而当开发中会有大量的字符串需要被创建，回收效率低，导致永久代内存不足，放到堆里面，可以及时的回收内存；
四)方法区的垃圾回收:常量池中废弃的常量以及不再使用的类变量
在大量使用到反射，动态代理，CGLIB等字节码框架，动态生成JSP以及频繁的自定义类加载器的场景，通常都是需要JAVA虚拟机具有类型卸载的能力，来保证不会对方法区有着很大的压力
4.1)类卸载的条件:ZGC不支持类卸载，一般来说这个区域的回收效果非常复杂难以让人满意，但是这部分区域的回收又是比较必要的
4.2)先来说说方法区中常量池之众所存放的两大类常量:字面量+符号引用
字面量是比较接近于JAVA语言层次的常量概念，比如说文本字符串，被声明成final的常量值等，但是符号引用就属于编译原理等方面的概念，包括以下三类常量:
1)类和接口的全限定名
2)字段的名称和描述符
3)方法的名称和描述符，HotSpot虚拟机对于常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方所引用，就可以被回收
方法区中的类记录了它是由哪一个加载器进行加载的，类的加载器同时也会记录他加载过谁，类的加载器都被卸载了，那么A也会被干掉，但是通常类的加载器是一般不会被回收的
1)严重性:内存溢出>内存泄漏: 比如说ThreadLocal没有调用remove
2)内存泄漏最终会导致内存溢出，而内存溢出可能是内存泄漏导致的，比如说网络IO未释放资源
五)对象的实例化内存布局和访问定位
1)从这个字节码中可以看到，stack是操作数栈的深度是2，局部变量表一共有两个元素，参数是1
2)现在来看Code代码，首先执行new字节码的操作指令，看到这里是#2，然后去找Object，首先会进行判断运行时常量池里面是否已经加载了Object类，如果没有加载过，那么直接使用ClassLoader将java/lang/Object类直接加载到方法区，并在堆上开辟内存空间
中间有一个指针进行标识空闲空间和非空闲空间的一个划分区域，当存放完成新的对象以后，指针会向右移
