[TOC] # 图示  虚拟机栈是执行java的 本地方法栈是为虚拟机执行native的 1. Class Loader类加载器 2. Execution Engine执行引擎负责解释命令,提交操作系统执行 3. Native Interface本地接口 4. Runtime data area 运行数据区 # Class Loader类加载器 负责加载class文件,class文件在文件开头有特定的文件标识,并且ClassLoader只负责class文件的加载,至于他是否可以运行,则由Execution Engine决定 # Native Interface 本地接口的作用是融合不同的编程语言为java所用,他的初衷是融合c/c++程序,于是就在内存中专门开辟了一块区域处理标记为native的代码. 他的具体做法是Native Method Stack中登记native方法,在Execution Engine执行时加载native libraries 目前该方法使用的越来越少,除非是与硬件有关的应用,比如通过java程序驱动打印机,或者java系统管理生产设备,在企业级应用中已经少见 因为现在异构领域间的通信很发达,比如可以使用socket通信,也可以使用web service等等 # Method Area方法区 方法区是被所有线程共享,所有字段和方法字节码,以及一些特殊方法如构造器,接口代码也在此定义. 简单的说,所有定义的方法信息都保存在该区域,**此区域属于共享区间** **静态变量+常量+类信息+运行时常量池存+即使编译后的代码在方法区中,实例变量存在堆内存中** * 类的版本 * 字段 * 方法 * 接口 方法区和永久代: jdk已经将GC扩展至方法区了. 这个区域也会发生OutOfMemoryError ## 运行时常量池 * **运行时常量池是方法区的一部分**，所以也是全局共享的。 * **其作用是存储 Java 类文件常量池中的符号信息。** * **class 文件中存在常量池(非运行时常量池)，其在编译阶段就已经确定；JVM 规范对 class 文件结构有着严格的规范，必须符合此规范的 class 文件才会被 JVM 认可和装载。** * **运行时常量池**中保存着一些 class 文件中描述的符号引用，同时还会将这些符号引用所翻译出来的直接引用存储在**运行时常量池**中。 * **运行时常量池相对于 class 常量池一大特征就是其具有动态性，Java 规范并不要求常量只能在运行时才产生，也就是说运行时常量池中的内容并不全部来自 class 常量池，class 常量池并非运行时常量池的唯一数据输入口；在运行时可以通过代码生成常量并将其放入运行时常量池中。** * 同方法区一样，当运行时常量池无法申请到新的内存时，将抛出 OutOfMemoryError 异常。 ~~~ //局部变量表 String s1 = "abc"; String s2 = "abc"; //堆中 String s3 = new String("abc"); System.out.println(s1 == s2); //true System.out.println(s1 == s3); //false //运行时常量池,运行时产生的 System.out.println(s1 == s3.intern()); //true ~~~ # PC Register 程序计数器 * 是一块较小的内存区域,可以看做是当前线程所执行的字节码的行号指示器 * 程序计数器处于线程独占区 * 如果线程执行的是java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址.如果正在执行的是navicat方法这个可以忽略不计 * 这个区域是唯一没有规定任何OutOfMemoryError的情况 每个线程都有一个程序计数器,就是一个指针,指向方法区中的方法字节码(下一个将要指向的指令代码), 由执行引擎读取下一条指令,是一个非常小的内存空间,几乎可以忽略不计 # 虚拟机栈 虚拟机栈是执行java的. **栈帧** 每个方法执行都会创建一个栈帧,伴随方法从创建到执行完成. 用于存储局部变量表,操作数栈,动态链接,方法出口等. **局部变量表** 存放编译期可知的各种基本数据类型,引用类型,returnAddress类型. 局部变量表的内存空间在编译期完成分配,当进入一个方法时,这个方法需要在栈分配多少内存是固定的,在方法运行期间是不会改变局部变量表的大小 ~~~ //局部变量表 String s1 = "abc"; String s2 = "abc"; //堆中 String s3 = new String("abc"); System.out.println(s1 == s2); //true System.out.println(s1 == s3); //false ~~~ # Native Method Stack本地方法栈 它的具体做法是Native Method Stack中登记native方法,在Execution Engine执行时加载native libraries # 元空间和永久代 永久代基本不用了,现在都是元空间 元空间的本质和永久代类似,都是对jvm规范中方法区的实现. 不过元空间与永久代之间最大的区别在于: 元空间并不在虚拟机中,而是使用本地内存. 因此,在默认情况下,元空间的大小仅受本地内存限制 # Stack栈 栈也叫栈内存,主管java程序的运行,是在线程创建时创建,它的生命周期是跟随线程的生命周期,线程结束栈内存也就释放,对于**栈来说不存在垃圾回收问题** 只要线程一结束该栈就over,生命周期和线程一致,是**线程私有的** 基本类型的变量和对象的引用变量都是在函数的栈内存中分配  ## 栈存储什么? 栈帧中主要保存3类数据: 本地变量(Local Variables): 输入参数和输出参数以及方法内的变量; 栈操作(Operand Stack): 记录出栈,入栈的操作 栈帧数据(Frame Data): 包括类文件,方法等 # Heap堆 一个JVM实例只存在一个堆内存,堆内存的大小是可以调节的. 类加载器读取了类文件后,需要把类,方法,常变量放到堆内存中,保存所有引用类型的真实信息,以方便执行器执行,堆内存分为三部分 * Young Generation Space新生区 Young * Tenure generation space 养老区 Old * Permanent Space 永久存储区 Perm 实际而言,方法区(Method Area)和堆一样,是各个线程共享的内存区域,它用于存储虚拟机加载的:类信息+普通常量+静态变量+编译器编译后的代码等等 **虽然JVM规范将方法区描述为堆的一个逻辑部分,但他还有一个别名叫Non-Heap(非堆),目的就是要和堆分开.** 对于HotSpot虚拟机,很多开发者习惯将方法区称为永久代,当严格本质上说两者不同,或者说使用永久代来实现方法区而已,永久代是方法区的一个实现,JDK1.7版本中,已经将原本放在永久代的字符串常量池移走,放到堆中.把永久代给删除了,然后又创建个元空间,把字符串常量池又放进去了. 常量池是方法区的一部分,Class文件除了有类的版本,字段,方法,接口等描述信息外,还有一项信息就是常量池,这部分内容将在类加载后进入方法区的运行时常量池中存放  GC  ## 堆内存示意图  ## 新生区 新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。 **新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）** 当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC) 将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。 若幸存 0区也满了，再对该区进行垃圾回收，然后移动到 1 区。那如果1 区也满了呢？ 再移动到养老区。 若养老区也满了，那么这个时候将产生Major GC（FullGC），进行养老区的内存清理。 若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常**OutOfMemoryError** 如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二： （1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。 （2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。 ----内存溢出；内存泄漏 ## 养老区          养老区用于保存从新生区筛选出来的 JAVA 对象，一般池对象都在这个区域活跃 ## 永久区 永久存储区是一个常驻内存区域，用于存放JDK自身所携带的 Class,Interface 的元数据，也就是说它存储的是运行环境必须的类信息，**被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭 JVM 才会释放此区域所占用的内存。** 如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。或者大量动态反射生成的类不断被加载，最终导致Perm区被占满。 Jdk1.6及之前： 常量池分配在永久代,1.6在方法区 Jdk1.7：有，但已经逐步“去永久代”，1.7在堆 Jdk1.8及之后： 无，1.8在元空间  # 写屏障 如何确保新生代对象被老年代引用的时候不被gc？（查询老年代对象来确认对新生代对象的引用避免误回收） 机制：当老年代存活对象多时，每次minor gc查询老年代所有对象影响gc效率（因为gc stop-the-world），所以在老年代有一个write barrier（写屏障）来管理的card table（卡表），card table存放了所有老年代对象对新生代对象的引用。 所以每次minor gc通过查询card table来避免查询整个老年代，以此来提高gc性能。