JVM学习笔记 Java内存模型.docx

JVM学习笔记 Java内存模型.docx

《JVM学习笔记 Java内存模型.docx》由会员分享，可在线阅读，更多相关《JVM学习笔记 Java内存模型.docx（18页珍藏版）》请在冰豆网上搜索。

JVM学习笔记Java内存模型

JVM学习笔记Java内存模型

一Java内存模型

1、运行时数据区域

1.1程序计数器

程序计数器（ProgramCounterRegister）是一块较小的内存空间，可以看成是当前线程所执行的字节码的行号指示器。

字节码解释器工作时就是通过改变这个计数器的值来选取吓一跳需要执行的字节码指令。

线程私有，每条线程都需要有一个独立的程序计数器，各条线程之间互不影响，独立存储。

如果线程正在执行一个JavaMethod，这个计数器记录的是正在执行的虚拟机字节码指令的地址；

如果正在执行的NativeMethod，这个计数器的值为空（Undefined）。

此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError的区域。

1.2Java虚拟机栈

Java虚拟机栈（JavaVirtualMachineStacks）

线程私有，生命周期与线程相同。

虚拟机栈描述的Java方法执行的内存模型:

每个方法在执行的同时，都会创建一个栈帧（StackFrame），用于存储局部变量表、操作数栈、动态链接、方法出口等信息。

每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

局部变量表存放了编译期可知的各种基本数据类型（boolean,byte,char,short,int,float,long,double）,对象引用（reference类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）

其中64位长度的long，double类型的数据会占用2个局部变量空间（slot），其余的数据类型只占用1个。

局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，这个方法在运行期间不会改变局部变量表的大小。

在Java虚拟机规范中，对这个区域规定了两种异常情况：

如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；

如果虚拟机栈可以动态扩展（当前大部分JVM都可以动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常

1.3本地方法栈

本地方法栈（NativeMethodStack）,与虚拟机栈所发挥的作用是非常相似的，它们之间的区别不过是虚拟机栈为虚拟机执行的Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。

有的虚拟机（如：

SunHotSpot）直接将本地方法栈和Java虚拟机展合二为一。

与Java虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

1.4Java堆

Java堆（JavaHeap）

对大多数应用来说，JavaHeap是Java虚拟机所管理的内存中最大的一块。

JavaHeap是被所有线程共享的一块区域，在虚拟机启动时创建。

此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配。

Java虚拟机规范描述的是：

所有的对象实例以及数组都要在堆上分配。

（Theheapistheruntimedataareafromwhichmemoryforallclassinstancesandarraysisallocated）。

但，随着JTI编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术导致一些微妙的变化，使其变得不那么绝对了。

JavaHeap是垃圾收集器管理的主要区域，因此很多时候也被称作为“GC”堆（GarbageCollectedHeap）。

从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为：

新生代和老年代；再细分：

Eden空间，FromSurvivor空间，ToSurvivor空间等。

（详见后面GC部分）

从内存分配的角度来看，线程共享的Javaheap中可能划分出多个线程私有的分配缓存区（ThreadLocalAllocationBuffer，TLAB）。

无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好的回收内存，或者更快的分配内存。

根据Java虚拟机规范的规定，JavaHeap可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。

在实现时，Javaheap可以实现成固定大小，也可以扩展的。

当前主流了的JVM都是可扩展的（通过-Xmx和-Xms控制）

如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

1.5方法区

方法区（MethodArea）,与Javaheap一样是各个线程共享的内存区域。

用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是却有一个别名：

No-Heap（非堆），目的是与Java堆区分。

HotSpot虚拟机上的开发人员，习惯上把方法区成为“永久代”（PermanentGeneration），其实两者不等价。

这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。

根据Java虚拟机规范的规定：

当方法区无法满足内存分配的需求时，将会抛出OutOfMemoryError异常。

1.6运行时常量池

运行时常量池（RuntimeConstantPool）是方法区的一部分。

Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是：

常量池（ConstantPoolTable），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

运行时常量池相对于Class文件常量池的另外一个重要特征是：

具备动态性。

Java并不需要常量一定只有在编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也能将新的常量放入池中，这种特征被开发人员利用的比较多的就是String类的intern（）方法。

当常量池无法再申请到内存时，会抛出OutOfMemoryError异常。

