JVM

最新推荐文章于 2023-05-28 01:18:45 发布

tripleHu

最新推荐文章于 2023-05-28 01:18:45 发布

阅读量196

点赞数

分类专栏： JVM

本文链接：https://blog.csdn.net/huxiaochang123/article/details/79563434

版权

JVM 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

JVM

JVM内存模型

一. 线程私有区域

1. 程序计数器（Program Counter Register）：

程序计数器是一个比较小的内存区域，用于指示当前线程所执行的字节码执行到了第几行，可以理解为是当前线程的行号指示器。字节码解释器在工作时，会通过改变这个计数器的值来取下一条语句指令。
每个程序计数器只用来记录一个线程的行号，所以它是线程私有（一个线程就有一个程序计数器）的。
如果程序执行的是一个Java方法，则计数器记录的是正在执行的虚拟机字节码指令地址；如果正在执行的是一个本地（native，由C语言编写完成）方法，则计数器的值为Undefined，由于程序计数器只是记录当前指令地址，所以不存在内存溢出的情况，因此，程序计数器也是所有JVM内存区域中唯一一个没有定义OutOfMemoryError的区域。

2. 虚拟机栈（JVM Stack）：

一个线程的每个方法在执行的同时，都会创建一个栈帧（Statck Frame），栈帧中存储的有局部变量表、操作站、动态链接、方法出口等，当方法被调用时，栈帧在JVM栈中入栈，当方法执行完成时，栈帧出栈。
局部变量表中存储着方法的相关局部变量，包括各种基本数据类型，对象的引用，返回地址等。在局部变量表中，只有long和double类型会占用2个局部变量空间（Slot，对于32位机器，一个Slot就是32个bit），其它都是1个Slot。需要注意的是，局部变量表是在编译时就已经确定好的，方法运行所需要分配的空间在栈帧中是完全确定的，在方法的生命周期内都不会改变。
虚拟机栈中定义了两种异常，如果线程调用的栈深度大于虚拟机允许的最大深度，则抛出StatckOverFlowError（栈溢出）；不过多数Java虚拟机都允许动态扩展虚拟机栈的大小(有少部分是固定长度的)，所以线程可以一直申请虚拟机栈，直到内存不足，此时，会抛出 OutOfMemoryError（内存溢出）。
每个线程对应着一个虚拟机栈，因此虚拟机栈也是线程私有的。

3. 本地方法栈（Native Method Statck）：

本地方法栈在作用，运行机制，异常类型等方面都与虚拟机栈相同，唯一的区别是：虚拟机栈是执行Java方法的，而本地方法栈是用来执行native方法的，在很多虚拟机中（如Sun的JDK默认的HotSpot虚拟机），会将本地方法栈与虚拟机栈放在一起使用。同样也会抛出StatckOverFlowError（栈溢出）OutOfMemoryError（内存溢出）
本地方法栈也是线程私有的。

二. 线程共享区域

1. Heap(Java堆)

-Xmx：最大堆大小
-Xms：初始堆大小
-Xmn:年轻代大小
-XXSurvivorRatio：年轻代中Eden区与Survivor区的大小比值
-XX:PermSize JVM初始分配的非堆内存
-XX:MaxPermSize JVM最大允许分配的非堆内存，按需分配
这里写图片描述
JDK1.7及之后版本的JVM已经将运行时常量池从方法区中移了出来，在Java 堆（Heap）中开辟了一块区域存放运行时常量池。
JDK1.8中JVM的实现中将类的元数据放入 native memory, 将字符串池和类的静态变量放入java堆中
在JDK1.8中, 永久区已经被彻底移除, 取而代之的是元数据区Metaspace(这一点在查看GC日志和使用jstat -gcutil查看GC情况时可以观察到),与永久代不同, 如果不指定Metaspace大小, 如果方法区持续增长, VM会默认耗尽所有系统内存.

这里写图片描述
几乎所有对象实例和数组都要在堆上分配(栈上分配、标量替换除外), 因此是VM管理的最大一块内存, 也是垃圾收集器的主要活动区域. 由于现代VM采用分代收集算法, 因此Java堆从GC的角度还可以细分为: 新生代(Eden区、From Survivor区和To Survivor区)和老年代; 而从内存分配的角度来看, 线程共享的Java堆还还可以划分出多个线程私有的分配缓冲区(TLAB). 而进一步划分的目的是为了更好地回收内存和更快地分配内存.

