1.JVM运行时结构

Java 运行时数据区域有程序计数器、Java虚拟机栈、本地方法栈、Java堆和方法区。其中前三个线程私有，随线程生而生，线程灭而灭；后面两个是线程间共享。

1.1 程序计数器

program counter register

较小

可看做是当前程序所执行的字节码的行号指示器。

在虚拟机的概念模型中，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器完成。

JVM的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现。（在任何一个确定的时刻，一个处理器（多核处理器时是指一个内核）都只会执行一条线程中的指令）。为了让线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器。各条线程之间的计数器互不影响，独立存储。

这类内存是“线程私有”内存。

若一个线程执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；
若执行的是Native方法，这个计数器值则为空（Null）

此内存区域是唯一一个在JVM规范中没有规定任何OutOfMemoryError情况的区域。

1.2 JVM栈

线程私有

生命周期与线程相同。

描述的是Java方法执行的内存模型：每个方法在执行的同时会创建一个栈帧（Stack Frame），用于存储局部变量表、操作数栈、动态链接、方法出口信息。每一个从方法调用直至执行完成的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。

局部变量表：存放了编译期可知的各种基本数据类型（boolean/byte/char/short/int/float/long/double，其中long和double占用两个局部变量空间（slot），其余的占用一个）、对象引用（reference类型，它不等同于对象本身，可能是一个指向对象起始抵制的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。局部变量表需要的内存空间在编译期间内完成分配。当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

JVM规范中，对这个区域规定了两种异常状况：

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

1.3 本地方法栈

Native Method Stack

与虚拟机栈发挥的作用是相似的。

虚拟机栈为虚拟机执行Java方法（字节码）服务。

本地方法栈为虚拟机使用到的Native方法服务。

本地方法栈也会抛出StackOverFlow和OutOfMemoryError异常。

1.4 Java堆

Java Heap

对大多数应用来说，Java堆是JVM所管理的内存中最大的一块。它是被线程所共享的一块内存区域，在虚拟机启动时创建。

唯一目的：存放Java对象实例。JVM规范中描述到：所有（现在没那么绝对了）的对象实例以及数组都要在堆上分配。

Java堆是垃圾收集器管理的主要区域，很多时候也叫做“GC堆”。

从内存回收的角度来看，由于现在收集器基本都采用分代收集，所以Java堆还可以细分为：新生代和老年代；
再细致一点新生代可以分为Eden空间、From Survivor空间、To Survivor空间等。
不过无论如何划分，都与存放的内容无关，无论哪个区域，存放的都仍然是对象实例。
进一步划分的目的是为了更好地回收和分配内存。

线程共享的Java堆可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer,TLAB）。进一步划分的目的只是为了更好地回收内存。

Java堆可以处在物理上不连续的内存空间中，只要逻辑上是连续的即可。既可实现成固定大小的，也可是可扩展的。

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

1.5 方法区

Method Area，别名：Non-Heap（非堆）

是各个线程共享的内存区域。

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

JVM规范对方法区的限制非常宽松：不需要连续的内存和可以选择固定大小和可扩展、还可以选择不实现垃圾收集。

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

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

1.6 运行时常量池

Runtime Constant Pool，是方法区的一部分。

class文件中除了有类的版本、字段、方法、接口等描述信息外，还有常量池（Constant Pool Table），用于存放编译器生成的各种字面量和符号引用。这部分内容在类加载后进入方法区的运行时常量池中存放。

JVM规范没有对运行时常量池做任何细节要求。

运行时常量池相对于class文件常量池的另外一个重要特征是具备动态性。

Java语言并不要求常量一定只有编译器才能生成，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中。——这种特性被开发人员利用最多的就是String类的intern()方法。

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

1.7 直接内存

Direct Memory

并不是虚拟机运行时数据区的一部分，也不是JVM规范中定义的内存区域。但它被频繁地使用，也可能导致OutOfMemoryError。

JDK1.4中新加入的NIO(New Input/Output)类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。避免了在Java堆和Native堆中来回复制数据。

本机直接内存的分配不会受到Java堆大小的限制，但还是会受到本机总内存大小以及处理器寻址空间的限制。

1.8总结

	共享/私有	出现的异常
程序计数器	私	没有规定任何OutOfMemory情况
Java虚拟机栈	私	OutOfMemoryError/StackOverflowError
本地方法栈	私	OutOfMemoryError/StackOverflowError
Java堆	共	OutOfMemoryError
方法区	共	OutOfMemoryError
运行时常量池		OutOfMemoryError
直接内存		OutOfMemoryError

