一)方法区:

 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)使用单例模式比如说静态方法

2)使用反射，Class的newInstance()，只能调用空参数的构造器，权限必须是public

3)Constructor的newInstance(XX)，反射的方式可以调用空参，带有参数的构造器，权限没有要求

4)使用克隆，不需要调用任何构造器，但是必须当前类实现Cloneable接口，实现克隆方法

5)使用反序列化:从文件中和网络中来获取到一个对象的二进制流

1)从这个字节码中可以看到，stack是操作数栈的深度是2，局部变量表一共有两个元素，参数是1

2)现在来看Code代码，首先执行new字节码的操作指令，看到这里是#2，然后去找Object，首先会进行判断运行时常量池里面是否已经加载了Object类，如果没有加载过，那么直接使用ClassLoader将java/lang/Object类直接加载到方法区，并在堆上开辟内存空间；

六)对象创建的过程:

1)是否已经加载了此类和父类:

当虚拟机遇到一条new的指令的时候，首先会去检查这个指令的参数能否在Metaspace的常量池中定位到一个类的符号引用，并且检查这个类代表的符号引用的类是否已经加载，解析和初始化，就是来判断类元信息是否存在，如果没有，那么在双亲委派模式下，使用当前的类加载器以ClassLoader+包名+类名为Key查找对应的.class文件，如果没有找到文件，那么就抛出classNotFoundException异常，如果找到对应的class文件，那么直接生成对应的Class对象；

2)为对象分配内存:

首先进行计算对象占用空间大小，接着在堆中划分出一块内存给新对象，如果实例成员变量是引用类型的变量，那么仅仅分配引用变量空间即可，即是4个字节大小

如果内存规整，使用指针碰撞

2.1)如果内存是规整的，那么虚拟机将采用的是指针碰撞法来为对象分配内存，意思是将所有用过的内存放到一边，空闲的内存放到一边，中间有一个指针来作为分界点的指示器，分配内存的时候仅仅是吧指针像空闲那边挪动一段和对象大小相等的距离罢了，比如说垃圾收集器选择的是Serial，ParNew这种基于压缩算法的，虚拟机将采用这种分配方式，一般采用整理过程中的收集器的时候，使用指针碰撞；

中间有一个指针进行标识空闲空间和非空闲空间的一个划分区域，当存放完成新的对象以后，指针会向右移

2.2)空闲列表:如果内存不规整，虚拟机需要维护一个列表，使用空闲列表进行分配，如果内存本身不是规整的，那么虚拟机使用的是空闲列表法来为对象分配内存，意思就是虚拟机维护了一个列表，记录那些内存块是可以用的，那些内存块是不可用的，再分配的时候从列表中找到一块足够大的空间划分给对象实例，并且更新列表上的内容，这种分配方式称之为空闲列表，实际上选择哪一种分配方式是由JAVA的堆来决定的，而JAVA堆是否规整又有采用的垃圾回收算法是否带有压缩整理功能所决定；

3)处理并发安全问题:

再分配内存空间的时候，另一个问题就是即使保证New对象的时候的线程安全性，创建对象是非常频繁的操作，虚拟机需要解决并发问题

3.1)CAS操作:失败重试，区域枷锁，来保证指针更新操作的原子性

3.2)TLAB:把内存分配的动作按照县城划分不同的空间进行，就是每一个线程在JAVA堆中预先分配一小块内存，称之为是本地线程缓冲区；

4)初始化分配的空间:0值初始化

内存分配结束，虚拟机将分配到的内存空间都初始化成零值，不包括对象头，这一步保证了对象的实例字段在JAVA代码中可以不用赋初值就可以直接使用，程序可以访问到这些字段的数据类型所对应的0值；

5)设置对象的对象头:

将对象的所属类，就是类的元数据信息，对象的hashcode和对象的GC信息，所信息等数据存储在对象的对象头中，这个过程具体的设置方式取决于JVM来实现

6)执行init方法执行初始化

初始化成员变量，执行实例代码块，调用类的构造方法，并把对内对象的首地址，属性的显示初始化，代码块中初始化，构造器中初始化

七)执行引擎:

执行引擎的任务就是将字节码指令解释/编译为对应平台上的本地机器指令，一种是解释执行，一种是编译执行，执行引擎从程序计数器中找到对应的指令的地址，取出字节码指令，翻译成二进制码让操作系统执行，来实现跨平台的特性

从外观上来看所有的JAVA虚拟机的执行引擎输入输出都是一致的，输入的是字节码二进制流，处理过程是字节码解释执行的等效过程，输出的是执行结果；

解释器:当JAVA虚拟机启动的时候会根据预定义的规范对字节码采用逐行解释的方式执行，将每一条字节码文件中的内容翻译成对应平台的本地机器指令执行，JIT即时编译器就是虚拟机将源代码直接编译成和本地机器平台相关的机器语言

