深入理解JVM学习笔记（一）

一、java内存区域

1. 运行时数据区域

1.1 程序计数器

  程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型中，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环跳转，异常处理，线程恢复等基础功能都需要依赖这个计数器来完成。
程序计数器是线程私有的，每个线程都有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储。
  如果线程正在执行的是一个 Java 方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是 Natvie 方法，这个计数器值则为空（Undefined）。此内存区域是唯一一个在Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。

1.2 java虚拟机栈

  与程序计数器一样， Java 虚拟机栈（ Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。

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

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

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

  在 Java 虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出 StackOverflowError 异常；如果虚拟机栈可以动态扩展（当前大部分的 Java 虚拟机都可动态扩展，只不过 Java 虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出 OutOfMemoryError 异常。

1.3 本地方法栈

  本地方法栈（ Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是虚拟机栈为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的 Native方法服务。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError 和OutOfMemoryError 异常。

1.4 java堆

  对于大多数应用来说， Java 堆（ Java Heap）是 Java 虚拟机所管理的内存中最大的一块。 Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。这一点在 Java 虚拟机规范中的描述是：所有的对象实例以及数组都要在堆上分配，但是随着 JIT 编译器的发展与逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。

  Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC 堆（ ” Garbage Collected Heap）。如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以 Java 堆中还可以细分为：新生代和老年代；再细致一点的有 Eden 空间、 From Survivor空间、 To Survivor 空间等。如果从内存分配的角度看，线程共享的 Java 堆中可能划分出多个线程私有的分配缓冲区（ Thread Local Allocation Buffer， TLAB）。不过，无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。

  根据 Java 虚拟机规范的规定， Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx 和-Xms 控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出 OutOfMemoryError 异常。

1.5 方法区

  方法区（ Method Area）与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），目的应该是与 Java 堆区分开来
。
  HotSpot虚拟机的设计团队把GC分代收集扩展至方法区，或者说使用永久代来代替方法区。这样HotSpot的垃圾收集器就可以像管理java堆一样管理这部分内存，但现在Hotspot也有放永久代并逐步改为采用Native Memory来实现方法区的规划了，在JDK1.7中，已经把永久代中的字符串常量池移出。

  Java 虚拟机规范对这个区域的限制非常宽松，除了和 Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的

  根据 Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出 OutOfMemoryError 异常。

1.6 运行时常量池

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

  除了保存 Class 文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。

  运行时常量池相对于 Class 文件常量池的另外一个重要特征是具备动态性， Java 语言并不要求常量一定只能在编译期产生，也就是并非预置入 Class 文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是 String 类的intern()方法。

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

1.7 直接内存

  直接内存（ Direct Memory）并不是虚拟机运行时数据区的一部分，也不是 Java 虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致 OutOfMemoryError 异常出现。

  在 JDK 1.4 中新加入了 NIO （ New Input/Output）类，引入了一种基于通道（ Channel）与缓冲区（ Buffer）的 I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在 Java 堆和 Native 堆中来回复制数据。

  显然，本机直接内存的分配不会受到 Java 堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括 RAM 及 SWAP 区或者分页文件）的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx 等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），从而导致动态扩展时 出现 OutOfMemoryError 异常。

2.Hotspot虚拟机对象

以虚拟机HotSpot和常用的内存区域java堆为例，深入探讨HotSpot在java堆中对象分配、布局和访问的全过程。

2.1对象的创建

当 jvm 遇到new指令时:

• 1.首先检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析、和初始化过。如果没有那就表明该类还没有被虚拟机加载无法创建，需要先执行类的加载过程。

• 2.类加载检查之后，jvm在java堆中按照 “指针碰撞” 或者 “空闲列表” 的方式为新生的对象分配内存，分配内存的大小在类加载完成后便可完全确定。

指针碰撞：在Java堆内存绝对规整的前提下，所有已使用的内存放在一边，空闲的在另一边，中间放着一个指针作为分界点的指示器，那所分配的内存仅仅就是把那个指针向空闲的那边挪动一段与对象大小相等的距离

空闲列表：如果Java堆内存并不是规整的，已使用的内存和未使用的内存交叉，那就没办法按照指针碰撞的方式为新生对象分配内存，jvm必须维护一个列表，记录哪些内存块是可用的，再分配的时候从列表中找到一块足够大的空间会分给对象实例，并更新列表记录，这种分配方式成为“空闲列表”。

  除如何划分可用空间外，还需考虑的问题是对象创建在jvm中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也会引发线程安全问题，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题有两个方案：一种是对分配内存空间的操作进行同步处理——实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性；另一种是把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在Java堆中预先分配一小块内存，成为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB）。哪个线程要分配就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时,才需要同步锁.

• 3.内存分配完成之后，jvm需要将分配到的内存空间进行初始化零值（不包含对象头），如果使用TLAB,这一过程也可提前至TLAB分配时进行。该步骤保证了对象的实例字段在Java代码中可以不赋初始值就可以直接使用，程序能访问到这些字段的数据类型所对应的零值。（实例变量无需初始化即可被程序使用，区别于局部变量的必须初始化才能被程序使用）
• 4.接下来对对象进行必要的设置：这个对象是哪个类的实例、如何找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息、这些信息存放于对象的对象头信息中。
• 5.开始执行方法进行对象的初始化，按照程序员的意愿初始化对象，至此一个真正可用的对象才算产生。

2.2 对象的内存布局

  创建完对象后，对象对分配给自己的内存是如何布局的呢？
  对象在堆内存中的布局可分为三部分：对象头（Header），实例数据(Instance Data)，对齐填充(Padding)。
对象头：对象头包含两部分，第一部分存储自身运行时数据，如哈希码，GC分代年龄、锁状态标志、线程持有锁、偏向线程ID、偏向时间戳等，官方称为“Mark Word”。第二部分是类型指针，即对象指向它的类元数据的指针，通过此指针来确定是哪个类的对象。
实例数据：存储对象中的各类型的字段内容。无论是从父类继承来的还是在子类中定义的。
对齐填充：并不是必然存在的，当对象实例数据部分没有对齐时，进行对齐补全。

2.3 对象的访问定位

  我们需要通过栈帧中局部变量表所存储的对象引用来对堆内存中的对象实例进行访问或操作。目前主流的访问方式有使用句柄和直接指针两种。

• 如果通过句柄来访问对象，Java堆中会划出一块内存作为句柄池，reference中存储句柄地址，而句柄中包含对象的实例数据与类型数据各自的地址。
  
• 直接指针，就是指reference中直接存储对象的地址。但是Java堆对象的布局中就必须考虑如何防止访问类型数据相关信息。
  

  这两种对象的访问方式各有优势，使用句柄访问最大的好处就是reference中存储的是稳定的句柄地址，在对象被移动时，只用修改句柄中的实例数据指针，而reference本身不需要修改！

  而直接访问对象方式的好处就是，减少一次指针定位的时间开销，由于对象的访问是非常频繁的，因此这类开销积少成多也是一项非常的执行成本。