深入理解Java虚拟机总结

花了几天学习完了周志明老师写的《深入理解Java虚拟机–JVM高级特性与最佳实践》一书，为更加深入的理解以及日后复习之用，写一篇总结

自动内存管理机制

2. Java内存区域与内存溢出异常
Java虚拟机所管理的内存包括：方法区、堆、虚拟机栈、本地方法栈、程序计数器。

• 程序计数器：是一块较小的内存空间，他可以看作是当前线程所执行的字节码行号的指示器；如果正在执行的是Native方法，这个计数器值则为空。（线程隔离的数据区，无OOM）
• Java虚拟机栈：虚拟机栈描述的是Java方法执行的内存模型，用于存储局部变量、操作数栈、动态链接、方法出口等信息。（线程隔离的数据区，如果线程请求的栈深度大于虚拟机嗦允许的深入，将抛出StackOverFlowError；虚拟机占一般可以自动扩展，如果内存不足而且无法扩展，抛出OOM；书中指出，单线程下都抛出StackOverFlowError，多线程下可以抛出OOM unable to create new native thread）
• 本地方法栈：与 Java虚拟机栈相同，只是服务于Native方法。（线程隔离的数据区；抛出异常与 Java虚拟机栈相同；Native方法一般是指非java代码的接口，我理解的大部分情况下是调用虚拟机底层的C/C++方法或者硬件接口）
• Java堆：几乎所以的对象实例都在这里分配，细分为：新生代和老年代；新生代又可以细分为1个Eden空间和2个Survivor空间（线程共享区域，但是也会划分线程私有的分配缓冲区TLAB；抛出OOM–Java heap space）
• 方法区：存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在HotSpot中用永久代来实现方法区，所以在查看内存分配的时候会看到Per区（线程共享区域，抛出OOM PerGen space，使用字节码技术动态加载Class后，会导致溢出）
• 运行时常量池：用于存放编译期产生的各种字面量和符号引用，这部分内容将在内贾在后进入方法去的运行时常量池中存放。（线程共享区域，抛出OOM PerGen space，但是在常量池转移到堆后，应该无此异常）
• 补充元数据区metaspace：在后面的虚拟机中，不再保有方法区的概念，而采用元数据区，没有查到十分详细的说明，大概是就是存放类的元数据信息。个人认为应该是将常量池排除之后的方法区，在已经JDK1.7之后的HotSpot中，已经把字符串常量池移出到堆区。

虚拟机内存分配参数：

• -Xms：初始堆大小
• -Xmx：堆最大可用大小
• -Xmn：新生代的大小
• -XX：SurvivorRatio，公式-XX:SurvivorRatio=eden/from =eden/to，例如-XX：SurvivorRatio=8，此时eden=8，from =to=1
• -Xss：线程栈的大小

---

3. 垃圾收集器与内存分配策略