方法区直接缓存解释执行的代码缓存，通过即时编译器可以将代码指令转化成机器执行进行缓存放到方法区里面，这样当进行调用的时候，直接执行机器指令，效率就会变高，JIT即时编译只会编译热点代码

机器码:不太好排查问题

解释器:

解释器真正意义上所承担的角色就是一个运行时翻译者，将字节码文件中的内容翻译成对应的平台的本地机器指令执行，当下一条字节码指令被解释执行完成以后，接着再来根据PC寄存器中记录的下一条需要被执行的字节码指令执行解释操作

机器码直接缓存在方法区，节省了解释执行的时间

第一种是将源代码编译成字节码文件，然后再运行的时候通过解释器将字节码文件转化成机器码执行，第二种是编译执行，直接将字节码文件变成机器码，现代虚拟机为了提升执行效率会使用即时编译技术将方法编译成机器码以后再来执行；

解释器的有显示执行速度快，上来就执行解释，JIT却是要翻译，响应速度太慢

​​​​​​​

八)JIT即时编译器:JAVA是半编译半解释执行

配置参数:-Xint解释执行响应时间比较慢，-XComp编译执行，-Xmixed混合模式

JIT即时编译器一开始编译时期很长程序启动速度非常慢可能导致程序员很长时间以后才能看到代码执行的逻辑，但是解释器一开始执行速度很快，但是之后效率就不如JIT即时编译器了

1)当然是否启动JIT即时编译器将字节码直接编译成对应平台的本地机器指令，则需要根据代码被调用的执行的频率来决定，关于那些需要被编译成本地代码的字节码，也被称之为是热点代码，JIT即时编译器会在运行时针对那些频繁被调用的热点代码来做深度优化，将其直接编译成对应平台的本地机器指令，以此来提升JAVA程序的执行性能

2)一个被多次调用的方法或者是一个方法体内部循环次数较多的循环体都是可以被称之为是热点代码，因此都是可以通过JIT编译器编译成本地机器指令，由于这种变异方式发生在方法的执行过程中，因此也可以被称之为是栈上替换；

3)一个方法究竟要被调用多少次，或者一个循环体究竟要执行多少次循环才可以达到这个标准，此时必须需要一个明确的阈值，JIT即时编译器才会将这些热点代码编译成本地机器指令执行，这里面主要依靠热点探测功能，目前虚拟机使用的是基于计数器的热点探测

4)基于计数器的热点探测，虚拟机竟会为每一个方法都建立两种不同类型的计数器，分别是方法调用计数器+回边计数器

方法调用计数器主要用于统计方法的调用次数，回边计数器主要用于统计循环体执行的循环次数

5)方法计数器就用于统计方法被调用的次数，他的默认阈值在Client模式下是1500词，在Server模式下是10000词，超过这个阈值，就会触发JIT即时编译，这个阈值可以通过虚拟机参数-XX：ComplieThreshold来人为设定

6)当一个方法被调用的时候，会先检查该方法是否存在被JIT即时编译过后的版本，如果存在，那么优先使用编译过后的本地代码来执行，如果不存在已经被编译过后的版本，那么将该方法的调用计数器+1，然后方法调用计数器和回边计数器之和是否已经超过了方法调用计数器的阈值，如果已经超过了该阈值，那么将会向即时编译器提交一个该方法的代码编译请求

回边计数器:它的作用是统计一个方法中循环体代码执行的次数，在字节码终于到控制流向后跳转的指令称为回边，很显然回边计数器统计的目的就是为了出发JIT编译

C1和C2编译器有着不同的优化策略:

不同的编译器上面有着不同的优化策略，C1编译器上主要有方法内联，去虚拟化和冗余消除

1)方法内联:将引用的函数代码编译到引用点处，这样可以减少栈帧的生成，减少参数传递以及跳转的过程

2)去虚拟化:对唯一的实现类进行内连

3)冗余消除:在运行期间把一些不会执行的代码给折叠掉

C2的优化主要是在全局的局面，逃逸分析是优化的基础

基于逃逸分析在C2上有以下几种优化:

1)标量替换:用标量替换代替聚合对象的属性值

2)栈上分配:对于为逃逸的对象分配对象在栈上而不是在堆

3)同步消除:清楚同步操作，通常指synchronized

分层编译:程序解释执行，不开启性能监控可以触发C1编译，将字节码翻译成机器码，可以进行简单的优化，也可以加上性能监控，C2编译会根据性能监控信息进行激进优化

不过在JAVA7版本以后一旦开发人员在程序中显式指定-server时，默认将会开启分层编译策略，由C1编译器和C2编译器相互协作共同完成编译任务

1)一般来说，JIT编译出来的机器码性能比解释器要高

2)C2编译器启动市场比C1编译器慢，系统稳定执行以后，C2编译器执行速度远远快于C1编译器；