10分钟快速了解 jvm 基础知识

前言

快速的了解Jvm相关知识。

内存模型

开局一张jdk8 JVM图，然后是JDK低版本的JVM图。

这里线程私有的区域有三个：程序计数器、本地方法栈、虚拟机栈。这三个区域随着线程创建而初始化，线程毁灭而自然的被回收，不需要回收算法来帮助回收。方法区和堆区会被垃圾回收算法回收。但这里要注意，虽然垃圾回收器不会回收其他区域的对象，但其他区域依旧会发生OOM，仔细想想也可以理解，因为发生OOM跟垃圾回收根本就是两回事，OOM是因为区域没有内存可用，垃圾回收主要是为了清空不需要的内存，其他结束的线程产生的垃圾对象可以被回收，但线程还没执行完而发生的OOM不能回收，不然线程也就执行出问题。

程序计数器

作用：在CPU内部，运行速度最快的区域，因为多线程环境下，线程可以来回切换，切换后需要找到一开始Java执行的位置，因此程序计数器要线程私有，并且存储正在上一次执行到的虚拟机字节码指令的地址，获得线程后继续执行下去，执行本地方法该值为空。

• 线程：每一个线程都有一个独立的程序计数器
• 是否GC：不存在GC情况，唯一不会有OutOfMemoryError 情况的区域

jvm stack 虚拟机栈

作用：方法之间存在调用情况，每个方法在执行的同时都会创建一个栈帧(Stack Frame，是方法运行时的基础数据结构)，用来记录调用的其它方法，调用方法入栈，方法执行结束出栈。栈帧里存储来方法的基本类型的局部变量，例如int、short、boolea等，当然也有一些对象引用存储在栈里，一个方法执行结束就会释放。

局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)

• 线程：每一个线程都有一个独立的虚拟机栈
• 是否GC：不会
• StackOverflowError：调用的方法深度过大，抛StackOverflowError异常
• OutOfMemoryError：扩展栈长度时，内存不够抛OutOfMemoryError异常，因为这一块区域可以是动态的，也可以是固定长度的

问题：

• 为什么Java对象引用在栈里面
  主要是栈被设计成是一个可以快速访问的区域，速度很快，通过栈指针比较方便上下移动，所以运行代码前，Java 虚拟机需要知道栈内所有数据的确切大小及生命周期，这也是为什么存储基本局部变量、对象引用。

• 上面的Java对象引用具体在那个位置呢？
  答案就是栈帧信息的局部变量表中

• 栈会不会被垃圾回收？
  栈是运行时单位，线程私有，生命周期和线程一致，存储的都是跟线程相关的数据，我觉得会被垃圾回收，因方法中的基本局部变量是存到栈中的，一个线程执行完来，数据就会被回收，但是一般垃圾回收都发生在Java堆中，所以也很奇怪。

本地方法栈（Native Method Stack）

本地方法栈与虚拟机栈所发挥的作用是非常相似的，本地方法栈则为虚拟机使用到的 Native 方法服务，JNI 类本地方法最著名的应该是 System.currentTimeMillis() ，本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常。

• 线程：每一个线程都有一个独立的本地方法栈
• 是否GC：不会
• StackOverflowError：会
• OutOfMemoryError：会

Java 堆（Java Heap）

此区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存，Java 堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。

• 线程：线程共有
• 是否GC：会
• OutOfMemoryError：会有，GC主要场所

方法区（jdk8叫元数据区）

方法区（Method Area）与 Java 堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做 Non-Heap（非堆），方法区包括类信息、常量、静态变量等，是JVM规范。 方法区是jvm规范里面的概念。jdk 1.7是永久代来实现的，jdk 1.8则是由元数据区加堆一起实现的。

• 线程：线程共有
• 是否GC：会，针对常量池的回收和对类型的卸载。
• OutOfMemoryError：当方法区无法满足内存分配需求时，将抛出 OutOfMemoryError 异常。

JDK8 之前，Hotspot 中方法区的实现是永久代（Perm），JDK8 开始使用元空间（Metaspace），以前永久代所有内容的字符串常量移至堆内存，其他内容移至元空间，元空间直接在本地内存分配。

为什么要使用元空间取代永久代的实现？

• 字符串存在永久代中，容易出现性能问题和内存溢出。
• 类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出 现永久代溢出，太大则容易导致老年代溢出。
• 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
• 将 HotSpot 与 JRockit 合二为一。

永久代的垃圾手机主要回收两部分内容：废弃常量和无用的类。 回收废弃常量与回收Java堆中的对象非常相似。以常量池中字面量的回收为例，若字符串“abc”已经进入常量池中，但当前系统没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用该字面量，若发生内存回收，且必要的话，该“abc”就会被系统清理出常量池。常量池中其他的类（接口）、方法、字段的符号引用与此类似。

无用的类需要满足3个条件：

（1）该类所有的实例都已经被回收，即Java堆中不存在该类的任何实例；
（2）加载该类的ClassLoader已经被回收；
（3）该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，此处仅仅是“可以”。

字符串常量池

String作为最基础的数据类型，大量频繁的创建字符串，耗费高昂的时间与空间代价，极大程度地影响程序的性能。

引用计数法和可达性分析

引用计数法是通过判断是否有引用指向这个对象，如果没有就说明这个对象不会再被使用了，如果有就说明这个对象可能还会继续被使用，这种通过引用是否存在的方法就叫做引用计数法，但这个方法存在一个问题就是无法解决对象循环引用的问题，因此又出现了可达性分析的方法来判断对象是否可以被会回收。

可达性分析通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。GC Roots的对象包括下面几种：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象。
• 方法区中类静态属性引用的对象。
• 方法区中常量引用的对象。
• 本地方法栈中JNI（即一般说的Native方法）引用的对象。

参考博客

Java内存区域（运行时数据区域）和内存模型（JMM）