• 引用技术算法：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值加1；当引用失效，计数器减1；任何石刻计数器为0对象就不可使用。但无法解决对象之间相互引用的问题，如A引用B，B引用A，此时A和B的引用都为1，但是再无其他引用，实际上已经死亡却无法回收
• 可达性分析算法：通过一系列的GC Roots对象作为起点，从起点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连，则对象不可用（图论中的，从GC Roots不可达）。可以用作GC Roots的对象：虚拟机栈（栈帧中的本地变量表）中引用的对象，方法区中镜头属性引用的对象，方法区中常量引用的对象，本地方法栈中JNI(Native方法)引用的对象。
• 四种引用：强引用，通常我们使用的引用，类似（Object obj=new Object()），只要引用还在，垃圾收集器永远不会回收掉被引用对象；软引用，有用但非必须的对象，在内存将要发生溢出异常之前进行第二次回收（即使引用在），采用SoftReference类（SoftReference sf= new SoftReference(new Object())）;弱引用，非必须对象的引用，只能生存到下一次垃圾收集器发生之前，采用WeakReference类来实现软引用；虚引用，也称为幽灵引用或幻影引用，无法通过虚引用来取得一个对象的实例，为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收的时候收到一个系统通知，参考博文
• 死亡还是生存：要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后没有发现与GC Roots相链接的引用链，那他将会被第一次标记并且进行一次筛选，筛选的条件是次对象是否有必要执行finalize()方法，如果未重载finalize()或者已经执行过finalize()则不用再执行finalize()，稍后对执行finalize()的对象进行第二次标记，执行finalize()方法后如果对象被重新引用，则可以存活。注：虚拟机只会触发这个方法，但并不承诺会等待他运行结束，所以也可能在finalize()中自救失败，而且finalize()自救只有一次机会，因为不会第二次执行finalize()
• 回收方法区：判断一个常量是否是废弃常量与Java堆一致，判断一个类是否是无用类需要满足3个条件–该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；加载该类的ClassLoader已经被回收；该类对应的java.langClass对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
• 标记-清除算法：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象
• 复制算法：将可用内存按容量划分为大小相等的两块，每次使用其中的一块，当一块的内存用完了，就将还存活的对象复制到另一块上面，然后再把已使用过的内存空间一次清空（Eden和Survivor）
• 标记-整理算法：标记过程仍然与标记-清楚算法一样，让所以存活对象都向一端移动，然后直接清理掉边界意外的内容
• 枚举根节点：使用OopMap的数据结构来存放对象的引用
• 安全点：抢先式中断和主动式中断
• 垃圾收集器：Serial–CMS/Serial Old，ParNew–CMS/Serial Old，Parallel Scavenge–Serial Old/Parrallel Old，G1
• Serial/Serial Old：单线程收集器；新生代采取复制算法，暂停所有用户线程；老年代采用标记整理算法，暂停所有用户线程。虚拟机运行在client模式下的默认新生代收集器
• ParNew/Parallel Old：多线程收集器；新生代采取复制算法，暂停所有用户线程；老年代采用标记整理算法，暂停所有用户线程
• Parallel Scavenge：新生代收集器，采用复制算法，吞吐量优先收集器。在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge+Parallel Old
• CMS（Concurrent Mark Sweep）：一种以获取最短回收停顿事件为目标的收集器，标记-清楚算法。四个步骤；初始标记，单线程stw，标记GC Roots能直接关联到的对象，速度很快；并发标记，GC Roots Tracing（应该就是判断复活吧，和被标记对象的变化）；重新标记，修正并发标记期间因用户程序继续运作而导致标记变动的那一部分对象，多线程stw，时间比初始标记稍长，远比并发标记短；并发清除，完成后重置线程为用户线程。缺点，CPU资源敏感，在并发阶段占用CPU资源导致程序变慢；无法处理浮动垃圾，在并发过程中会产生新的垃圾，无法清理，而且在垃圾清理过程中出现CMS运行期间预留的内存无法满足运行需求的时候，就会出现一次Concurrent Mode Failure失败，这是启用后备预案，临时启用Serial Old收集器；碎片整理由于CS是基于标记-清除算法实现的，所以会出现大量空间碎片，当老年代有足够空间却没有足够连续空间分配内存时候触发一次合并整理过程，stw时间会变长。
• G1：优势–并发与并行；分代收集；空间整合，整体上看是基于标记-整理算法，从局部（两个Region）是基于复制算法；可预测停顿。维护Remembered Set避免全堆扫描。操作步骤–初始标记标记GC Roots能直接关联到的对象，并且修改TAMS值，让下阶段程序并发运行时候能在正确可用的Region中创建对象，stw单线程，时间很短；并发标记对堆中对象进行可达性分析，找出存活对象，耗时长；最终标记修正并发标记期间的变动，stw多线程，Remembered Set Logs合并到Remembered Set；筛选回收排序制定回收计划，可并行可stw多线程，大部分是stw多线程。
• 对象优先在Eden分配：当Eden区没有足够空间分配，进行Minor GC，复制到Survovir中的一个
• 大对象直接进入老年代：超过-XX:PretenureSizeThreshold的对象直接放入老年代；长期存活的对象进入老年代，-XX:MaxTenuringThreshold设置；动态对象年龄判定，如果Survivor空间中的相同年龄对象的大小总和大于Survivor空间的一半，年龄大于或等于该年龄的对象进入老年代；空间分配担保，Minor GC之前，如果老年代最大可用连续空间小于新生代对象总空间，则是安全；否则查看HandlePromotionFailure是否允许担保失败；允许则检查老年代可用连续空间是否大于历次进入老年代的对象大小均值，否则都触发FullGC

---

虚拟机执行子系统

7. 虚拟机类加载机制
类从被加载到虚拟机内存中开始，到卸载出内存为止，整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载。

• 类加载的时机：虚拟机自由把握。
• 初始化阶段：主动引用，触发初始化。1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发起初始化。2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。3）初始化一个类，先初始化父类。4）虚拟机启动时候执行主类（main方法）先初始化。5）如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化则先触发初始化。被动引用：不会触发类的初始化。通过子类引用父类的静态字段；通过数组定义来引用类；常量在编译阶段会存入调用类的常量池，本质上没有直接引用到定义常量的类
• 加载：在加载阶段，虚拟机需要完成以下3件事情–通过一个类的全限定名来获取定义此类的二进制字节流；将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口（加载与链接阶段的部分内容是交叉进行的）
• 验证：确保Class文件的字节流中包含的信息符合当前虚拟机的要求。1）文件格式验证。2）元数据验证。3）字节码验证，对类的方法体进行校验。4）符号引用验证，发生在虚拟机将符号引用转化为直接引用的时候，在后面的解析阶段发生。
• 准备：准备阶段是正式为类变量分配内存并设置变量初始值的阶段，这时候进行内存分配的仅包括类变量（被static修饰的变量）；如果类字段的字段属性表中存在ConstantValue属性则在准备阶段就初始化为制定值
• 解析：解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。1）类或接口的解析。2）字段解析，搜索类本身；根据继承从下往上搜索接口；从下往上搜索父类。3）类方法解析，发现该索引是接口，报错；类中查找；父类中查找；接口中查找。4）接口方法解析，发现该索引是类不是接口，报错；类中查找；接口查找；父接口查找知道java.lang.Object类
• 初始化： 到了初始化阶段，才真正执行类中定义的Java程序代码。clinit方法由编译器自动搜集类中的所有类变量的赋值动作和静态语句块中的语句合并产生，顺序由出现顺序决定；虚拟机保证父类clinit先执行；如果类中没有静态语句块，也没有对变量的赋值操作，可以没有clinit；执行接口clinit不需要执行父接口clinit；单线程执行clinit方法
• 类与类加载器：每一个类加载器都有一个独立的名称空间，两个类来源与同一个Class文件但是类加载器不同，他们就是必定不相等。
• 双亲委派模型：启动类加载器（Bootstrap ClassLoader）和其他的类加载器（扩展类加载器Extension ClassLoader、应用程序类加载器Application ClassLoader、自定义加载器（继承于Application ClassLoader））。如果一个类加载器收到了类加载的请求，它首先不会自己尝试加载这个类，而是把这个请求委派给父类加载器去完成，只有当父类加载器反馈无法完成时，子加载器才会尝试自己加载