1.7直接内存

直接内存（DirectMemory），并不是JVM运行时数据区的一部分，也不是虚拟机规范中定义的内存区域。

但是这部分内存也被频繁使用，而且也可能导致OutOfMemoryError异常出现。

在jdk1.4中心加入了NIO类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。

这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。

附：

JVM内存参数

-Xmx指定JVM的最大heap大小，e.g.:

-Xmx256M

-Xms指定JVM的最小heap大小，高并发应用，建议和-Xmx一样，防止因为内存收缩/突然增大带来的性能影响

-Xmn指定JVM中NewGeneration的大小。

这个参数很影响性能，如果你的程序需要比较多的临时内存，建议设置到512M，如果用的少，尽量降低这个数值，一般来说128/256足矣

-XX:

PermSize=指定JVM中PermGeneration的最小值，如：

-XX:

PermSize=32M。

其实就是方法区。

-XX:

MaxPermSize=指定PermGeneration的最大值

-Xss指定线程栈大小，如：

-Xss128k,一般来说，webx框架下的应用需要256k。

如果程序中有大规模的递归行为，考虑设置到512k/1M.这个参数对性能的影响比较大的。

-XX:

NewRatio=指定JVM中OldGenerationheapsize与NewGeneration的比例。

在使用CMSGC的情况下此参数失效。

-XX:

SurvivorRatio=指定NewGeneration中EdenSpace与**一个**SurvivorSpace的Heapsize比例。

例：

-XX:

SurvivorRatio=8,那么NewGeneration为10M时，EdenSpace为8M。

-XX:

MinHeapFreeRatio=指定JVMheap在使用率小于n的情况下，heap进行收缩。

Xmx==Xms的情况下无效。

-XX:

MaxHeapFreeRatio=指定JVMheap在使用率大于n的情况下，heap进行扩张。

Xmx==Xms的情况下无效。

-XX:

LargePageSizeInBytes=指定Javaheap的分页页面大小。

二、GC与内存分配

1综述

1.1可达性分析算法

在主流的商用编程语言实现中，都是通过可达性分析（ReachabilityAnalysis）来判定对象是否存货的。

基本思想：

通过一系列的称为“GCRoots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为“引用链（ReferenceChain）”，当一个对象到GCRoots没有任何引用链相连的话（图论：

从GCRoots到这个对象不可达）时，则证明这个对象是不可用的，所以判定为可回收对象。

在Java中，可作为GCRoots的对象包括下面几种：

虚拟机栈（栈帧中的本地变量表）中引用的对象；

方法区中类静态属性引用的对象；

方法区中常量引用的对象；

本地方法栈中JNI（即一般说的Native方法）引用的对象；

1.2引用

jdk1.2之后，Java对引用的概念进行了扩充，将引用分为：

**强引用（StrongReference）、软引用（SoftReference）、弱引用（WeakReference）、虚引用（PhantomReference）**4种。

引用强度逐渐减弱。

强引用：

指在程序代码之中普遍存在的，类似“Objectobj=newObject（）”这类引用，只要强引用存在，GC就永远不会回收这些对象；

软引用：

是用来描述一些还有用但并非必需的对象，对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围之中进行二次回收。

如果这次回收还没有足够的内存，才会抛出内存溢出异常。

jdk1.2之后，提供：

SoftReference类来实现软引用

弱引用：

用来描述非必需对象的。

但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次gc之前。

当gc工作室，无论当前内存是否足骨，都会回收掉只被弱引用关联的对象。

在jdk1.2之后，提供WeakReference类来实现弱引用。

虚引用：

也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。

一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。

为一个对象设置虚引用关联的唯一目的就是：

能在这个对象被gc回收时受到一个系统通知。

在jdk1.2之后，提供了PhantomReference类来实现虚引用

引用和队列的使用

强引用一班不会和队列一起使用

软引用可以和一个引用队列联合使用，一般软引用可以用来实现内存敏感的高速缓存，如果软引用的对象被gc回收，JVM就会把引用加入到与之关联的引用队列中去。

弱引用和引用队列一起使用，如果弱引用所引用的对象被回收了，JVM就会把这个弱引用加入到关联的队列中去

虚引用，在JVM回收虚引用时，会把这个虚引用放到与之挂念的引用队列中去。

