JVM--Review

JVM–Review

Java内存区域

​ 1）程序计数器

​       它是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。在Java虚拟机概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
​​       Java虚拟机的多线程是通过线程轮流切换、分配处理器执行时间的方式实现的，在任何一个确定的时刻，一个处理器都只会执行一条线程中的指令。为了线程切换后能恢复到正确的执行位置，每次线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
​​       如果线程正在执行一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是本地方法，这个计数器值应该为空。此内存区域是唯一一个在《Java虚拟机规范》中没有任何OutOfMemoryError情况的区域。

​ 2）Java虚拟机栈

​​       与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的线程内存模型：每个方法被执行的时候，Java虚拟机都会同步创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态连接、方法出口等信息。每一个方法被调用直至执行完毕的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
​​       局部变量表存放了编译期可知的各种Java虚拟机基本数据类型(boolean、char、byte、short、int、long、float、double)、对象引用(reference类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置)和returnAddress类型(指向一条字节码指令的地址)。
​       这些数据类型在局部变量表中的存储空间以局部变量槽(Slot)来表示，其中64位长度的long和double类型的数据会占用两个变量槽，其余的数据类型只占用一个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小(“大小”是指变量槽的数量)。虚拟机真正使用多大的内存空间来实现一个变量槽，这是完全由具体的虚拟机实现自行决定的事情。
​       在《Java虚拟机规范》中，对这个内存区域规定了两类异常状况：
​           ①如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常
​           ②如果Java虚拟机栈容量可以动态扩展，当栈扩展时无法申请到足够的内存会抛出OutOfMemoryError异常

​ 3）本地方法栈

​       与虚拟机栈所发挥的作用是非常相似的，其区别只是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则是为虚拟机使用到的本地方法服务。
​       《Java虚拟机规范》对本地方法栈中使用的语言、使用方式与数据结构并没有任何强制规定，因此具体的虚拟机可以根据需要自由实现它，甚至由的Java虚拟机(譬如HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。
​       与虚拟机栈一样，本地方法栈也会在栈深度溢出或者栈扩展失败时分别抛出StackOverflowError和OutOfMemoryError异常。

​ 4）Java堆

​       它是虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，Java世界里“几乎”所有的对象实例都在这里分配内存。
​       Java堆是垃圾收集器管理的内存区域，因此一些资料中它也被称作“GC堆”(Garbage Collected Heap)。从回收内存的角度看，由于现代垃圾收集器大部分都是基于粉黛收集理论设计的，所以Java堆经常出现“新生代”、“老年代”、“永久代”、“Eden空间”、“From Survivor空间”、“To Survivor空间”等名词。（在HotSpot里面采用分代设计的垃圾收集器的背景下，上述说法还算是不会产生太大歧义）
​       从分配内存的角度看，所有线程共享的Java堆可以划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB)，以提升对象分配时的效率。不过无论从什么角度，无论如何划分，都不会改变Java堆中存储内容的共性，无论是哪个区域，存储的都只能是对象的实例，将Java堆细分的目的只是为了更好地回收内存，或者更快地分配内存。
​       根据《Java虚拟机规范》的规定，Java堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的，这点就像我们用磁盘空间去存储文件一样，并不要求每个文件都连续存放。但对于大对象(典型的如数组对象)，多数虚拟机实现处于实现简单、存储高效的考虑，很可能会要求连续的内存空间。
​       Java堆可以被实现成固定大小的，也可以是可扩展的，不过当前主流的Java虚拟机都是按照可扩展来实现的(通过参数-Xmx和-Xms设定)。如果在Java堆中没有内存完成实力分配，并且堆无法再扩展时，Java虚拟机会抛出OutOfMemoryError异常。

​ 5）方法区