1.9堆和栈的区别

	堆	栈
存放	所有的对象和数组实例	基本数据类型和引用变量，为执行Java方法服务
共享/私有	线程共享的	线程私有的，描述的是方法执行的内存模型
功能	主要用来存放对象的	主要是用来执行程序的
	存取速度的缓慢。可以在运行时动态地分配内存，生存期不需要提前告诉编译器，	存取速度更快；大小和生存期必须是确定的，因此缺乏一定的灵活性

1.10 StackOverflowStack和OutOfMemory(OOM)怎样发生?

1.10.1OutOfMemory

1、java.lang.OutOfMemory：Java heap space

首先查看是否是堆溢出或内存泄露。

要解决堆内存异常的情况一般的手段是通过内存映像分析工具(如Eclipse Memory Analyzer)对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是有必要的，也就是要先分清楚是内存泄露还是内存溢出。

如果是内存泄露，可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露的对象是怎么与GC Roots相连接导致进行垃圾回收时没能回收泄露对象所占的内存，有了泄露对象的信息和GC Roots引用链的信息，就可以准确地定位出泄露代码的位置。
如果没有发出内存泄露，也是说，内存中的对象确实还活着，那就应该去检查虚拟机的堆参数(-Xmx与-Xms)，与物理机器对比看是否还可以进一步扩大，从代码上检查是否存在某些对象声明周期过长、持有状态时间过长等，尝试减少程序运行内存消耗。

2、java.lang.OutOfMemory：PermGen space

说明是运行时常量池出现问题。需要扩大方法区来保证动态生成的class可以加载入内存。

3、java.lang.OutOfMemory

直接内存(直接内存并不是虚拟机运行数据区的一部分)可以通过-XX：MaxDirectMemorySize指定，如果不指定，则默认与Java堆最大值(-Xmx)一样。

虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但是它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是unsafe.allocateMemory().

由直接内存导致的内存溢出，一个明显的特征是Heap Dump文件中不会看见明显的异常，如果发现OOM之后Dump文件很小，而程序中又直接或间接使用了NIO，那就可以考虑检查一下是不是出现了方法区溢出。

1.10.2 StackOverflowStack

抛出StackOverflowStack异常是线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。

产生这种内存溢出与栈空间是否足够大并没有任何关系，反而给每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。

出现StackOverflowError异常有时有错误堆栈可以阅读，相对比较容易找到问题的所在。而且，如果使用虚拟机默认参数，在大多数情况下达到1000~2000是完全没有问题的，对于正常的方法调用(包括递归)，这个深度是完全没有问题的。但是如果建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。

2.Java自动内存管理

Java 的自动内存管理就是给对象的分配内存和回收分配给对象的内存。

2.1对象的内存分配

大方向，在堆上分配，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则不是百分百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机与内存相关的参数的设置。

2.1.1对象优先在Eden区分配

大多数情况下，对象在新生代Eden区中分配。

当Eden区没有足够的空间进行分配时，虚拟机将发起一次Minor GC。

收集日志参数：-XX:+PrintGCDetails，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各个区域分配情况。

参数：-XX:SurvivorRatio=8，决定了新生代中Eden区域一个Survivor区的空间比例是8:1。

2.1.2大对象直接进入老年代

大对象是指，需要大量连续内存空间的Java对象。典型的就是，很长的字符串以及数组。

经常出现大对象容易导致内存还有不少空间时，就提前出发垃圾收集以获取足够的连续空间来“安置”它们。

参数：-XX:PretenureSizeThreshold，令大于这个设置值的对象直接在老年代分配。

这个参数只对Serial和ParNew两款收集器有效。

目的是避免在Eden区以及两个Survivor区之间发生大量的内存复制（新生代采用复制算法收集内存）。

2.1.3 长期存活的对象将进入老年代

内存回收必须识别哪些对象应放在新生代，哪些对象应放在老年代中。

所以，虚拟机给每个对象定义了一个对象年龄（Age）计数器。

如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能够被Survivor容纳的话，将被移动到Survivor空间中，并且设置对象年龄为1.

对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就会进入老年代中。

对象进入老年代的阈值，可通过参数-XX:MaxTenuringThreshold设置。

2.1.4动态判断对象年龄

虚拟机并不是永远要求对象的年龄必须达到了MaxTenuringThreshold才能进入老年代，如果在Survivor空间中相同年龄所有对象大小总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可直接进入老年代。无需等到年龄阈值。

2.1.5空间担保