程序可以通过判断引用队列中是否已经引用了虚引用，来了解引用对象是否要被垃圾回收。

程序如果发现某个虚引用已经被加入到引用队列，那么可以在所引用的对象内存前，采取一些逻辑处理

1.3对象生存还是死亡：

finalize（）方法

宣告一个对象的真正死亡，至少要经历两次标记过程：

如果对象在进行可达性分析后发现没有与GCRoots相连的引用链，那它将会被第一次标记并且执行一次筛选，筛选的条件是：

此对象是否有必要执行finalize（）方法。

当对象没有覆盖finalize（）方法，或者finalize（）方法已经被虚拟机掉用过，虚拟机将这两种情况视为：

“没有必要执行”；

如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会被放置在一个叫做F-Queue的队列之中，并且稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。

这里的“执行”值虚拟机会触发这个方法，但并不承诺会等待它运行结束。

这样做的原因是：

如果一个finalize（）方法中执行缓慢，或者发生了死循环（更极端），将很可能会导致F-Queue队列中的其它对象永久处于等待状态，甚至导致整个内存回收系统崩溃。

finalize（）方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue队列中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己——只要重新与引用链中的任何一个对象建立关联即可，那么在第二次标记时，它将会被移除出“即将回收”的集合；如果对象这时候还没有逃脱，那基本还是那个它就真的被回收了。

1.4回收方法区

方法区（HotSpot中的永久代）

主要回收的内容：

废弃常量和无用的类

判断一个常量是否是“废弃常量”比较简单

判断一个类是否是“无用的类”，比较严苛，需要同时满足下面3个条件：

该类的所有实例都已经被回收，也就是JavaHeap中不存在该类的实例；

加载该类的ClassLoader已经被回收；

该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

在大量使用发射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGI这类频繁自定义ClassLoader的场景都需要虚拟机具备卸载的功能，以保证永久带不会溢出。

2垃圾收集算法

算法思想

2.1标记-清除算法（Mark-Sweep）

分为：

标记、清除两个阶段。

首先标记处所有需要回收的对象，在标记完成后同意回收所有被标记的对象。

不足：

效率问题。

标记和清除两个过程效率都不高；

空间问题。

标记清除之后会喊声大量不连续的内存碎片，空间碎片太多可能会导致以后再程序运行过程需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另外一次GC操作。

2.2复制算法（Copying）

为了解决效率问题，Copying算法就出现了。

它将可用内存容量划分为大小相等的两块，每次只使用其中的一块。

当这一块内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

这样就使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况了，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

不足：

Copying算法的代价是将内存缩小为原来的一半。

在对象仍然存活时，需要进行较多的复制操作，效率将会变低。

现在的商业JVM都采用这种收集算法来回收新生代，不过不是按照1：

1，研究表明：

新生代中的对象98%都是“朝生夕死”的。

将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。

当回收时，将Eden和Survivor中还存活着的对象一次性复制到另外一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor空间。

Hotspot默认Eden：

Survivor=8：

1（-XX:

SurvivorRatio=8），也就是说每次新生代中可用的内存空间为整个新生代容量的90%。

当Survivor空间不够用时，需要依赖其他内存（这里只老年代）进行内存担保（HandlePromotion）。

内存担保：

当另外一块Survivor空间上没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

2.3标记-整理算法（Mark-Compact）

过程和标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是：

让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

2.4分代收集算法（GenerationalCollection）

根据对象的存活周期的不同，将内存划分为几块。

一般把Java堆分为：

新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

在新生代中，每次垃圾收集时都发现有大批的对象死去，只有少量存活，那就选复制算法。

老年代中因为对象存活率高、没有额外空间对他进行分配担保，就必须使用“标记-清除”或“标记-整理”算法进行回收。

3垃圾收集器

先附上：

JVMClient模式&Server模式介绍

JVMServer模式与Client模式启动，最主要的差别自傲与：

-Server模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。

可通过：

java-version查看JVM处于什么工作模式

➜~java-version

javaversion"1.8.0_91"

Java（TM）SERuntimeEnvironment（build1.8.0_91-b14）

JavaHotSpot（TM）64-BitServerVM（build25.91-b14,mixedmode）

1

2

3

4

ServerVM!

Server模式会尝试收集更多的系统性能信息，使用更复杂的优化算法对程序进行优化。