​       它与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然《Java虚拟机规范》中把方法去描述为堆的一个逻辑部分，但是它却有一个别名叫作“非堆”(Non-Heap)，目的是与Java堆区分开来。
​       考虑到HotSpot未来的发展，在JDK6的时候HotSpot开发团队就有放弃永久代，逐步改为采用本地内存来实现方法区的计划了，到了JDK7的HotSpot，已经把原来放在永久代的字符串常量池、静态变量等移出，而到了JDK8，终于完全废弃了永久代的概念，改用与JRockit、J9一样在本地内存中实现的元空间来代替，把JDK7中永久代还剩余的内容(主要是类型信息)全部移到元空间中。
​       根据《Java虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出OutOfMemoryError异常。

​ 6）运行时常量池

​       它是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池表，用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。
​       Java虚拟机对于Class文件每一部分(自然也包括常量池)的格式都有严格规定，如每一个字节用于存储那种数据都必须符合规范上的要求才会被虚拟机认可、加载和执行，但对于运行时常量池，《Java虚拟机规范》并没有做任何细节的要求，不同提供商实现的虚拟机可以按照自己的需要来实现这个内存区域，不过一般来说，除了保存Class文件中描述的符号引用外，符号引用外，还会把符号引用翻译出来的直接引用也存储在运行时常量池中。
​       在常量池无法再申请到内存时会抛出OutOfMemoryError异常。

判断对象是否存活

​ 1）引用计数器法

​       它虽然占用一些额外的内存空间来进行记数，但它的原理简单，判定效率也很高，在大多数情况下它都是一个不错的算法。但是在Java领域，至少主流的Java虚拟机里面都没有选用引用计数算法来管理内存，主要原因是，这个看似简单的算法有很多例外情况要考虑，必须要配合大量额外处理才能保证正确地工作，譬如单纯的引用计数就很难解决对象之间相互循环引用的问题。

​ 2）可达性分析算法