在发生Minor GC之前，虚拟机会先检查老年代最大的可用连续空间是否大于新生代所有对象的总空间。

如果这个条件成立，那么Minor GC可以确保是安全的。
如果不成立，虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。
- 若允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小。
  - 若大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的。
  - 若小于，或HandlePromotionFailure不允许冒险，那这时要改为进行一次Full GC。
  - 但大部分的HandlePromotionFailure开关打开，避免Full GC过于频繁。

3.JVM实例

每当一个Java程序运行时，都会有一个对应的JVM实例，只有当程序运行结束后，这个JVM才会退出。

JVM实例通过调用类的main()方法来启动一个Java程序，而这个main()方法必须是公有的、静态的且返回值为void的方法，该方法接受一个字符串数组的参数，只有同时满足这些条件才可以作为程序的入口方法。

4.HotSpot虚拟机中对象的创建

4.1语言层面上

创建对象（克隆、反序列化）通常仅仅是一个new关键字

4.2虚拟机中

当虚拟机遇到一条new指令时，

4.3.1类加载检查

首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。

4.3.2为新生对象分配内存

对象所需的内存大小在类加载完成后便可完全确定。

分配方式：

指针碰撞（Bump the Pointer）：假设Java堆是绝对规整的，所有用过的内存都放在一边，空闲的放在另一边，中间放着一个指针作为分界点的指示器，那分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。

空闲列表（Free List）：若Java堆中的内存不是规整的，那虚拟机就需维护一个列表，记录上哪些内存块是可用的，再分配的时候找到一块足够大的空间划分给对象实例，并更新表上的记录。

选择哪种分配方式由Java堆是否规整决定。

Java堆是否规整由所采用的垃圾收集器是否带有压缩整理的功能决定。

在使用Serial、ParNew等带compact过程的收集器时，系统采用的分配算法是指针碰撞；
在使用CMS这种基于Mark-Sweep算法的收集器时，通常采用空闲列表。

对象创建在虚拟机中是非常频繁的行为，移动指针在并发情况下也不是线程安全的。

解决办法：

对分配内存空间的动作进行同步处理——实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性
把内存分配的动作按照线程划分在不同的空间中进行，即每个线程在Java堆中总预先分配一小块内存，成为本地线程分配缓冲（Thread Local Allocation Buffer,TLAB）,哪个线程要分配内存，就在那个线程的TLAB上分配，只有TLAB用完，并分配新的TLAB时。才需要同步锁定。
虚拟机是否使用TLAB，可以通过-XX:+/-UseTLAB参数来设定。

4.3.3初始化内存空间

内存分配完之后，虚拟机需要将分配到内存的空间都初始化为零值（不包括对象头）。

如果使用TLAB这一步也可以在TLAB分配时进行。

这一操作保证了对象的实例字段在Java代码中可以不赋初值就直接使用。程序能访问到这些字段的数据对应的零值。

4.3.1虚拟机对对象进行必要的设置。

这些信息存放在对象头（Object Head）中。

以上完成之后，从虚拟机的角度看，一个新的对象已经生成了。

4.4 Java程序看

上述完成后，对象的创建才刚刚开始，——<init>方法还没有执行，所有字段都还为零。

所以，一般来说（由字节码是否跟随invokespecial指令所决定），执行new指令之后会接着执行<init>方法，把对象按照程序员的意愿进行初始化，这样一个真正可用的对象才算安全产生。

5.HotSpot虚拟机中对象的内存布局

对象在内存中存储的布局可以分为3块区域：对象头（Header）、实例数据（Instance data）、对齐填充（Padding）。

5.1对象头

包括两部分信息：

5.1.1用于存储对象自身的运行时数据（Mark Word）

哈希码
GC分代年龄
锁状态标志
线程持有的锁
偏向线程ID
偏向时间戳

对象头信息时与对象自身定义的数据无关的额外存储成本。Mark Word会根据对象的状态复用自己的存储空间，它非固定。

存储内容	标志位	状态
对象哈希码、对象分代年龄	01	未锁定
指向锁记录的指针	00	轻量级锁定
指向重量级锁的指针	10	膨胀（重量级锁定）
空，不需要记录信息	11	GC标记
偏向线程ID、偏向时间戳、对象分代年龄	01	可偏向

5.1.2类型指针

即对象指向它的类元数据的指针。

虚拟机通过这个指针来确定这个对象是哪个类的实例。

并不是所有的虚拟机实现都必须在对象数据上保留类型指针，即查找对象的元数据信息并不一定要通过对象本身。