堆内存需要在逻辑上是连续的（在物理上不需要），在实现时，可以是固定大小的，也可以是可扩展的，目前主流的虚拟机都是可扩展的（通过-Xmx -Xms）。如果在执行垃圾回收之后，仍没有足够的内存分配，也不能再扩展，将会抛出OutOfMemoryError

2. Method Area(方法区)

即我们常说的永久代(Permanent Generation), 也可以叫非堆（Non-Heap）用于存储被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据. HotSpot VM把GC分代收集扩展至方法区, 即使用Java堆的永久代来实现方法区, 这样HotSpot的垃圾收集器就可以像管理Java堆一样管理这部分内存, 而不必为方法区开发专门的内存管理器(永久带的内存回收的主要目标是针对常量池的回收和类型的卸载, 因此收益一般很小)

在方法区上定义了OutOfMemoryError:PermGen space异常，在内存不足时抛出。

3.运行时常量池

这里写图片描述
JDK1.6及其以前是方法区的一部分. Class文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项常量池(Constant Pool Table)用于存放编译期生成的各种字面量和符号引用, 这部分内容会存放到方法区的运行时常量池中(如前面从test方法中读到的signature信息). 但Java语言并不要求常量一定只能在编译期产生, 即并非预置入Class文件中常量池的内容才能进入方法区运行时常量池, 运行期间也可能将新的常量放入池中,

如String的intern()方法，运行时常量池除了存储编译期常量外，也可以存储在运行时间产生的常量（比如String类的intern()方法，作用是String维护了一个常量池，如果调用的字符“abc”已经在常量池中，则返回池中的字符串地址，否则，新建一个常量加入池中，并返回地址）。

在内存不足时抛出 OutOfMemoryError异常，
JDK1.7及之后版本的JVM已经将运行时常量池从方法区中移了出来，在Java 堆（Heap）中开辟了一块区域存放运行时常量池。

三. 直接内存

直接内存并不是JVM运行时数据区的一部分, 但也会被频繁的使用: 在JDK 1.4引入的NIO提供了基于Channel与Buffer的IO方式, 它可以使用Native函数库直接分配堆外内存, 然后使用DirectByteBuffer对象作为这块内存的引用进行操作(详见: Java I/O 扩展), 这样就避免了在Java堆和Native堆中来回复制数据, 因此在一些场景中可以显著提高性能.
显然, 本机直接内存的分配不会受到Java堆大小的限制(即不会遵守-Xms、-Xmx等设置), 但既然是内存, 则肯定还是会受到本机总内存大小及处理器寻址空间的限制, 因此动态扩展时也会出现OutOfMemoryError异常.

对象的创建与内存布局

1.对象的创建

Java对象的创建
这里写图片描述
上图是对象创建的完整流程图，接下来做详细说明。

当虚拟机收到new指令后，检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用所代表的类是否已被加载、解析和初始化过。如果没有，必须先执行类加载过程。

在类加载完成后可以确定对象分配所需要的空间。如果Java堆中内存是绝对规整的，用过的内存放一边，空闲的内存放另一边，中间放着一个指针作为分界点的指示器，那分配内存就只是把指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为”指针碰撞”。如果Java堆中内存不是规整的，空闲内存与使用过的内存是相互交错的，虚拟机必须维护一个列表，记录哪些内存块是可用的，在分配的时候从列表中找出足够的空间分配给对象实例，并更新列表上的记录，这种分配方式称为”空闲列表”。采用哪种分配方式通常由虚拟机的垃圾收集器是否带有压缩整理功能决定。

划分可用空间时，还需考虑为对象实例分配空间时是否是线程安全的。要保证线程安全，有两种方案。一种是对分配内存空间的动作进行同步处理，实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性。另一种是把内存分配的动作按照线程划分在不同空间中进行，每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲(Thread Local Allocation Buffer , TLAB)。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。

