jvm内存结构

JVM内存结构

1、Class Loader类加载器 2、Execution Engine 执行引擎负责解释命令，提交操作系统执行
3、Native Interface 本地接口 4、Runtime Data Area 运行数据区

1、Class Loader 类加载器

负责加载class文件，class文件在文件开头有特定的文件标示，并且ClassLoader只负责class文件的加载，至于它 是否可以运行，则由Execution Engine决定。

2、Native Interface

本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序，Java 诞生的时候是C/C++横行的 时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具 体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies。目前该方法使 用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机，或者Java系统管理生产设备，在企业 级应用中已经比较少见。 因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等等， 不多做介绍。

3、Method Area方法区

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法如构造函数，接口代码也在此定义。简单 说，所有定义的方法的信息都保存在该区域，此区属于共享区间。 静态变量+常量+类信息+运行时常量池(JDK1.6) 存在方法区中 实例变量存在堆内存中保存。

4、PC Register 程序计数器

每个线程都有一个程序计数器，就是一个指针，指向方法区中的方法字节码(下一个将要执行的指令代码)，由执行 引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。

5、Native Method Stack 本地方法栈

它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies。

类加载器

类加载器的过程 :

1、加载

这个很简单，程序运行之前jvm会把编译完成的.class二进制文件加载到内存，供程序使用，用到的就是类加载器 classLoader ，这里也可以看出java程序的运行并不是直接依 靠底层的操作系统，而是基于jvm虚拟机。如果没有 类加载器，java文件就只是磁盘中的一个普通文件。

2、连接

连接是很重要的一步，过程比较复杂，分为三步 验证 》准备 》解析

• 验证：确保类加载的正确性。一般情况由javac编译的class文件是不会有问题的，但是可能有人的class文件是
  自己通过其他方式编译出来的，这就很有可能不符合jvm的编译规则，这一步就是要过滤掉这部分不合法文件

• 准备：为类的静态变量分配内存，将其初始化为默认值 。我们都知道静态变量是可以不用我们手动赋值的，它 自然会有一个初始值，比如int
  类型的初始值就是0 ；boolean类型初始值为false；引用类型的初始值为null 。 这
  里注意，只是为静态变量分配内存，此时是没有对象实例的

• 解析：把类中的符号引用转化为直接引用。解释一下符号引用和直接引用。比如在方法A中使用方法B，

java A（）{B（）；}   

这里的B（）就是符号引用，初学java时我们都是知道这是java的引用，以为B指向B方法的内存地址，但是这是不 完整的，这里的B只是一个符号引用，它对于方法的调用没有太多的实际意义，可以这么认为，他就是给程序员看 的一个标志，让程序员知道，这个方法可以这么调用，但是B方法实际调用时是通过一个指针指向B方法的内存地 址，这个指针才是真正负责方法调用，他就是直接引用。

3、初始化

为类的静态变量赋予正确的初始值，上述的准备阶段为静态变量赋予的是虚拟机默认的初始值，此处赋予的才是程 序编写者为变量分配的真正的初始值

类加载器的种类

JDK 默认提供了如下几种ClassLoader

• 1、Bootstrp loaderBootstrp加载器是用C++语言写的，它是在Java虚拟机启动后初始化的，它主要负责加
  载%JAVA_HOME%/jre/lib,-Xbootclasspath参数指定的路径以及%JAVA_HOME%/jre/classes中的类。
• 2、ExtClassLoader Bootstrp
  loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrp
  loader.ExtClassLoader是用Java写的，具体来说就是
  sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要
  加载%JAVA_HOME%/jre/lib/ext，此路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。
• 3、AppClassLoader Bootstrploader加载完ExtClassLoader后，就会加载AppClassLoader,并且将 AppClassLoader的父加载器指定为 ExtClassLoader。AppClassLoader也是用Java写成的，它的实现类是sun.misc.Launcher$AppClassLoader，另外我们知道ClassLoader中有个getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要负责加载classpath所指定的位置的类或者是jar文档，它也是Java程
  序默认的类加载器。

双亲委托机制

• 1、工作流程：

• 1.1当Application ClassLoader 收到一个类加载请求时，他首先不会自己去尝试加载这个类，而是将这个请求委派给 父类加载器Extension ClassLoader去完成。