若对象头是一个Java数组，那么对象头中还必须有一块用于记录数组长度的数据。（因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数组大小）。

5.2实例数据

对象真正存储的有效信息，也是程序代码中所定义的各种类型的字段内容。

这部分的存储顺序收到虚拟机分配策略参数（FieldsAllocationStyle）和字段在Java源码中定义顺序的影响。

HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、oops（ordinary object pointers）。

从分配策略来看，相同长度的字段总是被分配到一起。
在满足这个前提下，在父类中定义的变量会出现在子类之前。
若CompactFields参数值为true（默认），那么子类中较窄的变量也可能会插入到父类变量的空隙之中。

5.3对齐填充（非必需）

仅仅是占位符的作用。

由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍。

而对象头部分正好是8字节的倍数（1倍或2倍——32或64位，由虚拟机是32还是64确定），因此当独享实例数据部分没有对齐时，就需要通过对齐填充来补全。

6.对象的访问定位

Java程序需要通过栈上的reference数据来操作堆上的具体对象。

reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以对象访问也是取决于VM实现而定的。

目前主流的访问方式有：使用句柄和直接指针。

6.1使用句柄

Java堆中会划分出一块内存来作为句柄池。

reference中存放的就是对象的句柄地址。而句柄中包含了对象实例数据与类型数据各自的具体地址信息。

6.2直接指针

Java堆对象的布局必须考虑如何防止访问类型数据的相关信息，而reference中存储的直接就是对象地址。

6.3对比

句柄	直接指针
reference中存的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针	速度更快，节省了一次指针定位的开销
（垃圾收集时移动对象的行为很普遍）	（对象访问很频繁，积少成多）

JVM运行时结构、Java内存管理、JVM实例、HotSpot VM对象的创建、内存布局和访问定位相关推荐

JVM运行时对它所管理的内存划分区域（为面试准备）
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同数据区域.这些区域都有着各自的用途,接下来,我会逐一介绍.下图是Java虚拟机运行时的数据区域划分: Java虚拟机运行 ...
Java 虚拟机学习笔记 | 类加载过程和对象的创建流程
前言创建对象是 Java 语言绕不开的话题,那么对象是如何创建出来的呢?我们今天就来聊一聊.对象创建第一步就是检查类是否加载,而类的加载又牵扯到类的加载过程.如果单说对象的创建而绕开类的加载过程,感 ...
Java内存管理：Java内存区域 JVM运行时数据区
Java内存管理:Java内存区域 JVM运行时数据区在前面的一些文章了解到javac编译的大体过程.Class文件结构.以及JVM字节码指令. 下面我们详细了解Java内存区域:先说明JVM规范定 ...
JVM运行时的内存结构
我们都知道,JVM的垃圾收集机制能够帮开发者自动管理内存,了解JVM运行时的内存结构是理解垃圾收集机制的前提.本文主要简单介绍JVM运行时的内存结构. [JVM运行时内存中不同的数据区域] 一.PC寄 ...
12.JDK1.8 JVM运行时数据区域概览、各区域介绍、程序计数器、Java虚拟机栈、本地方法栈、堆、堆空间内存分配（默认情况下）、字符串常量池、元数据区、jvm参数配置
12.JDK1.8 JVM运行时数据区域概览 12.1.JDK1.8 JVM运行时数据区域概览 12.2.各区域介绍 12.3.各区域介绍 12.3.1.程序计数器 12.3.2.Java虚拟机栈 1 ...
[转]JVM运行时内存结构
[转]http://www.cnblogs.com/dolphin0520/p/3783345.html 目录[-] 1.为什么会有年轻代 2.年轻代中的GC 3.一个对象的这一辈子 4.有关年轻代的 ...
2020 idea 查看内存消耗_查看运行时某个java对象占用JVM大小及通过idea查看java的内存占用情况...
一.如果想看运行时某个java对象占用JVM内存大小,可以先将对象转换成字节类型,然后计算: List bizGroupRelatedEventInfos = bizEventVersionMappe ...
java runtime类 heap_Java 进阶（一） JVM运行时内存模型
1.JVM运行时数据区域的划分 a.程序计数器(Program Counter Register) 一块较小的内存空间,可以看作是当前线程所执行的字节码的行号指示器.每个线程拥有独立的一个计数器,如果 ...
尝试用HSDB分析JVM运行时内存理解Java多态实现机制
测试代码 // 接口 package ziya; public interface TestParent {void show(); }package ziya; public class Paren ...

JVM运行时结构、Java内存管理、JVM实例、HotSpot VM对象的创建、内存布局和访问定位