内存分配完成后，虚拟机对分配到的内存空间都初始化为零值(不包括对象头)，保证对象的实例字段在Java代码中可以不赋初始值就可以直接使用。
虚拟机将对象的信息放入对象的对象头中。
执行构造函数

2. 对象的内存布局

对象的内存布局总共分为三个部分：
这里写图片描述

对象头中主要包括两部分信息：
一部分用于存储对象自身的运行时数据，如哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。
另一部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。如果对象是Java数组，那在对象头中还必须有一块记录数组长的数据。
实例数据部分是对象真正存储的有效信息，也是程序代码中定义的各种类型的字段内容。从父类继承下来的，在子类中定义的都需要记录下来。

对齐填充仅仅起到占位符的作用。HotSpot VM的自动内存管理系统要求对象起始地址是8字节的整数倍，所以对象大小必须是8字节的整数倍。当对象实例数据部分没有对齐时，需要通过对齐填充来补全。

Java内存分配机制

Java内存分配和回收的机制概括的说，就是：分代分配，分代回收
这里所说的内存分配，主要指的是在堆上的分配，一般的，对象的内存分配都是在堆上进行，但现代技术也支持将对象拆成标量类型（标量类型即原子类型，表示单个值，可以是基本类型或String等），然后在栈上分配，在栈上分配的很少见，我们这里不考虑。

年轻代上的内存分配是这样的，年轻代可以分为3个区域：Eden区（伊甸园，亚当和夏娃偷吃禁果生娃娃的地方，用来表示内存首次分配的区域，再贴切不过）和两个存活区（Survivor 0 、Survivor 1）

对象优先在Eden分区：
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间分配时，虚拟机发起一次Minor GC。GC后对象尝试放入Survivor空间，如果Survivor空间无法放入对象时，只能通过空间分配担保机制提前转移到老年代。
大对象直接进入老年代：
大对象指需要大量连续内存空间的Java对象。虚拟机提供-XX:PretenureSizeThreshold参数，如果大于这个设置值对象则直接分配在老年代。这样可以避免新生代中的Eden区及两个Survivor区发生大量内存复制。
长期存活的对象进入老年代：
虚拟机会给每个对象定义一个对象年龄计数器。如果对象在Eden出生并且经过一次Minor GC后任然存活，且能够被Survivor容纳，将被移动到Survivor空间中，并且对象年龄设为1.每次Minor GC后对象任然存活在Survivor区中，年龄就加一，当年龄到达-XX:MaxTenuringThreshold参数设定的值时，将会移动到老年代。
动态年龄判断：
虚拟机不是永远要求对象的年龄必须达到-XX:MaxTenuringThreshold设定的值才会将对象移动到老年代去。如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代。
空间分配担保：
在Minor GC前，虚拟机会检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果条件成立，那么Minor GC是成立的。如果不成立，虚拟机查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用连续空间是否大于历次移动到老年代对象的平均大小，如果大于，将尝试一次Minor GC。如果小于，或者HandlePromotionFailure设置值不允许冒险，那将进行一次Full GC。
永久代GC的原因：
永久代空间已经满了
调用了System.gc()
注意：这种GC是full GC 堆空间也会一并被GC一次

新生代GC(Minor GC)：发生在新生代的垃圾收集动作，因为Java对象大多朝生夕死，所以Minor GC非常频繁，回收速度也较快。

老年代GC(Major GC/Full GC)：发生在老年代的垃圾收集动作。出现Major GC，经常会伴随至少一次Minor GC。Major GC的速度一般比Minor GC慢10倍以上。

方法区（永久代）：

　　永久代的回收有两种：常量池中的常量，无用的类信息，常量的回收很简单，没有引用了就可以被回收。对于无用的类进行回收，必须保证3点：

类的所有实例都已经被回收
加载类的ClassLoader已经被回收
类对象的Class对象没有被引用（即没有通过反射引用该类的地方）
永久代的回收并不是必须的，可以通过参数来设置是否对类进行回收。

new 对象如何不分配在堆而是栈上： 逃逸分析（把不共享的对象放在栈上，减少并发使用同步开销）、在方法内new对象

内存的回收

