本文深入介绍JVM，涵盖内存模型（JMM），包括其特性、内存交互操作等；阐述运行时数据区，如堆、方法区、栈等的结构与功能；讲解垃圾回收（GC），包含常见收集器、算法及对象存活分析；还介绍JVM管理，如常用设置、基础命令和分析工具，以及故障处理方式。
JVM简述
什么是JVM
- JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
- Java虚拟机包括：字节码指令集、寄存器、堆、栈、垃圾回收、存储方法域等。
- JVM屏蔽了与具体操作系统平台相关的信息，使Java程序只需生成在Java虚拟机上运行的目标代码（字节码）,就可以在多种平台上不加修改地运行。
- JVM在执行字节码时，实际上最终还是把字节码解释成具体平台上的机器指令执行
内存模型（JMM）
什么是JMM
- JMM是 Java 内存模型（Java Memory Model）的缩写，它是 Java 虚拟机（JVM）的一部分，用于解决多线程环境下内存管理和数据一致性问题。
- JMM 规定了线程和主内存之间的交互规则，确保在不同硬件和操作系统平台上运行的 Java 程序能够正确地共享和更新数据
- JMM 的主要作用包括
- 定义线程和主内存之间的抽象关系，使得线程间的共享变量能够在主内存中共享，同时每个线程都有自己的本地内存，其中存储了该线程的读/写共享变量的副本
- 提供机制如 monitorenter 和 monitorexit 来保证代码块的原子性，这可以通过 synchronized 关键字来实现
- 屏蔽底层硬件细节，为开发者提供一套通用的读写内存数据的规范，使程序可以在不同的硬件和操作系统平台上运行而保持一致性
JMM三大特性
- 原子性。一个或多个操作，要么全部执行，要么全部不执行（执行的过程中是不会被任何因素打断的）
- 可见性。只要有一个线程对共享变量的值做了修改，其他线程都将马上收到通知，立即获得最新值
- 有序性。在本线程内观察，所有的操作都是有序的
内存模型
主内存
- Java 内存模型规定了所有变量都存储在主内存(Main Memory)中。
- 此处的主内存与物理硬件的主内存 RAM 名字一样，两者可以互相类比，但此处仅是虚拟机内存的一部分
工作内存
- 每条线程都有自己的工作内存(Working Memory，又称本地内存，可与CPU高速缓存类比)
- 线程的工作内存中保存了该线程使用到的主内存中的共享变量的副本拷贝。
- 线程对变量的所有操作都必须在工作内存进行，而不能直接读写主内存中的变量。
- 工作内存是 JMM 的一个抽象概念，并不真实存在
内存之间的交互操作
简述
- 关于主内存和工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，
- Java 内存模型中定义了 8 种 操作来完成，虚拟机实现必须保证每一种操作都是原子的、不可再拆分的（double和long类型例外）
内存的八种操作
- 作用于工作内存
- Store（存储）。把工作内存中的变量传送到主内存中
- Load（载入）。把 read 读取的值放到工作内存中的副本变量中
- Use（使用）。把工作内存的值传递给执行引擎，当虚拟机遇到一个需要使用这个变量的指令时，就会执行这个动作
- Assign（赋值）。把执行引擎获取到的值赋值给工作内存中的变量，当虚拟机栈遇到给变量赋值的指令时，就执行此操作
- 作用于主内存
- Read（读取）。将共享变量从主内存传送到线程的工作内存中
- Write（写入）。把从工作内存中 store 传送过来的值写到主内存的变量中
- Lock（锁定）。把变量标记为线程独占状态
- Unlock（解锁）。它将释放独占状态
内存先行发生原则
- 程序次序规则： 一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作
- 管程锁定规则： 一个unLock操作先行发生于后面对同一个锁的lock操作
- volatile变量规则： 对一个变量的写操作 happens-before 后面对这个变量的读操作
- 传递规则： 如果操作A 先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A 先行发生于操作C
- 线程启动规则： Thread对象的 start() 方法先行发生于此线程的每一个动作
- 线程中断规则： 对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生
- 线程终结规则： 线程中所有的操作都先行发生于线程的终止检测。我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行
- 对象终结规则： 一个对象的初始化完成先行发生于它的 finalize() 方法的开始
内存屏障
简述
- Java 中如何保证底层操作的有序性和可见性？可以通过内存屏障。
- 内存屏障是被插入两个 CPU 指令之间的一种指令，用来禁止处理器指令发生重排序（像屏障一样），从而保障有序性的。
- 为了达到屏障的效果，它也会使处理器写入、读取值之前，将主内存的值写入高速缓存，清空无效队列，从而保障可见性
常见的四种屏障
-
LoadLoad 屏障
对于以下的语句，在Load2及后续读取操作要读取的数据被访问前，保证Load1要读取的数据被读取完毕 Load1; LoadLoad; Load2; -
StoreStore 屏障
对于以下的语句，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见 Store1; StoreStore; Store2; -
LoadStore 屏障
对于以下的语句，在Store2及后续写入操作被执行前，保证Load1要读取的数据被读取完毕 Load1; LoadStore; Store2; -
StoreLoad 屏障
对于以下的语句，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。 它的开销是四种屏障中最大的（冲刷写缓冲器，清空无效化队列）。 在大多数处理器的实现中，这个屏障也被称为全能屏障，兼具其它三种内存屏障的功能 Store1; StoreLoad; Load2
JVM运行时数据区
简述
- 运行时数据区包括：程序计数器(PC寄存器)、Java虚拟机栈、Java堆、方法区、运行时常量池、本地方法栈等等
- 其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程一一对应的数据区域会随着线程开始和结束而创建和销毁
- 线程私有：程序计数器、栈、本地栈
- 线程共享：堆、堆外内存（永久代或元空间、代码缓存）
- 栈是运行时的单位，而堆是存储的单位
- 栈解决程序的运行问题，即程序如何执行，或者说如何处理数据
- 堆解决的是数据存储的问题，即数据怎么放、放在哪
堆
简述
- 用来存放应用系统创建的对象和数组，所有线程共享Java堆
- GC主要管理堆空间，对分代GC来说，堆也是分代的
- 运行期动态分配内存大小，自动进行垃圾回收
- 为了进行高效的垃圾回收，虚拟机把堆内存逻辑上划分成三块区域（分代的唯一理由就是优化 GC 性能）
- 堆内存分配比率：新生代和老年代内存比例大概是1：2
- 效率相对较慢
内存划分
新生带（年轻代）
-
简述
- 新对象和没达到一定年龄的对象都在新生代
- 年轻一代被分为三个部分：(Eden Memory，伊甸园)和两个幸存区(Survivor Memory，被称为from/to或s0/s1)，默认内存分配比例是8:1:1
-
分析
- 大多数新创建的对象都位于 Eden 内存空间中
- 当 Eden 空间被对象填充时，执行Minor GC，并将所有幸存者对象移动到一个幸存者空间中
- Minor GC 检查幸存者对象，并将它们移动到另一个幸存者空间。所以每次，一个幸存者空间总是空的
- 经过多次 GC 循环后存活下来的对象被移动到老年代。通常，这是通过设置年轻一代对象的年龄阈值来实现的，然后他们才有资格提升到老一代
老年代（养老区）
- 被长时间使用的对象，老年代的内存空间应该要比年轻代更大
- 旧的一代内存包含那些经过许多轮小型 GC 后仍然存活的对象。通常，垃圾收集是在老年代内存满时执行的。老年代垃圾收集称为主GC，通常需要更长的时间
- 大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝
元空间（JDK1.8之前叫永久代）
- 像一些方法中的操作临时对象等，JDK1.8之前是占用JVM内存，JDK1.8之后直接使用物理内存
- 不管是 JDK8 之前的永久代，还是 JDK8 及以后的元空间，都可以看作是 Java 虚拟机规范中方法区的实现
- 虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫 Non-Heap（非堆），目的应该是与 Java 堆区分开
内存分配策略
- 对象优先在 Eden 分配
- 大多数情况下，对象在新生代 Eden 区分配，当 Eden 区空间不够时，发起 Minor GC
- 大对象直接进入老年代
- 大对象是指需要连续内存空间的对象，最典型的大对象是那种很长的字符串以及数组
- -XX:PretenureSizeThreshold，大于此值的对象直接在老年代分配，避免在 Eden 区和 Survivor 区之间的大量内存复制
- 长期存活的对象进入老年代
- 为对象定义年龄计数器，对象在 Eden 出生并经过 Minor GC 依然存活，将移动到 Survivor 中，年龄就增加 1 岁，增加到一定年龄则移动到老年代中
- -XX:MaxTenuringThreshold 用来定义年龄的阈值
- 动态对象年龄判定
- 虚拟机并不是永远地要求对象的年龄必须达到 MaxTenuringThreshold 才能晋升老年代
- 如果在 Survivor 中相同年龄所有对象大小的总和大于 Survivor 空间的一半，则年龄大于或等于该年龄的对象可以直接进入老年代，无需等到 MaxTenuringThreshold 中要求的年龄
- 空间分配担保
堆内存设置
- 简述
- 默认情况下，初始堆内存大小为：电脑内存大小/64
- 默认情况下，最大堆内存大小为：电脑内存大小/4
- 通常会将 -Xmx 和 -Xms 两个参数配置为相同的值，其目的是为了能够在垃圾回收机制清理完堆区后不再需要重新分隔计算堆的大小，从而提高性能
- 常见设置
- -Xmx 用来表示堆的起始内存，等价于 -XX:InitialHeapSize
- -Xms 用来表示堆的最大内存，等价于 -XX:MaxHeapSize
- 默认情况下新生代和老年代的比例是 1:2，可以通过 –XX:NewRatio 来配置
- 新生代中的 Eden:From Survivor:To Survivor 的比例是 8:1:1，可以通过-XX:SurvivorRatio来配置
- 开启了 -XX:+UseAdaptiveSizePolicy，JVM 会动态调整 JVM 堆中各个区域的大小以及进入老年代的年龄，此时 –XX:NewRatio 和 -XX:SurvivorRatio 将会失效。JDK 8 是默认开启。不要随意关闭-XX:+UseAdaptiveSizePolicy，除非对堆内存的划分有明确的规划
- 设置新生代晋升老年代的周期，-XX:PetenureSizeThreshold,默认是15次
拓展
对象逃逸分析
- 简述
- 逃逸分析(Escape Analysis)是目前 Java 虚拟机中比较前沿的优化技术。
- 这是一种可以有效减少 Java 程序中同步负载，和内存堆分配压力的跨函数全局数据流分析算法。
- 通过逃逸分析，Java Hotspot 编译器能够分析出一个新的对象的引用的使用范围，从而决定是否要将这个对象分配到堆上
- 在 JDK 6u23版本之后，HotSpot 中默认就已经开启了逃逸分析。如果使用较早版本，可以通过-XX"+DoEscapeAnalysis显式开启
- 分析
- 当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸
- 当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中，称为方法逃逸
- 使用逃逸分析，编译器可以对代码做优化
- 栈上分配。将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配
- 标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而存储在 CPU 寄存器
- 同步省略（消除）。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步
方法区（元数据空间）
简述
- 方法区（Method Area）与 Java 堆一样，是所有线程共享的内存区域
- 虽然 Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫 Non-Heap（非堆），目的应该是与 Java 堆区分开
- 运行时常量池（Runtime Constant Pool）是方法区的一部分
- Class 文件中除了有类的版本/字段/方法/接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将类在加载后进入方法区的运行时常量池中存放。
- 运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的是 String.intern()方法。
- 受方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 异常
- 方法区的大小和堆空间一样，可以选择固定大小也可选择可扩展，方法区的大小决定了系统可以放多少个类，如果系统类太多，导致方法区溢出，虚拟机同样会抛出内存溢出错误
- JVM 关闭后方法区即被释放
方法区内存设置
- 元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 指定
方法区内部结构
简述
- 方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等
结构
-
类型信息
- 类型的完整有效名称（全名=包名.类名）
- 类型直接父类的完整有效名（对于 interface或是 java.lang.Object，都没有父类）
- 类型的修饰符（public，abstract，final 的某个子集）
- 类型直接接口的一个有序列表
-
域（Field）信息
- JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
- 域的相关信息包括：域名称、域类型、域修饰符（public、private、protected、static、final、volatile、transient 的某个子集）
-
方法（Method）信息
- 方法的返回类型
- 方法参数的数量和类型
- 方法的修饰符（public，private，protected，static，final，synchronized，native，abstract 的一个子集）
- 方法的字符码（bytecodes）、操作数栈、局部变量表及大小（abstract 和 native 方法除外）
- 异常表（abstract 和 native 方法除外）
运行时常量池
简述
- 运行时常量池（Runtime Constant Pool）是方法区的一部分，理解运行时常量池的话，我们先来说说字节码文件（Class 文件）中的常量池（常量池表）
- 一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外，还包含一项信息那就是常量池表（Constant Pool Table），包含各种字面量和对类型、域和方法的符号引用
明细
- 在加载类和结构到虚拟机后，就会创建对应的运行时常量池
- 常量池表（Constant Pool Table）是 Class 文件的一部分，用于存储编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
- JVM 为每个已加载的类型（类或接口）都维护一个常量池。池中的数据项像数组项一样，是通过索引访问的
- 运行时常量池中包含各种不同的常量，包括编译器就已经明确的数值字面量，也包括到运行期解析后才能够获得的方法或字段引用。此时不再是常量池中的符号地址了，这里换为真实地址
- 当创建类或接口的运行时常量池时，如果构造运行时常量池所需的内存空间，超过了方法区所能提供的最大值，则 JVM 会抛出 OutOfMemoryError 异常
方法区的垃圾回收
- 方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型
- HotSpot 虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收
- 判定一个类型是否属于“不再被使用的类”，需要同时满足三个条件
- 该类所有的实例都已经被回收，也就是 Java 堆中不存在该类及其任何派生子类的实例
- 加载该类的类加载器已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如 OSGi、JSP 的重加载等，否则通常很难达成
- 该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法
拓展
Java8 之后方法区的变化
- 移除了永久代（PermGen），替换为元空间（Metaspace）
- 永久代中的 class metadata 转移到了 native memory（本地内存，而不是虚拟机）
- 永久代中的 interned Strings 和 class static variables 转移到了 Java heap
- 永久代参数 （PermSize MaxPermSize） -> 元空间参数（MetaspaceSize MaxMetaspaceSize）
方法区在 JDK6、7、8中的演进细节
- jdk1.6及之前
- 有永久代，静态变量存放在永久代上
- jdk1.7
- 有永久代，但已经逐步“去永久代”，字符串常量池、静态变量移除，保存在堆中
- jdk1.8及之后
- 取消永久代，类型信息、字段、方法、常量保存在本地内存的元空间，但字符串常量池、静态变量仍在堆中
补充资料
- 方法区（method area）只是JVM规范中定义的一个概念，用于存储类信息、常量池、静态变量、JIT编译后的代码等数据，并没有规定如何去实现它，不同的厂商有不同的实现。
- 而永久代（PermGen）是 Hotspot 虚拟机特有的概念， Java8 的时候又被元空间取代了，永久代和元空间都可以理解为方法区的落地实现
- 永久代物理是堆的一部分，和新生代，老年代地址是连续的（受垃圾回收器管理），而元空间存在于本地内存（我们常说的堆外内存，不受垃圾回收器管理），这样就不受 JVM 限制了，也比较难发生OOM（都会有溢出异常）
- Java7 中我们通过-XX:PermSize 和 -xx:MaxPermSize 来设置永久代参数，Java8 之后，随着永久代的取消，这些参数也就随之失效了，改为通过-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 用来设置元空间参数
- 存储内容不同，元空间存储类的元信息，静态变量和常量池等并入堆中。相当于永久代的数据被分到了堆和元空间中
- JVM 规范说方法区在逻辑上是堆的一部分，但目前实际上是与 Java 堆分开的（Non-Heap）
栈
简述
- java 虚拟机栈(Java Virtual Machine Stacks)，早期也叫 Java 栈。每个线程在创建的时候都会创建一个虚拟机栈，其内部保存一个个的栈帧(Stack Frame），对应着一次次 Java 方法调用，是线程私有的，生命周期和线程一致
- 主管 Java 程序的运行，它保存方法的局部变量、部分结果，并参与方法的调用和返回
- Java 虚拟机规范允许 Java虚拟机栈的大小是动态的或者是固定不变的
可以通过参数-Xss来设置线程的最大栈空间，栈的大小直接决定了函数调用的最大可达深度 - 特点
- 栈是一种快速有效的分配存储方式，访问速度仅次于程序计数器
- JVM 直接对虚拟机栈的操作只有两个：每个方法执行，伴随着入栈（进栈/压栈），方法执行结束出栈
- 栈不存在垃圾回收问题
栈中可能出现的异常
- 如果采用固定大小的 Java 虚拟机栈，那每个线程的 Java 虚拟机栈容量可以在线程创建的时候独立选定。如果线程请求分配的栈容量超过 Java 虚拟机栈允许的最大容量，Java 虚拟机将会抛出一个 StackOverflowError 异常
- 如果 Java 虚拟机栈可以动态扩展，并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，那 Java 虚拟机将会抛出一个OutOfMemoryError异常
栈的存储单位
- 每个线程都有自己的栈，栈中的数据都是以栈帧（Stack Frame）的格式存在
- 在这个线程上正在执行的每个方法都各自有对应的一个栈帧
- 栈帧是一个内存区块，是一个数据集，维系着方法执行过程中的各种数据信息
栈运行原理
- JVM 直接对 Java 栈的操作只有两个，对栈帧的压栈和出栈，遵循“先进后出/后进先出”原则
- 在一条活动线程中，一个时间点上，只会有一个活动的栈帧。即只有当前正在执行的方法的栈帧（栈顶栈帧）是有效的，这个栈帧被称为当前栈帧（Current Frame），与当前栈帧对应的方法就是当前方法（Current Method），定义这个方法的类就是当前类（Current Class）
- 执行引擎运行的所有字节码指令只针对当前栈帧进行操作
- 如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，放在栈的顶端，称为新的当前栈帧
- 不同线程中所包含的栈帧是不允许存在相互引用的，即不可能在一个栈帧中引用另外一个线程的栈帧
- 如果当前方法调用了其他方法，方法返回之际，当前栈帧会传回此方法的执行结果给前一个栈帧，接着虚拟机会丢弃当前栈帧，使得前一个栈帧重新成为当前栈帧
- Java 方法有两种返回函数的方式，一种是正常的函数返回，使用 return 指令，另一种是抛出异常，不管用哪种方式，都会导致栈帧被弹出
栈帧的内部结构
局部变量表（Local Variables）
- 基础结构
- 局部变量表也被称为局部变量数组或者本地变量表
- 是一组变量值存储空间，主要用于存储方法参数和定义在方法体内的局部变量，包括编译器可知的各种 Java 虚拟机基本数据类型（boolean、byte、char、等）、对象引用（reference类型，它并不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此相关的位置）和 returnAddress 类型（指向了一条字节码指令的地址，已被异常表取代）
- 由于局部变量表是建立在线程的栈上，是线程的私有数据，因此不存在数据安全问题
- 局部变量表所需要的容量大小是编译期确定下来的，并保存在方法的 Code 属性的maximum local variables 数据项中。在方法运行期间是不会改变局部变量表的大小的
- 方法嵌套调用的次数由栈的大小决定。一般来说，栈越大，方法嵌套调用次数越多。对一个函数而言，它的参数和局部变量越多，使得局部变量表膨胀，它的栈帧就越大，以满足方法调用所需传递的信息增大的需求。进而函数调用就会占用更多的栈空间，导致其嵌套调用次数就会减少
- 局部变量表中的变量只在当前方法调用中有效。在方法执行时，虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。当方法调用结束后，随着方法栈帧的销毁，局部变量表也会随之销毁
- 参数值的存放总是在局部变量数组的 index0 开始，到数组长度 -1 的索引结束
- 槽 Slot
- 局部变量表最基本的存储单元是Slot（变量槽）。在局部变量表中，32位以内的类型只占用一个Slot(包括returnAddress类型)，64位的类型（long和double）占用两个连续的 Slot
操作数栈（Operand Stack）
- 简述
- 也称为表达式栈
- 每个独立的栈帧中除了包含局部变量表之外，还包含一个后进先出（Last-In-First-Out）的操作数栈，也可以称为表达式栈（Expression Stack）
- 操作数栈，在方法执行过程中，根据字节码指令，往操作数栈中写入数据或提取数据，即入栈（push）、出栈（pop）
- 某些字节码指令将值压入操作数栈，其余的字节码指令将操作数取出栈。使用它们后再把结果压入栈。比如，执行复制、交换、求和等操作
- 分析
- 操作数栈，主要用于保存计算过程的中间结果，同时作为计算过程中变量临时的存储空间
- 操作数栈就是 JVM 执行引擎的一个工作区，当一个方法刚开始执行的时候，一个新的栈帧也会随之被创建出来，此时这个方法的操作数栈是空的
- 每一个操作数栈都会拥有一个明确的栈深度用于存储数值，其所需的最大深度在编译期就定义好了，保存在方法的 Code 属性的 max_stack 数据项中
- 栈中的任何一个元素都可以是任意的 Java 数据类型。32bit 的类型占用一个栈单位深度；64bit 的类型占用两个栈单位深度
- 操作数栈并非采用访问索引的方式来进行数据访问的，而是只能通过标准的入栈和出栈操作来完成一次数据访问
- 如果被调用的方法带有返回值的话，其返回值将会被压入当前栈帧的操作数栈中，并更新PC寄存器中下一条需要执行的字节码指令
- 操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，这由编译器在编译期间进行验证，同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证
- 另外，我们说Java虚拟机的解释引擎是基于栈的执行引擎，其中的栈指的就是操作数栈
- 栈顶缓存（Top-of-stack-Cashing）
- 将栈顶元素全部缓存在物理 CPU 的寄存器中，以此降低对内存的读/写次数，提升执行引擎的执行效率
动态链接（Dynamic Linking）
- 简述
- 指向运行时常量池的方法引用
- 每一个栈帧内部都包含一个指向运行时常量池中该栈帧所属方法的引用。包含这个引用的目的就是为了支持当前方法的代码能够实现动态链接(Dynamic Linking)
- 在 Java 源文件被编译到字节码文件中时，所有的变量和方法引用都作为符号引用（Symbolic Reference）保存在 Class 文件的常量池中，动态链接的作用就是为了将这些符号引用转换为调用方法的直接引用
- 链接机制
- 静态链接。当一个字节码文件被装载进 JVM 内部时，如果被调用的目标方法在编译期可知，且运行期保持不变时。这种情况下将调用方法的符号引用转换为直接引用的过程称之为静态链接
- 动态链接。如果被调用的方法在编译期无法被确定下来，也就是说，只能在程序运行期将调用方法的符号引用转换为直接引用，由于这种引用转换过程具备动态性，因此也就被称之为动态链接
- 绑定机制
- 早期绑定。早期绑定就是指被调用的目标方法如果在编译期可知，且运行期保持不变时，即可将这个方法与所属的类型进行绑定，这样一来，由于明确了被调用的目标方法究竟是哪一个，因此也就可以使用静态链接的方式将符号引用转换为直接引用
- 晚期绑定。如果被调用的方法在编译器无法被确定下来，只能够在程序运行期根据实际的类型绑定相关的方法，这种绑定方式就被称为晚期绑定
虚方法与非虚方法
- 如果方法在编译器就确定了具体的调用版本，这个版本在运行时是不可变的。这样的方法称为非虚方法，比如静态方法、私有方法、final方法、实例构造器、父类方法都是非虚方法
- 其他方法称为虚方法
方法返回地址（Return Address）
- 方法正常退出或异常退出的地址
其它附加信息
- 栈帧中还允许携带与 Java 虚拟机实现相关的一些附加信息。例如，对程序调试提供支持的信息，但这些信息取决于具体的虚拟机实现
程序计数器
简述
- 程序计数寄存器（Program Counter Register），程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器
- 它是一块很小的内存空间，几乎可以忽略不计。也是运行速度最快的存储区域
- 在 JVM 规范中，每个线程都有它自己的程序计数器，是线程私有的，生命周期与线程的生命周期一致
- 任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。如果当前线程正在执行的是 Java 方法，程序计数器记录的是 JVM 字节码指令地址，如果是执行 natice 方法，则是未指定值（undefined）
- 它是程序控制流的指示器，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成
- 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令
- 它是唯一一个在 JVM 规范中没有规定任何 OutOfMemoryError 情况的区域
常见问题
- 使用PC寄存器存储字节码指令地址有什么用呢？为什么使用PC寄存器记录当前线程的执行地址呢？
- 因为CPU需要不停的切换各个线程，这时候切换回来以后，就得知道接着从哪开始继续执行。JVM的字节码解释器就需要通过改变PC寄存器的值，来明确下一条应该执行什么样的字节码指令
- PC寄存器为什么会被设定为线程私有的？
- 多线程在一个特定的时间段内只会执行其中某一个线程方法，CPU会不停的做任务切换，这样必然会导致经常中断或恢复。为了能够准确的记录各个线程正在执行的当前字节码指令地址，所以为每个线程都分配了一个PC寄存器，每个线程都独立计算，不会互相影响
本地方法栈
本地方法栈（Native Method Stack）
- Java 虚拟机栈用于管理 Java 方法的调用，而本地方法栈用于管理本地方法的调用
- 本地方法栈也是线程私有的
- 允许线程固定或者可动态扩展的内存大小
- 本地方法是使用C语言实现的
- 它的具体做法是 Mative Method Stack 中登记native方法，在 Execution Engine 执行时加载本地方法库当某个线程调用一个本地方法时，它就进入了一个全新的并且不再受虚拟机限制的世界。它和虚拟机拥有同样的权限
- 本地方法可以通过本地方法接口来访问虚拟机内部的运行时数据区，它甚至可以直接使用本地处理器中的寄存器，直接从本地内存的堆中分配任意数量的内存
- 并不是所有 JVM 都支持本地方法。因为 Java 虚拟机规范并没有明确要求本地方法栈的使用语言、具体实现方式、数据结构等。如果 JVM 产品不打算支持 native 方法，也可以无需实现本地方法栈
- 在 Hotspot JVM 中，直接将本地方栈和虚拟机栈合二为一
本地方法接口
- 与 Java 环境外交互：有时 Java 应用需要与 Java 外面的环境交互，这就是本地方法存在的原因
- 与操作系统交互：JVM 支持 Java 语言本身和运行时库，但是有时仍需要依赖一些底层系统的支持。通过本地方法，我们可以实现用 Java 与实现了 jre 的底层系统交互， JVM 的一些部分就是 C 语言写的
垃圾回收（GC）
简述
- GC (Garbage Collection)的基本原理：将内存中不再被使用的对象进行回收，GC中用于回收的方法称为收集器，由于GC需要消耗一些资源和时间，Java在对对象的生命周期特征进行分析后，按照新生代、旧生代的方式来对对象进行收集，以尽可能的缩短GC对应用造成的暂停
- JVM 在进行 GC 时，并非每次都对堆内存（新生代、老年代；方法区）区域一起回收的，大部分时候回收的都是指新生代
- 常见的有Minor GC、Major GC、Full GC
常见的垃圾收集器
- CMS垃圾收集器
- G1垃圾收集器
- G1垃圾回收器是在Java7 update 4之后引入的一个新的垃圾回收器
- G1也是关注最小时延的垃圾回收器，也同样适合大尺寸堆内存的垃圾收集，G1最大的特点是引入分区的思路，弱化了分代的概念，合理利用垃圾收集各个周期的资源，解决了其他收集器甚至CMS的众多缺陷
- ZGC垃圾收集器
- ZGC（The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器, 是JDK 11+ 最为重要的更新之一，适用于大内存低延迟服务的内存管理和回收
垃圾回收策略
部分收集（Partial GC）
- 新生代收集（Minor GC/Young GC）。只是新生代的垃圾收集
- 老年代收集（Major GC/Old GC）。只是老年代的垃圾收集
- 目前，只有 CMS GC 会有单独收集老年代的行为
- 很多时候 Major GC 会和 Full GC 混合使用，需要具体分辨是老年代回收还是整堆回收
- 阈值默认为 92%，大于时自动触发GC
- 混合收集（Mixed GC）：收集整个新生代以及部分老年代的垃圾收集
- 目前只有 G1 GC 会有这种行为
整堆收集（Full GC）
- 收集整个 Java 堆和方法区的垃圾
- Full GC 的触发条件
- 调用 System.gc()
- 老年代空间不足
- 空间分配担保失败
- JDK 1.7 及以前的永久代空间不足
- Concurrent Mode Failure
GC算法
标记-清除算法
- 算法分为标记和清除两个阶段，首先标记出所有需要回收的对象，然后回收所有需要回收的对象
- 需要全量扫描内存空间，标记和清理两个过程效率都不高
- 标记清理之后会产生大量不连续的内存碎片
标记-整理(压缩)算法
- 标记存活的对象，将存活的对象向一端移动，清理掉存活端边界以外的内存
- 没有内存碎片
- 比标记清除算法更耗时，增加了内存拷贝过程
复制算法
- 将可用内存划分为两块，每次只是用其中的一块，当半区内存用完了，仅将还存活的对象复制到另外一块上面，然后就把原来整块内存空间一次性清理掉
- 内存缩小为原来的一半，代价高昂
- 对象存活率高的时候，效率有所下降
分代收集算法
- 新生代
- 采用的复制算法，分为Eden、From Survivor、To Survivor三个分区，内存比率是：8：1：1，每次只有10%的surivor内存是浪费的。
- 每次使用eden和From Survivor，每当GC后，将存活的对象一次性拷贝到To Survivor空间中，然后清理掉Eden和Frm Survivor
- 老年代
- 标记清除算法或者标记整理算法
- 新生代晋升老年代的规则
- 长期存活的对象将进入老年代。新生代内存在每次GC后存活的对象，存活年龄加1，当年龄超过15次后（虚拟机默认15），会被移动到老年代
- 大对象直接进入老年代。可通过配置-XX:PretenureSizeThreshold参数，大于该值得直接进入老年代
- 动态对象年龄判断。在survivor区中低于或等于某年龄的的所有对象大小的总和，大于Survivor空间的一半时，大于或等于改年龄的对象就可以直接进入老年代，无需等到-XX:MaxTenuringThreshold中要求的年龄
- 空间分配担保
对象存活分析
存活判断方法
引用计数法
- 在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的
- 虽然占用了一些额外的内存空间来进行计数，但它的原理简单，判定效率也很高在大多数情况下它都是一个不错的算法
- 很难解决对象之间相互循环引用的问题
可达性分析算法
- JVM默认方式
- 通过一系列称为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为“引用链”（Reference Chain），
- 如果某个对象到GC Roots间没有任何引用链相连，或者用图论的话来说就是从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的
拓展
方法区的回收条件
- 该类所有的实例都已经被回收，也就是堆中不存在该类的任何实例
- 加载该类的 ClassLoader 已经被回收
- 该类对应的 Class 对象没有在任何地方被引用，也就无法在任何地方通过反射访问该类方法
finalize函数
- 当一个对象可被回收时，会执行该对象的 finalize() 方法
- 如果该对象通过自救存活了下来，当下一次被垃圾回收时，不会再调用finalize()方法
对象引用类型
强引用
- 被强引用关联的对象不会被回收
- 使用 new 一个新对象的方式来创建强引用
软引用
- 被软引用关联的对象只有在内存不够的情况下才会被回收
- 使用 SoftReference 类来创建软引用
弱引用
- 被弱引用关联的对象一定会被回收，也就是说它只能存活到下一次垃圾回收发生之前
- 使用 WeakReference 类来实现弱引用
虚引用
- 又称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象
- 使用 PhantomReference 来实现虚引用
- 为一个对象设置虚引用关联的唯一目的就是能在这个对象被回收时收到一个系统通知
判断GC有没有问题的指标
- 延迟（Latency）
- 也可以理解为最大停顿时间，即垃圾收集过程中一次 STW 的最长时间，越短越好，一定程度上可以接受频次的增大，GC 技术的主要发展方向
- 吞吐量（Throughput）
- 即吞吐量 = 运行用户代码时间 /（运行用户代码时间 + 垃圾收集时间）
- 通常吞吐量大于或等于99.99%时，视为达标，否则就需要进行优化
GC常见问题
动态扩容引起的空间震荡
-
在 JVM 的参数中 -Xms 和 -Xmx 设置的不一致，在初始化时只会初始 -Xms 大小的空间存储信息，每当空间不够用时再向操作系统申请，这样的话必然要进行一次 GC
-
一般来说，我们需要保证 Java 虚拟机的堆是稳定的，确保 -Xms 和 -Xmx 设置的是一个值，获得一个稳定的堆，尽量将成对出现的空间大小配置参数设置成固定的
如： -Xms 和 -Xmx， -XX:MaxNewSize 和 -XX:NewSize， -XX:MetaSpaceSize 和 -XX:MaxMetaSpaceSize
显式 GC 的去与留
- 发生 System.gc 时会引发一次 STW 的 Full GC，对整个堆做收集
MetaSpace 区域发生 OOM
- 避免弹性伸缩带来的额外 GC 消耗，我们会将 -XX:MetaSpaceSize 和 -XX:MaxMetaSpaceSize 两个值设置为固定的，但是这样也会导致在空间不够的时候无法扩容，然后频繁地触发 GC，最终 OOM。所以关键原因就是 ClassLoader 不停地在内存中 load 了新的 Class ，一般这种问题都发生在动态类加载等情况上
- 经常会出问题的几个点有 Orika 的 classMap、JSON 的 ASMSerializer、Groovy 动态加载类等。基本都集中在反射、Javasisit 字节码增强、CGLIB 动态代理、OSGi 自定义类加载器等的技术点上。另外就是及时给 MetaSpace 区的使用率加一个监控，如果指标有波动提前发现并解决问题
过早晋升
- Young/Eden 区过小
- 解决方式：观察CMS GC的清空找到存货对象大概大小，Old 的大小应当为活跃对象的 2~3 倍左右，考虑到浮动垃圾问题最好在 3 倍左右，剩下的都可以分给 Young 区
- 分配速率过大
- 可以观察出问题前后 Mutator 的分配速率，如果有明显波动可以尝试观察网卡流量、存储类中间件慢查询日志等信息，看是否有大量数据被加载到内存中
- 问题场景：偶发较大时，通过内存分析工具找到问题代码，从业务逻辑上做一些优化
- 问题场景：一直较大时，当前的 Collector 已经不满足 Mutator 的期望了，这种情况要么扩容 Mutator 的 VM，要么调整 GC 收集器类型或加大空间
CMS Old GC 频繁
单次 CMS Old GC 耗时长
内存碎片&收集器退化
堆外内存 OOM
JNI 引发的 GC 问题
JVM管理
JVM常用设置
开启JVM日志打印
-verbose:gc -XX:+PrintGCDetails
设置JVM初始化内存为20M
-Xms20M
设置JVM最大内存为20M
-Xmx20M
设置JVM年轻带内存大小为10M
-Xmn10M
设置JVM大对象分配区域判断条件
-XX: PretenureSizeThreshold 1024
设置内存异常是保存内存快照
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath:/data/heap/error
JVM基础命令介绍
JPS
jps (JVM Process Status Tool）是其中的典型jvm工具。除了名字像 UNIX 的 ps 命令之外，它的功能也和 ps 命令类似：可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class, main（）函数所在的类）名称以及这些进程的本地虚拟机唯- ID (Local Virtual Machine Identifier, LVMID），虽然功能比较单一，但它是使用频率最高的 JDK 命令行工具
-
使用
输出主类的全名，如果进程执行的是Jar包则输出Jar路径 jps -l 输出虚拟机进程启动时JVM参数 jps -v
jstat
Jstat (JVM Statistics Monitoring Tool）是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程-虚拟机进程中的类装载、内存、垃圾收集、JIT 编译等运行数据，在没有 GU 图形界面，只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的首选工具
-
使用
jstat -gc 2764 250 20 --------------说明----------------- //2764表示进程id ，250表示250毫秒打印一次 ，20表示一共打印20次 S0C：第一个幸存区的大小 S1C：第二个幸存区的大小 S0U：第一个幸存区的使用大小 S1U：第二个幸存区的使用大小 EC：伊甸园区的大小 EU：伊甸园区的使用大小 OC：老年代大小 OU：老年代使用大小 MC：方法区大小 MU：方法区使用大小 CCSC:压缩类空间大小 CCSU:压缩类空间使用大小 YGC：年轻代垃圾回收次数 YGCT：年轻代垃圾回收消耗时间 FGC：老年代垃圾回收次数 FGCT：老年代垃圾回收消耗时间 GCT：垃圾回收消耗总时间
jinfo
jinfo (Configuration Info for Java）的作用是实时地查看和调整虚拟机各项参数。使用 jps 命令的-v 参数可以查看虚拟机启动时显式指定的参数列表，但如果想知道未被显式指定的参数的系统默认值，除了去找资料外，就只能使用 info 的-flag 选项进行查询了
-
使用
jinfo pidjinfo -flag CMSInititingOccupancyFraction 1444
jmap
Jmap (Memory Map for Java）命令用于生成堆转储快照。如果不使用 jmap 命令，要想获取 Java 堆转储快照，还有一些比较“暴力”的手段：-XX: +HeapDumpOnOutOfMemoryError 参数，可以让虚拟机在 OOM 异常出现之后自动生成 dump 文件，用于系统复盘环节
和 info 命令一样，jmap 有不少功能在 Windows 平台下都是受限的，除了生成 dump 文件的- dump 选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统都提供之外，其余选项都只能在Linux/Solaris 下使用
-
使用
生成 Java 堆转储快照 windows jmap -dump:format=b,file=d:\a.bin 1234 mac jmap -dump:format=b,file=/Users/daniel/deskTop
jstack
Jstack (Stack Trace for Java）命令用于生成虚拟机当前时刻的线程快照（-般称为 threaddump 或者 javacore 文件）
线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过 jstack 来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些什么事情，或者等待着什么资源
-
使用
输出线程堆栈 jstack -l 3500 强制输出线程堆栈 jstack -F -l 3500
常用的JVM分析工具
命令行终端
- 标准终端类
- jps
- jinfo
- jstat
- jstack
- jmap
- 功能整合类
- jcmd
- vjtools
- arthas
- greys
可视化界面
- JConsole
- Visualvm
- VisualVM是一个集成命令行JDK工具和轻量级分析功能的可视化工具
- IDEA安装VisualVM插件。File-> Setting-> Plugins -> Browers Repositrories 搜索VisualVM Launcher安装并重启IDEA
- 配置VisualVM。Ctrl + Alt + S > Other Settings > VisualVM LauncherVisualVM executable: E:/Java/jdk1.8.0_131/bin/jvisualvm.exe
- HA
- GCHisto
- GCViewer
- MAT
- JProfiler
- IBM HeapAnalyzer
- IBMHeapAnalyzer可以分析heapdump、phd、hax等文件IBMHeapAnalyzer是一个非常重要的JAVA程序bug分析工具。
- 它可以帮助我们分析哪些原因可能导致了程序的内存溢出
故障处理方式
- 某个节点发生问题后，如果条件允许一定不要直接操作重启、回滚等动作恢复，优先通过摘掉流量的方式来恢复，这样我们可以将堆、栈、GC 日志等关键信息保留下来，当然除了这些，应用日志、中间件日志、内核日志、各种 Metrics 指标等对问题分析也有很大帮助
扫一扫
602
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