因此，当系统完全启动并进入运行稳定期后，Server模式的执行速度会远快于Client模式。

3.1Serial收集器

这个收集器是一个单线程收集器，但它的“单线程”的意义并不仅仅说明它只会只用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它进行垃圾收集时，必须停掉所有其它工作线程，直到它收集结束。

“Stoptheworld”，由虚拟机在后台自动发起和自动完成，在用户不可见的情况下吧用户正常工作的线程全部停掉，简直不能接受。

Serial收集器是虚拟机运行在Client模式下的默认新生代收集器。

有点：

简单而高效（与其它收集器的单线程比）

3.2ParNew收集器

ParNew收集器是Serial收集器的多线程版本。

除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（e.g.：

-XX:

SurvivorRatio、-XX:

PretenureSizeThreshold、-XX:

HandlePromotionFailure等）、收集算法、StopTheWold、对象分配规则、回收策略等都与Serial收集器完全一样。

是许多运行在Server模式下的虚拟机中首选的新生代收集器，

有一个很重要的与性能无关的原因：

除了Serial收集器外，目前只有它能与CMS收集器配合工作

注：

并行（Parallel）：

指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态；

并发（Concurrent）：

指用户线程与垃圾收集线程同时执行（但不一定并行，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。

附：

可以使用-XX:

ParallelGCThreads参数来限制垃圾收集的线程数。

3.3ParallelScavenge收集器

新生代收集器，使用Copying算法，并行的多线程收集器

ParallelScavenge收集器的关注点与其它收集器不同。

CMS等收集器关注点是：

尽可能地缩短垃圾收集时用户线程的停顿时间

ParallelScavenge收集器的目标是：

达到一个可控制的吞吐量（Throughput）。

ps：

吞吐量：

就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即：

吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）

适合在后台运算而不需要太多交互的任务。

提供了两个参数用于控制精确控制吞吐量

-XX:

MaxGCPauseMillis控制最大垃圾收集的停顿时间。

允许的值是一个大于0的毫秒数，GC的停顿时间是以牺牲吞吐量和新生代空间来换取的

-XX:

GCTimeRatio吞吐量大小。

是一个大于0且小于100的整数，也就是垃圾收集时间的占比，相当于吞吐量的倒数

还有一个参数：

-XX:

+UseAdaptiveSizePolicy这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:

SurvivorRatio）、晋升老年代对象年龄（-XX:

PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态的调整这些参数以提供最合适的停顿时间或者最大吞吐量。

这种调节方式称为：

GC自适应的调节策略（GCErgonomics）

3.4SerialOld收集器

SerialOld是Serial收集器的老年代版本，单线程收集器，使用“标记-整理”算法、

主要意义：

给Client模式下的虚拟机使用

如果用在Server模式下，那么它主要有两大用途：

在JDK1.5以及之前的版本中与ParallelScavenge收集器搭配使用

作为CMS收集器的后备预案，在并发收集发生CocurrentModeFailure时使用。

3.5ParallelOld收集器

ParallelOld是Parallel收集器的老年代版本，多线程收集器，使用“标记-整理”算法。

jdk1.6才提供的

3.6CMS收集器

CMS（ConcurrentMarkSweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

标记-清除算法。

不过较为复杂一些。

整个过程分为4个步骤：

初始标记（CMSinitialmark）

并发标记（CMSconcurrentmark）

重新标记（CMSremark）

并发清除（CMSconcurrentsweep）

其中初始标记、重新标记仍然需要“Stoptheworld”.

初始标记仅仅只是标记一下GCRoots能直接关联到的对象，速度很快；

并发标记就是进行GCRootsTracing的过程；

重新标记则是为了修正并发标记期间因为用户程序继续运行而导致的标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程，收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行额。

优点：

并发收集，低停顿

三个明显的缺点：

CMS收集器对CPU资源非常敏感。

CMS默认启动的回收线程数是：

（CPU数量+3）/4。

也就是当CPU在4个以上是，并发回收时垃圾收集线占用不少于25%的CPU资源，并且随着CPU数量的增加而下降。

当CPU不足4个时，比如2个，CMS对用户程序的影响就可能变得很大。

为应付这种情况，虚拟机提供了一种称为：

增量式并发收集器（Increme