​       当前主流的商用程序语言(Java、C#等)的内存管理子系统，都是通过可达性分析算法来判定对象是否存活的。这个算法的基本思路就是通过一系列成为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径成为“引用链”，如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的。

Java引用类型

​       引用分为强引用、软引用、弱引用、虚引用4种，这4种引用强度依次逐渐减弱。

​       1）强引用(Strongly Reference)：指在程序代码中普遍存在的引用赋值，即类似“Object obj = new Object()”这种引用关系。无论在任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。（对于一个对象来说，只要有强引用的存在，它就会一直存在于内存中）

​       2）软引用(Soft Reference)：用来描述一些还有用，但非必须的对象。只要被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。（如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存）

​       3）弱引用(Weak Reference)：描述那些非必须对象，但它的强度比软引用更弱一些，被弱引用关联着的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。（一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的空间）

​       4）虚引用(Phantom Reference)：也成为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例，为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。（如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收）

垃圾收集算法

​       从如何判定对象消亡的角度出发，垃圾收集算法可以划分为“引用计数式垃圾收集”(Reference Counting GC)和“追踪式垃圾收集”(Tracing GC)两大类，这两类也常称作“直接垃圾收集”和“间接垃圾收集”。
​       1）标记–清除算法（Mark–Sweep）

​       算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收所有未被标记的对象。它的主要缺点有两个：
​       ①执行效率不稳定，如果Java堆包含大量对象，而且其中大部分是需要被回收的，这是必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低；
​       ②内存空间的碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
​       应用：关注延迟的CMS收集器基于这种算法

​ 2）标记–复制算法（Mark–Copy）

​       为了解决标记–清除算法面对大量可回收对象时执行效率低的问题而被提出。它是将可用内存按容量划分为大小相等的两块，每次只是用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。如果内存中多数对象都是存活的，这种算法将会产生大量的内存空间复制的开销，但对于多数对象都是可回收的情况，算法需要复制的就是占少数的存活对象，而且每次都是针对整个半区进行内存回收，分配内存时也就不用考虑有空间碎片的复杂情况，只用移动栈顶指针，按顺序分配即可。
​       优点：实现简单，运行高效
​       缺点：将可用内存缩小为原来的一半，空间浪费太多
​       “Appel式回收”是一种更优化的半区复制分代策略。HotSpot虚拟机的Serial、ParNew等新生代收集器均采用了这种策略来设计新生代的内存布局。它的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只是用Eden和其中一块Survivor。发生垃圾收集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1，也即每次新生代中可用内存空间为整个新生代容量的90%(Eden的80%加上一个Survivor的10%)，只有一个Survivor空间，即10%的新生代是会被“浪费”的。
​       如果另一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象，这些对象便通过分配担保机制直接进入老年代，这对虚拟机来说就是安全的。

​       3）标记–整理算法（Mark–Compact）
​       标记过程仍然与“标记–清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。
​       它与标记–清除算法的本质差异在于，它是一种移动式的回收算法，而标记–清除算法是一种非移动式的回收算法。
​       “Stop The World”：如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机设计者形象的描述为“Stop The World”。
​       应用：HotSpot虚拟机里面关注吞吐量的Parallel Scavenge收集器基于这种算法
​       “如稀泥式”解决方案：可以不在内存分配和访问上增加太大额外负担，做法是让虚拟机平时多数时间都采用标记–清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经大到影响对象分配时，再采用标记–整理算法收集一次，以获得规整的内存空间。基于标记–清除算法的CMS收集器面临空间碎片过多时采用的就是这种处理算法。

内存分配与分配策略

​       HotSpot虚拟机参数：

​       -Xms<size>：设置初始Java堆大小
​       -Xmx<size>：设置最大Java堆大小
​       -Xss<size>：设置Java线程堆栈大小
​       -Xmn<size>：设置新生代大小
​       -XX:NewRatio：新生代(Eden+2*Survivor)和老年代(不包含永久区)的比值
​       ​       ​       ​       ​     例如：4，表示新生代:老年代=1:4，即新生代占整个堆的1/5
​       -XX:SurvivorRatio：设置两个Survivor区和Eden区的比值
​       ​       ​       ​       ​     例如：8，表示两个Survivor:Eden=2:8，即一个Survivor占年轻代的1/10
​       -XX:PretenureSizeThreshold=size：大于size(单位为Byte,不能直接写XMB，而应该写成X*1024*1024)的对象直接在老年代分配，目的是为了避免在Eden区及两个Survivor区之间来回复制，产生大量的内存复制操作。
​       -XX:MaxTenuringThreshold=age：对象晋升老年代的阈值，默认为15，对象的年龄达到age时，晋升到老年代。

​ 1）对象优先在Eden分配

​       在多数情况下，对象在新生代Eden区中分配。当Eden区没有足够进行分配时，虚拟机将会发起一次新生代收集（Minor GC）。垃圾收集期间，若对象全部无法放入Survivor区，则只好通过分配担保机制提前转移到老年代去。

​ 2）大对象直接进入老年代

​       大对象指需要大量连续内存空间的Java对象，最典型的大对象便是那种很长的字符串，或者元素数量很庞大的数组。大于-XX:PretenureSizeThreshold<size>参数中size的对象，会直接在老年代分配。

​ 3）长期存活的对象将进入老年代

​       虚拟机给每个对象定义了一个对象年龄计数器。存储在对象头中。对象通常在Eden区诞生，如果经过一次Minor GC后仍然存活，并且能被Survivor区容纳的话，该对象会被移动到Survivor区，并且将对象年龄设为1岁。对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15)，就会被晋升到老年代中。可以通过参数-XX:MaxTenuringThreshold设置对象晋升老年代的年龄阈值。

​ 4）动态对象年龄判定

​       为了能更好地适应不同程序的内存状况，HotSpot虚拟机并不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold才能晋升到老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到-XX:MaxTenuringThreshold中要求的年龄。

​ 5）空间分配担保

​       在发生Minor GC之前，虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那这一次Minor GC可以确保是安全的。如果不成立，则虚拟机会先查看-XX：HandlePromotionFailure参数的设置值是否允许担保失败(Handle Promotion Failure)；如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者-XX：HandlePromotionFailure设置不允许冒险，那这时就要改为进行一次Full GC。