• 1.2.当Extension ClassLoader收到一个类加载请求时，他首先也不会自己去尝试加载这个类，而是将请求委派给父 类加载器Bootstrap ClassLoader去完成。

• 1.3.如果Bootstrap ClassLoader加载失败(在<JAVA_HOME>\lib中未找到所需类)，就会让Extension ClassLoader尝 试加载。

• 1.4.如果Extension ClassLoader也加载失败，就会使用Application ClassLoader加载。

• 1.5.如果Application ClassLoader也加载失败，就会使用自定义加载器去尝试加载。

• 1.6.如果均加载失败，就会抛出ClassNotFoundException异常。

“双亲委派”机制只是Java推荐的机制，并不是强制的机制。 我们可以继承java.lang.ClassLoader类，实现自己的类加载器。如果想保持双亲委派模型，就应该重写 findClass(name)方法；如果想破坏双亲委派模型，可以重写loadClass(name)方法。

• 2、为什么使用这种双亲委托模式呢？ 因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
  考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代
  java核心api中定义类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已
  经在启动时被加载，所以用户自定义类是无法加载一个自定义的ClassLoader。
• 3、思考： 假如我们自己写了一个java.lang.String的类，我们是否可以替换调JDK本身的类？ JVM强制java.* 包下的类是由Bootstrap ClassLoader加载

栈管运行，堆管存储

栈（stack）是什么

栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也 就释放，对于栈来说不存在垃圾回收问题，只要线程结束该栈就Over,生命周期和线程一致，是线程私有的。基本 类型的变量和对象的引用变量都是在函数的栈内存中分配。

栈运行的原理