---

8. 虚拟机字节码执行引擎

• 方法调用–解析：只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本，符合这个条件的有静态方法、私有方法、实例构造方法、父类方法，在类加载的解析阶段就会把符号引用解析为直接引用，称为非虚方法（包括final定义的方法）
• 方法调用–静态分派：重载方法，使用那个重入版本完全取决于传入参数的静态类型和数量。优先匹配正确类型，再进行自动类型转换，再自动装箱，再转型接口，再转型父类（从下往上），再变长参数；
• 方法调用–动态分派：多态，根据实际类型调用方法。invokevirtual运行解析过程–1）找到操作数栈顶第一个元素所指向的对象的实际类型C。2）找到描述法简单名称都符合，权限校验，返回方法直接引用。3）对父类查找。由于查找的都是实际类型，所以运行的时候都解析到了实际运行的直接引用上，这就是重写的本质

---

程序编译与代码优化

10. 早期（编译期）优化
前期编译器：Sun的javac、EclipseJDT中的增量式编译器，从*.java到*.class。JIT编译器：HotSpotVM的C1、C2编译器，从字节码转变成机器码。AOT编译器：直接把*.java文件编译成本地机器码。
Javac编译过程：解析与填充符号表过程；插入式注解处理器的注解处理过程；分析与字节码生成过程。

---

10. 晚期（运行期）优化
当程序运行环境中内存资源较大，可以使用解释执行节约内存，反之可以使用编译执行来提升效率。同时，解释器还可以作为编译器激进优化时的一个逃生门，让激进优化假设不成立时可以通过逆优化退回到解释状态继续执行。

• 编译层次：第0层，解释器不开启性能监控功能，可触发第一层编译；第1层，也称为C1编译，将字节码编译为本地代码，简单可靠优化，如有必要加入性能监控；第2层，C2编译，启用编译较长的优化，甚至不可靠的激进优化。
• 编译对象触发条件：被多次调用的方法；被多次执行的循环体。

---

高效并发

12. Java内存模型与线程

• 主内存与工作内存：Java内存模型规定了所有的变量都存储在主内存中（此处的主内存与介绍物理硬件时的主内存名字一样，两者也可以相互类比，但此处仅是虚拟机内存的一部分）；每条线程还有自己的工作内存（可与前面讲的处理器高速类比），线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所以操作都必须在工作内存中进行。
• 内存间交互操作：lock（锁定）：作用于主内存的变量，它把一个变量标示为一条线程独占的状态；unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定；read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到工作内存中，以便随后的load动作使用；load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中；use（使用）：作用于工作内存的变量，它把工作内存中的一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值得字节码指令时将会执行这个操作；assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作；store（存储）：作用于工作内存的变量，它把工作内存中的一个变量的值传递到主内存中，以便随后的write操作使用；write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量值放入主内存的变量中。
• 内存间交互操作的规则：1、不允许read和load、store和write操作之一单独出现，以上两个操作必须按顺序执行，但没有保证必须连续执行，也就是说，read与load之间、store与write之间是可插入其他 指令的；2、不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存；3、不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中； 4、一个新的变量只能从主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use和store操作之前，必须先执行过　　了assign和load操作； 5、一个变量在同一个时刻只允许一条线程对其执行lock操作，但lock操作可以被同一个条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁；6、如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值；7、如果一个变量实现没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量； 8、对一个变量执行unlock操作之前，必须先把此变量同步回主内存（执行store和write操作）
• volatile禁止指令重排序：有volatile修饰的变量，赋值后多执行了一个内存屏障操作，指重排序时不能把后面的指令重排序到内存屏障之前的位置。

---

13. 线程安全与锁优化

• 自旋锁与自适应自旋：挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大的压力。可以让后面请求锁的线程不放弃处理器执行时间，只需要让线程执行一个忙循环（自旋），默认10次，参数-XX:PreBlockSpin更改；自适应是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定
• 锁消除：对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。
• 锁粗化：如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作出现在循环体中，即使没有线程竞争也会损耗性能，因此在外围加一个锁
• 轻量级锁和偏向锁：参考博文