Java虚拟机通过 可达性分析 来判定对象是否存活。这个算法的基本思想是通过一系列称为”GC Roots”的对象作为起始点，从这些节点向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有与任何引用链相连时，则该对象是不可用的。
如图，object5,object6,object7虽然互有关联，但是GC Roots是不可达的，所以它们被判定是可回收的对象。
这里写图片描述
GC Roots的对象包括下面几种
1. 虚拟机栈（栈帧中的本地变量表）中引用的对象

方法区中类静态属性引用的对象(类静态变量)
方法区中常量引用的对象（常量）
本地方法栈中JNI(即一般说的Native方法)引用的对象

另外值得一提的是引用计数算法，引用计数法是通过给对象一个引用计数器，每当有一个地方引用它时，计数器值就加一；引用失效时，计数器值就减一；任何时刻计数器为0的对象就是不可能再被使用的。引用计数器效率高、实现简单。但是很难解决对象间相互循环引用的问题，主流Java虚拟机几乎都不再使用引用计数法来管理内存。

即使在可达性分析算法中不可达的对象，也不一定会立即被回收。一个对象被回收，至少要经历两次标记过程。
如果对象在进行可达性分析后没有与GC Roots相连的引用链，那它将会被第一次标记并进行一次筛选。筛选的条件是此对象是否有必要执行finalize()方法。当对象 没有覆盖finalize()方法，或finalize()方法已被虚拟机调用过，虚拟机将这两种情况视为”没有必要执行”。
如果这个对象判定为有必要执行finalize()方法，那么这个对象会放置在F-Queue队列中，稍后由虚拟机自动建立、低优先级的Finalizer线程去执行finalize()方法。GC对F-Queue中的对象进行第二次小规模标记，如果对象重新与引用链上的任何一个对象建立关联，那么第二次标记时它将被移除”即将回收”的集合。否则对象就真的要被回收了。

标记-清除算法(Mark-Sweep)：

算法分为”标记”和”清除”两个阶段：首先标记出需要回收的对象，在标记完成后统一回收被标记的对象。它主要不足有两个：一是效率问题，标记和清除两个过程效率都不高。二是空间问题，标记清除后会产生大量不连续内存碎片，碎片太多可能导致要分配较大对象时，无法找到足够的内存空间不得不提前触发一次垃圾收集动作。
这里写图片描述

复制算法：

复制算法将可用内存按容量划分为大小相等的两块，每次只使用其中一块。当一块内存用完了，将存活的对象复制到另一块上面，然后把已使用的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法将内存缩小为原来的一半，代价较高。
这里写图片描述

标记-整理算法(Mark-Compact)：

标记过程与”标记-清除”算法一样，但后续不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存
这里写图片描述

分代收集算法

商业虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期将内存划分为几块。Java堆分为新生代和老年代，这样可以根据年代特点采用适当的收集算法。新生代中每次垃圾收集都有大批对象死去，那就选用复制算法。老年代对象存活率高，没有额外空间进行分配担保，适合使用”标记-清理”或”标记-整理”算法来回收。

垃圾收集器

这里写图片描述
- Serial收集器：新生代收集器，使用 停止复制算法，使用一个线程进行GC，其它工作线程暂停。使用-XX:+UseSerialGC可以使用Serial+Serial Old模式运行进行内存回收（这也是虚拟机在Client模式下运行的默认值）