栈中的数据都是以栈帧(Stack Frame) 的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法 (Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧F1, 并被压入到栈中，A方法又调用了B 方法，先是产生栈帧F2也被压入栈，B方法又调用了C方法，于是产生栈帧F3也被压入栈，… 执行完毕后，先弹出 F3栈帧，再弹出F2栈帧，再弹出F1栈…遵循“先进后出”或者“后进先出”原则。

栈结构如图

（1）局部变量表

局部变量表是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。

（2）操作数栈

操作数栈也是被组织成一个以字节为单位的数组，通过标准的栈操作—压栈和出栈—来访问的。比如，如果某个指 令把一个值压入到操作数栈中，稍后另一个指令就可以弹出这个值来使用。 虚拟机把操作数栈作为它的工作区—— 大多数指令都要从这里弹出数据，执行运算，然后把结果压回操作数栈。比如，iadd指令就要从操作数栈中弹出两 个整数，执行加法运算，其结果又压回到操作数栈中，看看下面的示例，它演示了虚拟机是如何把两个int类型的局 部变量相加，再把结果保存到第三个局部变量的：
在这个字节码序列里，前两个指令iload_0和iload_1将存储在局部变量中索引为0和1的整数压入操作数栈中，其后 iadd指令从操作数栈中弹出那两个整数相加，再将结果压入操作数栈。第四条指令istore_2则从操作数栈中弹出结 果，并把它存储到局部变量区索引为2的位置。

（3）动态连接

每个栈帧都包含一个指向运行时常量池中该栈帧所属性方法的引用，持有这个引用是为了支持方法调用过程中的动 态连接。在 Class 文件的常量池中存有大量的 符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引 用为参数。这些符号引用一部分会在类加载阶段或第一次使用的时候转化为直接引用，这种转化 称为静态解析。另 外一部分将在每一次的运行期期间转化为直接引用，这部分称为动态连接

（4）方法返回地址

当一个方法被执行后，有两种方式退出这个方法：正常退出和异常退出。
无论采用何种方式退出，在方法退出之前，都需要返回到方法被调用的位置，程序才能继续执行，方法返回时可能 需要在栈帧中保存一些信息，用来帮助恢复它的上 层方法的执行状态。一般来说，方法正常退出时，调用者 PC 计 数器的值就可以作为返回地址，栈帧中很可能会保存这个计数器值。而方法异常退出时，返回地址是 要通过异常处 理器来确定的，栈帧中一般不会保存这部分信息。
方法退出的过程实际上等同于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作 数栈，把返回值 (如果有的话) 压入调用栈帧的操作数栈中，调用 PC 计数器的值以指向方法调用指令后面的一条指 令等。

栈内存溢出

Exception in thread “main” java.lang.StackOverflowError
异常产生的原因：栈帧压栈的时候，超出了栈的深度。 堆

三种JVM

Sun HotSpot
提起HotSpot VM，相信所有Java程序员都知道，它是Sun JDK和OpenJDK中所带的虚拟机，也是目前使用范围 广的Java虚拟机。

 1.begin
 - iload_0    // push the int in local variable 0 onto the stack  
 - iload_1    // push the int in local variable 1 onto the stack  
 - iadd       // pop two ints, add them, push result
 - istore_2   // pop int, store into local variable 2
 6.end

HotSpot VM的热点代码探测能力可以通过执行计数器找出具有编译价值的代码，然后通知JIT编译器以方法为单 位进行编译。 如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准编译和OSR（栈上替换） 编译动作。 通过编译器与解释器恰当地协同工作，可以在优化的程序响应时间与佳执行性能中取得平衡，而且 无须等待本地代码输出才能执行程序， 即时编译的时间压力也相对减小，这样有助于引入更多的代码优化技术，输 出质量更高的本地代码。
在2006年的JavaOne大会上，Sun公司宣布终会把Java开源，并在随后的一年，陆续将JDK的各个部分（其中当 然也包括了HotSpot VM）在GPL协议下公开了源码， 并在此基础上建立了OpenJDK。这样，HotSpot VM便成为 了Sun JDK和OpenJDK两个实现极度接近的JDK项目的共同虚拟机。
在2008年和2009年，Oracle公司分别收购了BEA公司和Sun公司，这样Oracle就同时拥有了两款优秀的Java虚拟 机：JRockit VM和HotSpot VM。 Oracle公司宣布在不久的将来（大约应在发布JDK 8的时候）会完成这两款虚拟机 的整合工作，使之优势互补。 整合的方式大致上是在HotSpot的基础上，移植JRockit的优秀特性，譬如使用JRockit 的垃圾回收器与MissionControl服务， 使用HotSpot的JIT编译器与混合的运行时系统。

BEA JRocket

BEA JRockit 旨在驱动要求极高的服务器端 Java 应用，以便为企业应用提供极高的性能、可管理性和可靠性。 Oracle JRockit （原来的 Bea JRockit）系列产品是一个全面的Java运行时解决方案组合，包括了行业快的标准 Java解决方案。 大量的行业基准测试显示，基本JRockit JVM是世界上快的JVM。JRockit面向延迟敏感型应用的解 决方案JRockit Real Time提供以毫秒或微秒级的JVM响应时间，适合财务前端办公、军事指挥与控制和电信网络的 需要。使用JRockit产品，客户已经体验到了显著的性能提高（一些超过了70% ）和硬件成本的减少（达50%）。 JRocket主要是定位于服务器应用，所以不关注虚拟机的启动速度，它会将所有代码即时编译为本地代码执行， JRocket的垃圾收集器具有很高的收集效率。

IBM J9

J9与JRockit类似，亮点是高度模块化，不但可以部署在桌面或服务器上，还可以部署到嵌入式环境中，例如CLDC 级别的环境；这些环境用的是同一个J9核心VM，搭配上适用于具体环境的GC和JIT编译器。IBM J9包含整套解决方 案，后期维护相对会比较方便。

堆内存划分 (分jdk 版本)

一个JVM示例只存在一个堆内存，堆内存的大小是可以调节的，类加载器读取了类文件后，需要把类，方法，放在 堆内存中，保存着所有引用类型的真实信息，以方便执行器执行，堆内存分为三部分：新生区、养老区、永久区。
堆内存示意图

新生区

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，后被垃圾回收器收集，结束生命。新生区又 分为两部分:伊甸区(Eden space) 和幸存者区(Survivor pace) ，所有的类都是在伊甸区被new出来的。幸存区有两 个: 0区(Survivor 0 space)和1区。 新生区的空间以后会进行垃圾回收，幸存的对象，再移动到养老区。若养老区也满了,那么这个时候将产生Major GC (FullGC) ，进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生0OM 异常“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区被占满

熟悉三区结构后方可学习JVM垃圾收集

实际而言，方法区(MethodArea)和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的:类信息+普通常 量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫 做Non-Heap(非堆)， 目的就是要和堆分开。 对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代 (Parmanent Gen)” ，但严格来说，两者有本质的不 同，或者说使用永久代来实现方法区而已，永久代是方法区(相 当于是一个接口interface)的一个实现，jdk1.7的版 本中，已经将原本放在永久代的字符串常量池移走。
Jdk1.6及之前: 有永久代，常量池在方法区 Jdk1.7: 有永久代，但已经逐步“去永久代”，常量池在堆 Jdk1.8及之后:无 永久代， 常量池在元空间

内存堆栈图(jdk1.7)

请简单画出以上代码的内存图。 内存划分

JDK1.7

JDK1.8

1、JDK1.8以后将初的永久代取消了，由元空间取代

public static void main(String[] args) {
// line 1  
 int i = 1;
 // line 2      
   Object obj = new Object();
 // line 3     
    DemoClass demo = new DemoClass();
 // line 4     
    demo.method(obj);
 // line 5   
  }
 // line 9    
 private void method(Object param) {
 // line 6       
  String str = param.toString();
 // line 7      
   System.out.println(str);    }
 // line 8

-Xms 设置初始分配大小，默认为物理内存的 1/64
-Xmx 最大分配内存，默认为物理内存的 1/4
-XX:+PrintGCDetails 输出详细的GC处理日志
2、目的：将HotSpot与JRockit两个虚拟机合并标准

简单参数调优

EXP：-Xmx1024m -Xms1024m -XX:+PrintGCDetails
自动触发垃圾回收
JVM在GC 的时候，并非每次都对上面三个内存一起回收，大部分回收的指的是新生代。 按照回收区域分为两种：普通GC(Minor GC)（新生代）和全局GC(Major GC)（老年代）

GC算法

复制算法–年轻代的GC

HotSpot JVM把年轻代分为三部分，1个Eden区和2个Survivor区(分别叫from和to) .默认比例为8:1:1,一般情况下， 新创建的对象都会被分配到Eden区，这些对象经过一次MinorGC，如果仍然存活，将会被移到Survivor区，对象 在Survivor区中每熬过一次MinorGC，年龄就会增加1岁，当它能年龄增加到一定程度时，就会被移动到老年代 中。因为年轻代中的对象基本都是期生夕死的（80%以上），所以在年轻代的垃圾回收算法使用的是复制整理算 法，复制整理算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复 制到另外一块上面。

Runtime.getRuntime().totalMemory() 
Runtime.getRuntime().maxMemory()    
String str = "itcast";
 while(true){    str += str + new Random().nextInt(88888888); }

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC， Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。 年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈 值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他 们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为 To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对 象移动到年老代中。
优点：不会产生内存碎片。
缺点：
（1）会开辟新的空间也就是 To survivor，用来保存有用对象
（2）复制对象会花费一些时间

标记清除

分为标记和清除两阶段：首先标记出所有需要回收的对象，然后统一回收所有被标记的
缺点：
1、标记阶段和清除阶段的效率都不高。
2、显而易见的，清除后产生了大量不连续的内存碎片，导致在程序运行过程中需要分配较大对象的时候，
无法找 到足够的连续内存而不得不提前触发一次垃圾收集动作。
标记整理
标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一 端移动，然后直接清理掉端边界以外的内存。
优点:
自带整理功能，这样不会产生大量不连续的内存空间，适合老年代的大对象存储。
算法小结：
内存效率：复制算法>标记清除算法>标记整理算法
内存整齐度：复制算法=标记整理算法>标记清除算法 内存利用率：标记整理算法=标记清除算法>复制算法
没有最好的算法，只有最合适的算法。

分代收集

当前商业虚拟机的垃圾收集都采用分代收集。此算法没啥新鲜的，就是将上述三种算法整合了一下。具体如下： 根 据各个年代的特点采取适当的收集算法
1、在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法。只需要付出少量存 活对象的复制成本就可以完成收集。
2、老年代中因为对象存活率高、没有额外空间对他进行分配担保，就必须用 标记-清除或者标记-整理。