ParNew收集器：新生代收集器，使用 停止复制算法，Serial收集器的多线程版，用多个线程进行GC，其它工作线程暂停，关注缩短垃圾收集时间。使用-XX:+UseParNewGC开关来控制使用ParNew+Serial Old收集器组合收集内存；使用-XX:ParallelGCThreads来设置执行内存回收的线程数。
Parallel Scavenge 收集器：新生代收集器，使用 停止复制算法，关注CPU吞吐量，即运行用户代码的时间/总时间，比如：JVM运行100分钟，其中运行用户代码99分钟，垃圾收集1分钟，则吞吐量是99%，这种收集器能最高效率的利用CPU，适合运行后台运算（关注缩短垃圾收集时间的收集器，如CMS，等待时间很少，所以适合用户交互，提高用户体验）。使用-XX:+UseParallelGC开关控制使用 Parallel Scavenge+Serial Old收集器组合回收垃圾（这也是在Server模式下的默认值）；使用-XX:GCTimeRatio来设置用户执行时间占总时间的比例，默认99，即 1%的时间用来进行垃圾回收。使用-XX:MaxGCPauseMillis设置GC的最大停顿时间（这个参数只对Parallel Scavenge有效）
Serial Old收集器：老年代收集器，单线程收集器，使用 标记整理（整理的方法是Sweep（清理）和Compact（压缩），清理是将废弃的对象干掉，只留幸存的对象，压缩是将移动对象，将空间填满保证内存分为2块，一块全是对象，一块空闲）算法，使用单线程进行GC，其它工作线程暂停（注意，在老年代中进行标记整理算法清理，也需要暂停其它线程），在JDK1.5之前，Serial Old收集器与ParallelScavenge搭配使用。
Parallel Old收集器：老年代收集器，多线程，多线程机制与Parallel Scavenge差不错，使用 标记整理（与Serial Old不同，这里的整理是Summary（汇总）和Compact（压缩），汇总的意思就是将幸存的对象复制到预先准备好的区域，而不是像Sweep（清理）那样清理废弃的对象）算法，在Parallel Old执行时，仍然需要暂停其它线程。Parallel Old在多核计算中很有用。Parallel Old出现后（JDK 1.6），与Parallel Scavenge配合有很好的效果，充分体现Parallel Scavenge收集器吞吐量优先的效果。使用-XX:+UseParallelOldGC开关控制使用Parallel Scavenge +Parallel Old组合收集器进行收集。
CMS（Concurrent Mark Sweep）收集器：老年代收集器，致力于获取最短回收停顿时间，使用 标记清除算法，多线程，优点是并发收集（用户线程可以和GC线程同时工作），停顿小。使用-XX:+UseConcMarkSweepGC进行ParNew+CMS+Serial Old进行内存回收，优先使用ParNew+CMS（原因见后面），当用户线程内存不足时，采用备用方案Serial Old收集。
G1收集器（或者垃圾优先收集器Garbage-First）的设计初衷是为了尽量缩短处理超大堆（大于4GB）时产生的停顿。相对于CMS的优势而言是内存碎片的产生率大大降低。
G1将新生代，老年代的物理空间划分取消了,取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。

Java虚拟机类加载的过程

类加载的全过程分为五个阶段：加载、验证、准备、解析、初始化
这里写图片描述

加载

这个阶段可分为三段：

（1）加载二进制字节流

根据类的全限定名（包名+类名），获取此类的二进制字节流。

虚拟机规范没有指定二进制字节流从哪里读取，可以是class文件，可以是jar，也可以由动态代理在运行时生成，等等，只要是符合规范的字节流即可，由类加载器来决定字节流的来源。

（2）生成方法区的数据结构

根据前一步读取到的字节，在方法区创建运行时数据结构。

（3）创建Class实例

在Java堆中创建java.lang.Class的实例，作为程序代码访问类型数据的外部接口。
2. 验证

这个阶段验证读取到的二进制字节流是否符合虚拟机规范中Class文件的存储格式，如果不符合，抛出java.lang.VerifyError异常或其子类的异常。
3. 准备
可以查看此题
https://www.cnblogs.com/javaee6/p/3714716.html
在方法区，为static field分配内存，并设置其初始值。
这里设置的初始值，是Java虚拟机定义的对应于各种类型的默认值。
4. 解析

把类文件的常量池部分的符号引用转化为运行时常量池的直接引用。

类加载器树状组织结构示意图
这里写图片描述

参考

几张图轻松理解String.intern()

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM

JVMJVM内存模型一. 线程私有区域1. 程序计数器（Program Counter Register）：程序计数器是一个比较小的内存区域，用于指示当前线程所执行的字节码执行到了第几行，可以理解为是当前线程的行号指示器。字节码解释器在工作时，会通过改变这个计数器的值来取下一条语句指令。每个程序计数器只用来记录一个线程的行号，所以它是线程私有（一个线程就有一个程...
复制链接

扫一扫