JVM
2024-10-12 15:05:40 0 举报AI智能生成
JVM，全称Java Virtual Machine，是一种用于运行Java程序的虚拟机。它可以将Java字节码转换成机器码，以便在不同操作系统和硬件架构上运行。JVM的核心内容包括类加载器、执行引擎、运行时数据区和本地方法接口。类加载器负责加载和链接Java类文件；执行引擎执行字节码指令，包括解释执行和即时编译（JIT）；运行时数据区包括堆、栈、方法区和程序计数器，用于存储和操作运行时数据；本地方法接口则允许Java程序调用本地方法。JVM是一种平台无关的文件类型，可以用于创建跨平台的Java应用程序。在Java代码中，JVM可以通过public、private、protected和default等修饰语控制可见性和访问权限。
作者其他创作
大纲/内容
JVM是Java Virtual Machine(Java虚拟机)的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机
是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
1 什么是JVM
为什么要在程序和操作系统中间添加一个JVM
问题
从图中可以看到，有了 JVM 这个抽象层之后，Java 就可以实现跨平台了
JVM 只需要保证能够正确执行 .class 文 件，就可以运行在诸如 Linux、Windows、MacOS 等平台上了。
而 Java 跨平台的意义在于一次编译，处处运行，能够做到这一点 JVM 功不可没
现在的一些 JVM 的扩展语言，比如 Clojure、JRuby、Groovy 等，编译到最后都是 .class 文件，Java 语言的维护 者，只需要控制好 JVM 这个解析器，就可以将这些扩展语言无缝的运行在 JVM 之上了。
答案
应用程序、JVM、操作系统之间的关系
JVM 上承开发语言，下接操作系统，它的中间接口就是字节码
关系
2 JVM与操作系统
JVM
仅仅是 JVM，是无法完成一次编译，处处运行的
它需要一个基本的类库，比如怎么操作文件、怎么连接网络等。 而 Java 体系很慷慨，会一次性将 JVM 运行所需的类库都传递给它。
JVM 标准加上实现的一大堆基础类库，就组成 了 Java 的运行时环境，也就是我们常说的 JRE(Java Runtime Environment)
jre
对于 JDK 来说，就更庞大了一些
除了 JRE，JDK 还提供了一些非常好用的小工具，比如 javac、java、jar 等
它 是 Java 开发的核心，让外行也可以炼剑!
JDK
如图所示
解释
3 JVM、JRE、JDK 的关系
是 Java 虚拟机规范，其实就是为输入和执行字节码提供一个运行环境
左半部分
是我们常说的 Java 语法 规范，比如 switch、for、泛型、lambda 等相关的程序，最终都会编译成字节码
右半部分
而连接左右两部分的桥梁依然是 Java 的字节码。
如果 .class 文件的规格是不变的，这两部分是可以独立进行优化的。
但 Java 也会偶尔扩充一下 .class 文件的格式， 增加一些字节码指令，以便支持更多的特性。
我们可以把 Java 虚拟机可以看作是一台抽象的计算机，它有自己的指令集以及各种运行时内存区域，学过《计算 机组成结构》的同学会在课程的后面看到非常多的相似性。
分析
这里的 Java 程序是文本格式的。比如下面这段 HelloWorld.java，它遵循的就是 Java 语言规范
Java 虚拟机采用基于栈的架构，其指令由操作码和操作数组成。这些 字节码指令 ，就叫作 opcode。
其中， getstatic、ldc、invokevirtual、return 等，就是 opcode，可以看到是比较容易理解的。
VM 就是靠解析这些 opcode 和操作数来完成程序的执行的。
当我们使用 Java 命令运行 .class 文件的时候，实际上 就相当于启动了一个 JVM 进程。
HelloWorld.class
常见的就是解释执行，将 opcode + 操作数翻译成机器代码;
另 外一种执行方式就是 JIT，也就是我们常说的即时编译，它会在一定条件下将字节码编译成机器码之后再执行。
然后 JVM 会翻译这些字节码，它有两种执行方式
java程序的运行过程
4 Java虚拟机规范和 Java 语言规范的关系
1.jvm回顾
根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。
如图
Jvm内存描述
类装载器子系统 、 运行时数据区 、 执行引擎 、 本地方法接口 和 垃圾收集模块
JVM的五大模块
1.JVM整体架构
Java 虚拟机有自动内存管理机制，如果出现面的问题，排查错误就必须要了解虚拟机是怎样使用内存的。
方法区是java虚拟机规范中定义的一种概念上的区域，不同的厂商可以对虚拟机进行不同的实现。
我们通常使用的Java SE都是由Sun JDK和OpenJDK所提供，这也是应用最广泛的版本
而该版本使用的VM就是 HotSpot VM。通常情况下，我们所讲的java虚拟机指的就是HotSpot的版本。
背景
JDK7内存结构
针对JDK8虚拟机内存详解
JDK8内存结构
当然不是，方法区只是一个规范，只不过它的实现变了。
在Java8中，元空间(Metaspace)登上舞台，方法区存在于元空间(Metaspace)。
同时，元空间不再与堆连续，而且是 存在于本地内存(Native memory)。
对于Java8，HotSpots取消了永久代，那么是不是就没有方法区了呢?
移除了永久代(PermGen)，替换为元空间(Metaspace)
永久代中的class metadata(类元信息)转移到了native memory(本地内存，而不是虚拟机)
永久代中的interned Strings(字符串常量池) 和 class static variables(类静态变量)转移到了Java heap
永久代参数(PermSize MaxPermSize)-> 元空间参数(MetaspaceSize MaxMetaspaceSize)
方法区Java8之后的变化
字符串存在永久代中，容易出现性能问题和内存溢出。
类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出
永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
Oracle 可能会将HotSpot 与 JRockit 合二为一，JRockit没有所谓的永久代。
Java8为什么要将永久代替换成Metaspace?
区别
java7和java8的区别
叫PC寄存器，是一块较小的内存空间，它可以看做是当前线程所执行 的字节码的行号指示器。
在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计数器的值来选取下一条 需要执行的字节码指令、分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成
计算机用pc寄存器来存放“伪指令”或地址
而相对于虚拟 机，pc寄存器它表现为一块内存，虚拟机的pc寄存器的功能也是存放伪指令，更确切的说存放的是将要执行指令的 地址。
(1)区别于计算机硬件的pc寄存器，两者不略有不同。
(2)当虚拟机正在执行的方法是一个本地(native)方法的时候，jvm的pc寄存器存储的值是undefined。
(3)程序计数器是线程私有的，它的生命周期与线程相同，每个线程都有一个。
(4)此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
特点
Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的
在任何一个确定的时刻，一个处 理器只会执行一条线程中的指令。
为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器
各条线程之间的计数 器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
程序计数器使用模拟
2.1 PC 程序计数器
Java虚拟机栈(Java Virtual Machine Stacks)也是线程私有的，即生命周期和线程相同。
栈帧(Stack Frame)是用于支持虚拟机进行方法调用和方法执行的数据结构
栈帧存储了方法的局部变量表、操作数 栈、动态连接和方法返回地址等信息。
每一个方法从调用至执行完成的过程，都对应着一个栈帧在虚拟机栈里从入 栈到出栈的过程。
如图题
是一组变量值存储空间，用于存放方法参数和方法内定义的局部变量
包括8种基本数据类型、对象引用(reference类型)和returnAddress类型(指向一条字节码指令的地址)。
其中64位长度的long和double类型的数据会占用2个局部变量空间(Slot)，其余的数据类型只占用1个。
注意
1.局部变量表
操作数栈(Operand Stack)也称作操作栈，是一个后入先出栈(LIFO)
随着方法执行和字节码指令的执行，会从局部变量表或对象实例的字段中复制常量或变量写入到操作数栈
再随着计算的进行将栈中元素出栈到局部变量表或者 返回给方法调用者，也就是出栈/入栈操作。
处理过程
案例
2.操作数栈
Java虚拟机栈中，每个栈帧都包含一个指向运行时常量池中该栈所属方法的符号引用
持有这个引用的目的是为了 支持方法调用过程中的动态链接(Dynamic Linking)。
动态链接的作用:将符号引用转换成直接引用。
作用
3.动态链接
方法返回地址存放调用该方法的PC寄存器的值
正常地执行完成，出现未处理的异 常非正常的退出
无论通过哪种方式退出，在方法退出后都返回到该方法被调用的位置。
方法正常退出时，调用者 的PC计数器的值作为返回地址，即调用该方法的指令的下一条指令的地址。
正常退出
而通过异常退出的，返回地址是要通过 异常表来确定，栈帧中一般不会保存这部分信息。
异常退出
一个方法的结束，有两种方式:
4.方法返回地址
结构元素
1.什么是栈帧
每个方法在执行时都会创建一个栈帧(Stack Frame)，用于存储局部变量表、操作数栈、动态 链接 、 方法出口 等信息
每一个方法从调用直到执行完成的过程就对应着一个栈帧在虚拟机栈中从入栈到出栈的过 程。
java虚拟机栈和线程同时创建，用于存储栈帧。
代码
案例解释
-Xss 为jvm启动的每个线程分配的内存大小，默认JDK1.4中是256K，JDK1.5+中是1M
count输出8467是因为在180KB的栈空间限制下，main方法可以递归调用8467次
设置虚拟机栈的大小
2.2 虚拟机栈
其区别只是虚拟机栈为虚拟机执行Java方法(也就是字节码) 服务
而本地方法栈则是为虚拟机使用到的本地(Native) 方法服务。
本地方法栈(Native Method Stacks) 与虚拟机栈所发挥的作用是非常相似的
(2)虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则是为虚拟机使用到的Native方法服务。
(3)是线程私有的，它的生命周期与线程相同，每个线程都有一个。
异常
2.3 本地方法栈
对于Java应用程序来说， Java堆(Java Heap) 是虚拟机所管理的内存中最大的一块。
java堆是被所 有线程共享 的一块内存区域， 在虚拟机启动时创建。
此内存区域的唯一目的就是存放对象实例， Java 世界里“几乎”所有的对 象实例都在这里分配内存。
随着Java语 言的发展， 现在已经能看到些许迹象表明日 后可能出现值类型的支持， 即使只考虑现在， 由于即时编译技术的进步， 尤其是逃逸分析技术的日渐强大， 栈上 分配、 标量替换优化手段已经导致一些微妙的变化悄然发生， 所以说Java对象实例都分配在堆上也渐渐变得不是 那么绝对了。
(1)是Java虚拟机所管理的内存中最大的一块。
堆中也包含私有的线程缓冲区 Thread Local Allocation Buffer (TLAB)
(2)堆是jvm所有线程共享的。
(3)在虚拟机启动的时候创建。
(4)唯一目的就是存放对象实例，几乎所有的对象实例以及数组都要在这里分配内存。
(5)Java堆是垃圾收集器管理的主要区域。
所以Java堆还可以细分为:新生代和老年代
新生代又可以分为:Eden 空间、From Survivor空间、To Survivor空间。
(6)因此很多时候java堆也被称为“GC堆”(Garbage Collected Heap)。从内存回收的角度来看，由于现在收集器 基本都采用分代收集算法
(7)java堆是计算机物理存储上不连续的、逻辑上是连续的，也是大小可调节的(通过-Xms和-Xmx控制)。
(9)如果在堆中没有内存完成实例的分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常
2.特点
1. 内存大小-Xmx/-Xms使用示例: -Xmx20m -Xms5m说明: 当下Java应用最大可用内存为20M， 最小内存为5M
描述
大家可以发现，这里打印出来的Xmx值和设置的值之间是由差异的
total Memory和最大的内存之间还是存在一定 差异的，就是说JVM一般会尽量保持内存在一个尽可能底的层面，而非贪婪做法按照最大的内存来进行分配。
子主题
输出结果
在申请分配了4m内存空间之后，total memory上升了，同时可用的内存也上升了
可以发现其实JVM在分配内存过 程中是动态的， 按需来分配的。
更新代码
3.设置堆的空间大小
现在垃圾回收器都使用分代理论
青年代Young Generation
老年代Old Generation
永久代Permanent Generation
在Java7 Hotspot虚拟机中将Java堆内存分为3个部分:
由于方法区的内存不在分配在Java堆上，而是存储于本地内存元空间Metaspace中
所以 永久代就不 存在了 ，在几天前(2018年9约25日)Java11正式发布以后，我从官网上找到了关于Java11中垃圾收集器的官方文档， 文档中没有提到“永久代”，而只有青年代和老年代。
在Java8以后
4.堆的分类
1.java堆概念
年轻代主要存放新创建的对象，内存大小相对会比较小，垃圾回收会比较频繁
年轻代分 成1个Eden Space和2个Suvivor Space(from 和to)。
1)年轻代(Young Gen):
年老代主要存放JVM认为生命周期比较长的对象(经过几次的Young Gen的垃圾回收后仍 然存在)
内存大小相对会比较大，垃圾回收也相对没有那么频繁。
2)年老代(Tenured Gen):
1.JVM中存储java对象可以被分为两类:
配置解读
从图中可以看出: 堆大小 = 新生代 + 老年代。其中，堆的大小可以通过参数 –Xms、-Xmx 来指定。
新生代 ( Young ) 被细分为 Eden 和 两个 Survivor 区域
这两个 Survivor 区域分别被命名为 from 和 to，以示区分。
默认的，Edem : from : to = 8 : 1 : 1 ( 可以 通过参数 –XX:SurvivorRatio 来设定 )，即: Eden = 8/10 的新生代空间大小，from = to = 1/10 的新生代空间大小
JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域 是空闲着的
因此，新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。
处理现象
即:新生 代 ( Young ) = 1/3 的堆空间大小
老年代 ( Old ) = 2/3 的堆空间大小。
默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2 ( 该值可以通过参数 –XX:NewRatio 来指定 )，
2.配置新生代和老年代堆结构占比
2.年轻代和老年代
JVM设计者不仅需要考虑到内存如何分配，在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关
因此还需要考虑GC执行完内存回收后是否存在空间中间产生内存碎片。
1.new的对象先放在伊甸园区。该区域有大小限制
3.然后将伊甸园区中的剩余对象移动到幸存者0区
4.如果再次触发垃圾回收，此时上次幸存下来的放在幸存者0区的，如果没有回收，就会放到幸存者1区
5.如果再次经历垃圾回收，此时会重新返回幸存者0区，接着再去幸存者1区。
可以通过设置参数，调整阈值 -XX:MaxTenuringThreshold=N
6.如果累计次数到达默认的15次，这会进入养老区。
分配过程
具体如图所示
分配对象的流程图
3.对象分配过程
新生代收集(Minor GC / Young GC): 只是新生代的垃圾收集
老年代收集 (Major GC / Old GC): 只是老年代的垃圾收集 (CMS GC 单独回收老年代)
分类
一种是部分收集器(Partial GC)
整堆收集(Full GC):收集整个java堆和方法区的垃圾收集器
另一类是整堆收集器(Fu'll GC)
Java 中的堆也是 GC 收集垃圾的主要区域。GC 分为两种
年轻代GC触发条件:
Major GC的速度比Minor GC慢10倍以上.
老年代GC (Major GC)触发机制
老年代空间不足
方法区空间不足
通过Minor GC进入老年代平均大小大于老年代可用内存
FullGC 触发机制:
触发条件
4.堆GC
2.4 堆
在JDK1.7之前，HotSpot 虚拟机把方法区当成永久代来进行垃圾回收
HotSpots取消了永久代，那么是不是也就没有方法区了 呢?当然不是，方法区是一个规范，规范没变，它就一直在
只不过取代永久代的是 元空间(Metaspace) 而已。
而从 JDK 1.8 开始，移除永久代，并把方法 区移至元空间，它位于本地内存中，而不是虚拟机内存中
永久代和元空间有什么不同?
永久代 在物理上是堆的一部分 ，和新生代、老年代的地址是连续的
而元空间属于 本地内存 。
存储位置不同
在原来的永久代划分中，永久代用来存放类的元数据信息、静态变量以及常量池等
现在类的元信 息存储在元空间中，静态变量和常量池等并入堆中，相当于原来的永久代中的数据，被元空间和堆内存给瓜分了
存储内容不同
在原来的永久代划分中，永久代需要存放类的元数据、静态变量和常量等。 它的大小不容易确定 ，因为这其 中有很多影响因素，比如类的总数，常量池的大小和方法数量等，-XX:MaxPermSize 指定太小很容易造成永久 代内存溢出。
移除永久代是为融合HotSpot VM与 JRockit VM而做出的努力，因为JRockit没有永久代，不需要配置永久代
永久代会为GC带来不必要的复杂度，并且回收效率偏低。
2.5.1 为什么要废弃永久代，引入元空间?
由于类的元数据分配在本地内存中，元空间的最大可分配空间就是系统可用内存空间。不会遇到永久代存在 时的内存溢出错误。
将运行时常量池从PermGen分离出来，与类的元数据分开，提升类元数据的独立性。
将元数据从PermGen剥离出来到Metaspace，可以提升对元数据的管理同时提升GC效率。
2.5.2 废除永久代的好处
初始空间大小，达到该值就会触发垃圾收集进行类型卸载
如 果释放了大量的空间，就适当降低该值
如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提 高该值。
同时GC会对该值进行调整
-XX:MetaspaceSize
最大空间，默认是没有限制的。如果没有使用该参数来设置类的元数据的大小， 其最 大可利用空间是整个系统内存的可用空间
JVM也可以增加本地内存空间来满足类元数据信息的存储。
但是如果没有设置最大值，则可能存在bug导致Metaspace的空间在不停的扩展，会导致机器的内存不足;
进 而可能出现swap内存被耗尽;最终导致进程直接被系统直接kill掉。
如果设置了该参数，当Metaspace剩余空间不足，会抛出:java.lang.OutOfMemoryError: Metaspace space
-XX:MaxMetaspaceSize
在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的 垃圾收集
-XX:MinMetaspaceFreeRatio
在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的 垃圾收集
-XX:MaxMetaspaceFreeRatio
2.5.3 Metaspace相关参数
2.5 元空间
方法区(Method Area) 与Java堆一样， 是各个线程共享的内存区域， 它用于存储已被虚拟机加载 的类型信息、 常量、 静态变量、 即时编译器编译后的代码缓存等数据。
元空间、永久代是方法区具体的落地实现。方法区看作是一块独立于Java堆的内存空间，它主要是用来存储所加载 的类信息的
创建对象各数据区域的声明:
方法区与堆一样是各个线程共享的内存区域
方法区在JVM启动的时候就会被创建并且它实例的物理内存空间和Java堆一样都可以不连续
方法区的大小跟堆空间一样 可以选择固定大小或者动态变化
关闭JVM就会释放这个区域的内存
方法区的特点
2.6.1 方法区的理解
类加载器将Class文件加载到内存之后，将类的信息存储到方法区中。
1 这个类型的完整有效名称(全名 = 包名.类名)
2 这个类型直接父类的完整有效名(对于 interface或是java.lang. Object，都没有父类)
4 这个类型直接接口的一个有序列表
类型信息
域信息，即为类的属性，成员变量
JVM必须在方法区中保存类所有的成员变量相关信息及声明顺序。
域名称
域类型
域修饰符(pυblic、private、protected、static、final、volatile、transient的 某个子集)
相关结构
域信息
JVM必须保存所有方法的以下信息，同域信息一样包括声明顺序:
1. 方法名称方法的返回类型(或void)
2. 方法参数的数量和类型(按顺序)
4. 方法的字节码bytecodes、操作数栈、局部变量表及大小( abstract和native方法除外)
5. 异常表( abstract和 native方法除外)。每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏 移地址、被捕获的异常类的常量池索引
结构
方法信息
类信息
运行时常量池
JIT代码缓存
2.6.2 方法区结构
方法区的大小不必是固定的，JVM可以根据应用的需要动态调整。
jdk7及以前
元数据区大小可以使用参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize指定
与永久代不同，如果不指定大小，默认情况下，虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出，虚拟 机一样会抛出异常OutOfMemoryError:Metaspace
-XX:MetaspaceSize:设置初始的元空间大小
配置参数
jps #查看进程号
jinfo -flag MetaspaceSize 进程号 #查看Metaspace 最大分配内存空间
jinfo -flag MaxMetaspaceSize 进程号 #查看Metaspace最大空间
查看元数据空间配置的大小指令
对于一个64位的服务器端JVM来说，其默认的-xx:MetaspaceSize值为 21MB。
这就是初始的高水位线，一旦触及这个水位线，FullGC将会被触发并卸载没用的类(即这些类对应的类加载 器不再存活)然后这个高水位线将会重置
新的高水位线的值取决于GC后释放了多少元空间。如果释放的空间不 足，那么在不超过MaxMetaspaceSize时，适当提高该值。如果释放空间过多，则适当降低该值
如果初始化的高水位线设置过低，上述高水位线调整情况会发生很多次
通过垃圾回收器的日志可以观察到FullGC 多次调用。为了避免频繁地GC，建议将-XX:MetaspaceSize设置为一个相对较高的值。
案例分析
JDK8以后
JDK1.7和JDK1.8的区别
2.6.3 方法区设置
2.6 方法区
字节码文件中 ，内部包含了常量池
存放编译期间生成的各种字面量与符号引用
常量池
方法区中 ，内部包含了运行时常量池
常量池表在运行时的表现形式
它们不是一个概念，存放的位置是不同的。一个在字节码文件中，一个在方法区中。
常量池vs运行时常量池
编译后的字节码文件中包含了类型信息、域信息、方法信息等。
通过ClassLoader将 字节码文件的常量池 中的信息加 载到内存中，存储在了 方法区的运行时常量池 中。
理解为字节码中的常量池 Constant pool 只是文件信息，它想要执行就必须加载到内存中
而Java程序是靠 JVM，更具体的来说是JVM的执行引擎来解释执行的
执行引擎在运行时常量池中取数据，被加载的字节码常量池 中的信息是放到了方法区的运行时常量池中。
处理流程
一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外
还包含一项信息那就是 常量池表( Constant pool table)，包括各种字面量和对类型、域和方法的符号引用。
常量池，可以看做是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。
常量池表Constant pool table:
在方活中对常量池表的符号引用
为什么需要常量池
对字节码文件反编译之后，查看常量池相关信息:
2.7 运行时常量池
直接内存(Direct Memory) 并不是虚拟机运行时数据区的一部分。
在JDK 1.4中新加入了NIO(New Input/Output) 类， 引入了一种基于通道(Channel) 与缓冲区 (Bu\u0000er) 的I/O方 式
它可以使用Native函数库直接分配堆外内存， 然后通过一个存储在Java堆里面的 DirectByteBu\u0000er对象作为这块 内存的引用进行操作。
这样能在一些场景中显著提高性能， 因为避免了 在Java堆和Native堆中来回复制数据。
扩展
NIO的Buer提供一个可以直接访问系统物理内存的类——DirectBuer
DirectBuer类继承自ByteBuer，但和普通 的ByteBuer不同。普通的ByteBuer仍在JVM堆上分配内存，其最大内存受到最大堆内存的 限制
而DirectBuer直 接分配在物理内存中，并不占用堆空间。在访问普通的ByteBuer时，系统总是会使用一个“内核缓冲区”进行操作
而DirectBuer所处的位置，就相当于这个“内核缓冲区”。因此，使用DirectBuer是一种更加接近内存底层的方法， 所以它的速度比普通的ByteBuer更快。
1. 改善堆过大时垃圾回收效率，减少停顿。Full GC时会扫描堆内存，回收效率和堆大小成正比。Native的内 存，由OS负责管理和回收。
2. 减少内存在Native堆和JVM堆拷贝过程，避免拷贝损耗，降低内存使用。
3. 可突破JVM内存大小限制。
通过使用堆外内存，可以带来以下好处:
directBuffer类图
2.8 直接内存
2.JVM运行时内存
堆内存中主要存放对象、数组等，只要不断地创建这些对象，并且保证 GC Roots 到对象之间有可达路径来避免垃 圾收集回收机制清除这些对象
当这些对象所占空间超过最大堆容量时，就会产生 OutOfMemoryError 的异常
java.lang.OutOfMemoryError: Java heap space 的信息，说明在堆内存空间产生内存溢出的异常。题
新产生的对象最初分配在新生代，新生代满后会进行一次 Minor GC ，如果 Minor GC 后空间不足会把该对象和 新生代满足条件的对象放入老年代
老年代空间不足时会进行 Full GC ，之后如果空间还不足以存放新对象则抛 出 OutOfMemoryError 异常。
运行后报异常
案例代码
内存中加载的数据过多，如一次从数据库中取出过多数据;
堆内存分配不合理
常见原因
3.1 Java堆溢出
1) 如果线程请求的栈深度大于虚拟机所允许的最大深度， 将抛出StackOverflowError异常。
HotSpot虚拟机的选择是不支持 扩展， 所以除非在创建线程申请内存时就因无法获得足够内存而出现 OutOfMemoryError异常
创建线程的时候无法申请足够的内存
2) 如果虚拟机的栈内存允许动态扩展， 当扩展栈容量无法申请到足够的内存时， 将抛出 OutOfMemoryError异常
两种异常
3.2 虚拟机栈和本地方法栈溢出
String::intern()是一个本地方法， 它的作用是如果字符串常量池中已经包含一个等于此String对象的 字符串， 则返 回代表池中这个字符串的String对象的引用;
否则， 会将此String对象包含的字符串添加到常量池中， 并且返回此 String对象的引用
代码解释
在JDK 6或更早之前的HotSpot虚拟机中， 常量池都是分配在永久代中， 我们可以通过-XX: PermSize和-XX: MaxPermSize限制永久代的大小
jdk1.6及以前
因为自JDK 7起， 原本存放在 永久代的字符串常量池被移至Java堆之中， 所以在JDK 7及以上版本， 限制方法区的容量对该测试用例来说是毫无 意义的
这时候使用-Xmx参数限制最大堆到6MB就能 够看到以下两种运行结果之一， 具体取决于哪里的对象分配 时产生了溢出:
jdk1.8
运行时常量池内存溢出
方法区的其他部分的内容， 方法区的主要职责是用于存放类型的相关信息， 如类名、 访问修饰符、 常量池、 字段描述、 方法描述等。
对于这部分区域的测试， 基本的思路是运行时产 生大量的类去填满方法区， 直到溢出为止。
虽然直接使用Java SE API也可以动态产生类(如反射时的 GeneratedConstructorAccessor和动态代理等)
借助CGLib使得方法区出现内存溢出异常
思路
在默认设置下， 前面列举的那些正常的动态创建 新类型的测试用例已经很难再迫使虚拟机产生方法区的溢出异常了。
在JDK 8以 后， 永久代便完全退出了历史舞台， 元空间作为其替代者登场。
-XX: MaxMetaspaceSize: 设置元空间最大值， 默认是-1， 即不限制， 或者说只受限于本地内存 大小。
-XX: MetaspaceSize: 指定元空间的初始空间大小， 以字节为单位， 达到该值就会触发垃圾收集 进行类型卸载， 同时收集器会对该值进行调整: 如果释放了大量的空间， 就适当降低该值; 如果释放 了很少的空间， 那么在不超 过-XX: MaxMetaspaceSize(如果设置了的话) 的情况下， 适当提高该值。
-XX: MinMetaspaceFreeRatio: 作用是在垃圾收集之后控制最小的元空间剩余容量的百分比， 可 减少因为元空间 不足导致的垃圾收集的频率。 类似的还有-XX: Max-MetaspaceFreeRatio， 用于控制最 大的元空间剩余容量的百分 比。
防御措施
方法区内存溢出
3.3 运行时常量池和方法区溢出
如果不去指定， 则默认与 Java堆最大值(由-Xmx指定) 一致， 越过了DirectByteBuer类直接通 过反射获取Unsafe实例进行内存分配 (Unsafe类的getUnsafe()方法指定只有引导类加载器才会返回实例
体现了设计者希望只有虚拟机标准类库里面的 类才能使用Unsafe的功能， 在JDK 10时才将Unsafe 的部分功能通过VarHandle开放给外部使用)
直接内存(Direct Memory) 的容量大小可通过-XX: MaxDirectMemorySize参数来指定
因为虽然使用 DirectByteBuer分配内存也会抛出内存溢出异常， 但它抛出异常时并没有真正向操作系统申请分配内存
而是通 过计算得知内存无法分配就会 在代码里手动抛出溢出异常， 真正申请分配内存的方法是Unsafe::allocateMemory()
由直接内存导致的内存溢出， 一个明显的特征是在Heap Dump文件中不会看见有什么明显的异常 情况， 如果发现 内存溢出之后产生的Dump文件很小
而程序中又直接或间接使用了 DirectMemory(典型的间接使用就是NIO) ， 那就可以考虑重点检查一下直接内存方面的原因了。
现象
3.4 直接内存溢出
3.实战OutOfMemmooryError异常
2.java虚拟机的内存管理
1、类加载子系统负责从文件系统或是网络中加载.class文件，class文件在文件开头有特定的文件标识
2、把加载 后的class类信息存放于方法区，除了类信息之外，方法区还会存放运行时常量池信息，可能还包括字符串字面量和 数字常量(这部分常量信息是Class文件中常量池部分的内存映射)
3、ClassLoader只负责class文件的加载，至于 它是否可以运行，则由Execution Engine决定;
4、如果调用构造器实例化对象，则该对象存放在堆区;
1.1 类加载子系统介绍
1. class file 存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到 JVM当中来根据这个文件实例化出n个一模一样的实例。
2. class file 加载到JVM中，被称为DNA元数据模板。
3. 在 .class文件 --> JVM --> 最终成为元数据模板，此过程就要一个运输工具(类装载器Class Loader)，扮演一个快递员的角色。
1.2 类加载器ClassLoader角色
我们知道我们写的程序经过编译后成为了.class文件，.class文件中描述了类的各种信息
最终都需要加载到虚拟机之后才能运行和使用。而虚拟机如何加载这些.class文件?.class文件的信息进入到虚拟机后会发生什么变化
类从被加载到虚拟机内存中开始，到卸载出内存，它的整个生命周期包括
加载是类加载的第一个阶段。有两种时机会触发类加载:
虚拟机启动时加载，加载的是JAVA_HOME/lib/下的rt.jar下的.class文件，这个jar包里面的内容是程序运行时非常常 常用到的，像java.lang.*、java.util. java.io. 等等，因此随着虚拟机一起加载
要证明这一点很简单，写一个空的 main函数，设置虚拟机参数为\"-XX:+TraceClassLoading\"来获取类加载信息，运行一下
1)预加载
虚拟机在用到一个.class文件的时候，会先去内存中查看一下这个.class文件有没有被加载
如果没有就会按照类的全限定名来加载这个类。
2)运行时加载
触发时机
从zip包中获取，这就是以后jar、ear、war格式的基础
从网络中获取，典型应用就是Applet
运行时计算生成，典型应用就是动态代理技术
由其他文件生成，典型应用就是JSP，即由JSP生成对应的.class文件
从数据库中读取，这种场景比较少见
途径
获取.class文件的二进制流
将类信息、静态变量、字节码、常量这些.class文件中的内容放入方法区中
在内存中生成一个代表这个.class文件的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。一般 这个Class是在堆里的，不过HotSpot虚拟机比较特殊，这个Class对象是放在方法区中的
加载阶段做的三件事情
加载(Loading)
是为了确保.class文件的字节流中包含的信息符合当前虚拟机的要求，并且不 会危害虚拟机自身的安全。
目的
在字节码语言层面上，Java代码至少从 语义上是可以表达出来的。
虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节 流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作
原因
文件格式验证
元数据验证
字节码验证
符号引用验证
验证的内容
验证 (Verification)
准备阶段是正式为类变量分配内存并设置其初始值的阶段，这些变量所使用的内存都将在方法区中分配
这时候进行内存分配的仅仅是类变量(被static修饰的变量)，而不是实例变量
实例变量将会在对象实例化 的时候随着对象一起分配在Java堆中
注意点一
这个阶段赋初始值的变量指的是那些不被final修饰的static变量，比如\"public static int value = 123\"，value在准 备阶段过后是0而不是123，给value赋值为123的动作将在初始化阶段才进行
比如\"public static final int value = 123;\"就不一样了，在准备阶段，虚拟机就会给value赋值为123。
注意点二
两个注意点
各个数据类型的零值如下表:
因为局部变量不像类变量那样存在准备阶段
一次在准备阶段，赋予初始值(也可以是指定值);
另外一次在初始化阶段，赋予程序员定义的值。
类变量有两次赋初始值的过程
因此，即使程序员没有为类变量赋值也没有关系，它仍然有一个默认的初始值
但局部变量就不一样了，如果没有给它赋初始值，是不能使用的。
代码一和代码二执行结果不一样的原因
准备(Preparation)
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程 。
符号引用是一种定义，可以是任何字面上的含义，而直接引用就是直接指向目标的指针、相对偏移量。
类和接口的全限定名
字段的名称和描述符
方法的名称和描述符
三类常量
java代码
比如#2，它的值 是\"com/xrq/test6/TestMain\"，表示的是这个类的全限定名;
又比如#5为i，#6为I，它们是一对的，表示变量时 Integer(int)类型的，名字叫做i;
#6为D、#7为d也是一样，表示一个Double(double)类型的变量，名字为d; #18、#19表示的都是方法的名字。
看到Constant Pool也就是常量池中有22项内容，其中带\"Utf8\"的就是符号引用
反编译代码
符号引用和我们上面讲的是一样的，是对于类、变量、方法的描述。
符号引用和虚拟机的内存布局是没有关系的，引用的目标未必已经加载到内存中了。
总结
1、符号引用
直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。
直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机示例上翻译出来的直接引用一般不会相同
如果有了直接引用，那引用的目标必定已经存在在内存中了。
2、直接引用
符号引用和直接引用有什么区别
解析阶段负责把整个类激活，串成一个可以找到彼此的网，过程不可谓不重要
类或接口的解析
类方法解析
接口方法解析
字段解析
解析内容
解析(Resolution)
链接
类的初始化阶段是类加载过程的最后一个步骤， 之前介绍的几个类加载的动作里
除了在加载阶 段用户应用程序 可以通过自定义类加载器的方式局部参与外， 其余动作都完全由Java虚拟机来主导控制
直到初始化阶段， Java 虚拟机才真正开始执行类中编写的Java程序代码， 将主导权移交给应用程序。
()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static{}块) 中的 语句合并产 生的， 编译器收集的顺序是由语句在源文件中出现的顺序决定的
静态语句块中只能访问 到定义在静态语句块之 前的变量， 定义在它之后的变量， 在前面的静态语句块可以赋值， 但是不能访 问
执行动作
()方法与类的构造函数(即在虚拟机视角中的实例构造器()方法) 不同， 它不需要显 式地调用父类构造器
Java 虚拟机会保证在子类的()方法执行前， 父类的()方法已经执行 完毕。
因此在Java虚拟机中第一个被执行的()方法的 类型肯定是java.lang.Object。
由于父类的()方法先执行， 也就意味着父类中定义的静态语句块要优先于子类的变量赋值 操作
如代码清单7-6 中， 字段B的值将会是2而不是1。方法执行顺序package com.lagou.unit2;
()方法对于类或接口来说并不是必需的， 如果一个类中没有静态语句块， 也没有对变量的 赋值操作， 那么编译器 可以不为这个类生成()方法
接口中不能使用静态语句块， 但仍然有变量初始化的赋值操作， 因此接口与类一样 都会生成 ()方法。
执行接口的()方法不需要先执行父接口的()方法， 因为只有当父接口中定义的变量被使用 时， 父接口才会被初始化
此外， 接口的实现类在初始化时也 一样不会执行接口的()方法。
但接口与类不同
Java虚拟机必须保证一个类的()方法在多线程环境中被正确地加锁同步， 如果多个线程同 时去初始化一个类
那 么只会有其中一个线程去执行这个类的()方法， 其他线程都需要阻塞等 待， 直到活动线程执行完毕()方法。
如果在 一个类的()方法中有耗时很长的操作， 那就 可能造成多个进程阻塞， 在实际应用中这种阻塞往往是很隐蔽的
主要是为了让你弄明白类的初始化和对象的初始化之间的差别。
其中 static 字段和 static 代码块，是属于类的，在类的加载的初始化阶段就已经被执行
类信息会被存放在方法 区，在同一个类加载器下，这些信息有一份就够了，所以上面的 static 代码块只会执行一次，它对应的是 方法。
上面代码的 static 代码块只会执行一次，对象的构造方法执行两次。
再加上继承关系的先后原则，不难分析 出正确结果。
方法 的执行时期: 对象的初始化阶段
结论
<cinit>与<init>
初始化(Initiallization)
使用(Using)
卸载 (Unloading)
类使用的7个阶段
加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地 开始
而解析阶段不一定:它在某些情况下可以初始化阶段之后在开始，这是为了支持Java语言的运行时绑定(也 称为动态绑定)
1.3 类加载的执行过程
1.类装载子系统
类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内
然后在创建 一个java.lang.Class对象，用来封装类在方法区内的数据结构。
JVM主要在程序第一次主动使用类的时候，才会去加载该类，也就是说，JVM并不是在一开始就把一个 程序就所有的类都加载到内存中
而是到不得不用的时候才把它加载进来，而且只加载一次。
2.1 类加载器的作用
引导类加载器是由c/c++实现的
1、这个类加载器使用c/c++实现，嵌套再jvm内部
2、它用来加载Java的核心类库(JAVA_HOME/jre/lib/rt.jar、 resource.jar或sun.boot.class.path路径下的内容)，用于提供JVM自身需要的类
3、并不继承自 java.lang.ClassLoader，没有父加载器
引导类加载器BootStrapClassLoader、也叫启动类加载器
加载器
引导类加载器
自定义加载器是由java实现的
jvm规范定义自定义加载器是指派生于抽象类ClassLoder的类加载器。
1、java语言编写，由sun.misc.Launcher$ExtClassLoader实现
2、从java.ext.dirs系统属性所指定的目录中加载类库， 或从JDK的安装目录的jre/lib/ext 子目录(扩展目录)下加载类库。如果用户创建的JAR 放在此目录下，也会自动由 扩展类加载器加载;派生于 ClassLoader。
3、父类加载器为启动类加载器
扩展类加载器 Extension Class Loader
1、java语言编写，由 sun.misc.Lanucher$AppClassLoader 实现
2、该类加载是程序中默认的类加载器，一般来说， Java应用的类都是由它来完成加载的，它负责加载环境变量classpath或系统属性java.class.path 指定路径下的类 库;派生于 ClassLoader
3、父类加载器为扩展类加载器
4、通过 ClassLoader#getSystemClassLoader() 方法可以获取 到该类加载器。
系统类加载器 system Class Loader
在日常的Java开发中，类加载几乎是由三种加载器配合执行的，在必要时我们还可以自定义类加载器，来定制类的 加载方式。
用户自定义类加载器 User-Defined ClassLoader
具体
自定义加载器
类型
图中的加载器划分为包含关系而并非继承关系
代码如何获取
2.2 类加载器分类
2.类加载器
如果一个类加载器收到类加载的请求，它首先不会自己去尝试加载这个类，而是把这个 请求委派给父类加载器完成
每个类加载器都是如此，只有当父加载器在自己的搜索范围内找不到指定的类时 (即 ClassNotFoundException )，子加载器才会尝试自己去加载
工作流程
3.1 什么是双亲委派
如果不使用这种模型，可能带来的安全风险
通过双亲委派模型，JVM保证了像 java.lang.String 这样的重要类只能由顶层类加载器加载，确保任何自定义类加载器都不能覆盖核心类库中的类。
核心类库的保护：
自定义类加载器可以加载用户定义的类，但这些类不会覆盖或者替换核心类
因为自定义类加载器必须先请求父类加载器加载，如果核心类已经由父类加载器加载成功，子类加载器就不会再加载同名类。
安全隔离
如何防止此类攻击
3.2 为什么需要双亲委派模型?
每次通过先委托父类加载器加载，当父类加载器无法加载时，再自己加载。
其实 ClassLoader 类默认的 loadClass 方法已经帮我们写好了，我们无需去写。
说明
1. 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
3. 如果父加载器及 bootstrap 类加载器都没有找到指定的类，那么调用当前类加载器的 findClass 方 法来完成类加载。
具体代码
抽象类 ClassLoader 的 findClass 函数默认是抛出异常的
而前面我们知道， loadClass 在父加载 器无法加载类的时候，就会调用我们自定义的类加载器中的 findeClass 函数
因此我们必须要在 loadClass 这 个函数里面实现将一个指定类名称转换为 Class 对象.
如果自定义类加载器，就必须重写 findClass 方法!
3.3 如何实现双亲委派模型
3.双亲委派机制
比如tomcat这类web应用服务器，内部自定义了好几中类加载 器，用于隔离web应用服务器上的不同应用程序。
隔离加载类
除了Bootstrap加载器外，其他的加载并非一定要引入。根据实际情况在某个时间点按需进行动态加载
修改类加载方式
比如还可以从数据库、网络、或其他终端上加载
扩展加载源
java代码容易被编译和篡改，可以进行编译加密，类加载需要自定义还原加密字节码。
防止源码泄漏
4.1 为什么要自定义类加载器
4.2 自定义函数调用过程
所有用户自定义类加载器都应该继承ClassLoader类
2)重写findClass方法 (推荐)
实现方式
测试类
我是由 class Main$MyClassLoader 加载进来的
运行结果
类加载器
4.3 自定义类加载器实现
4.自定义类加载器
关系类图
5.1 类的关系图
创建扩展类加载器
创建应用程序类加载器
设置ContextClassLoader
如果需要安装安全管理器 security manager
构造方法 Launcher() 中做了四件事情
关键的几步
ExtClassLoader的创建中的关键几步
关键几个步骤
AppClassLoader的创建中的关键几步
启动类
5.2 Launcher核心类的源码剖析
参考原文档
5.3 ClassLoader 源码剖析
5.classLoader源码解析
3.JVM加载机制详解
哪些内存需要回收?
什么时候回收?
如何回收?
垃圾回收主要完成的三件事
a.不需要考虑内存管理，
b.可以有效的防止内存泄漏，有效的利用可使用的内存，
c.由于有垃圾回收机制，Java中的对象不再有\"作用域\"的概念，只有对象的引用才有\"作用域\"
优点
缺点
java垃圾回收的优缺点:
给每个创建的对象添加一个引用计数器，每当此对象被某个地方引用时，计数值+1， 引用失效时-1，所以当计数值为0时表示对象已经不能被使用
实现思路
实现简单，执行效率高，很好的和程序交织。
譬如有A和B两个对象，他们都互相引用，除此之外都没有任何对外的引用，那么理论上A和B都可以被作为垃 圾回收掉
但实际如果采用引用计数算法，则A、B的引用计数都是1，并不满足被回收的条件，如果A和B之 间的引用一直存在，那么就永远无法被回收了
无法检测出循环引用。
在java程序中这两个对象仍然会被回收，因为java中并没有使用引用计数算法。
判断对象是否存活-引用计数算法
在主流的商用程序语言如Java、C#等的主流实现中，都是通过可达性分析(Reachability Analysis)来判断对象是否存 活的。
通过一系列的“GC Roots”的对象作为起始点，从起始点开始向下搜索到对象的路径。
搜索所经过的路径称为引用链(Reference Chain)，当一个对象到任何GC Roots都没有引用链时，则表明对象“不可 达” ，即该对象是不可用的。
栈帧中的局部变量表中的reference引用所引用的对象
方法区中static静态引用的对象
方法区中final常量引用的对象
本地方法栈中JNI(Native方法)引用的对象
Java虚拟机内部的引用， 如基本数据类型对应的Class对象， 一些常驻的异常对象(比如 NullPointExcepiton、 OutOfMemoryError) 等， 还有系统类加载器
所有被同步锁(synchronized关键字) 持有的对象。
反映Java虚拟机内部情况的JMXBean、 JVMTI中注册的回调、 本地代码缓存等。
GC ROOt对象
2.2.1 可达性分析算法
最终判定对象是否存活:
即使在可达性分析算法中判定为不可达的对象， 也不是“非死不可”的， 这时候它们暂时还处于“缓 刑”阶段， 要真 正宣告一个对象死亡， 至少要经历两次标记过程
finalize()方法
如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链， 那它将会被第一次标记，随后进行一次筛选
假如对象没有覆盖finalize()方法， 或者finalize()方法已经被虚拟机调用过， 那么虚拟机将这两种情况都视为“没有必 要执行”。
没有必要:
如果这个对象被判定为确有必要执行finalize()方法， 那么该对象将会被放置在一个名为F-Queue的 队列之中
并在 稍后由一条由虚拟机自动建立的、 低调度优先级的Finalizer线程去执行它们的finalize() 方法
finalize()方法是对 象 逃脱死亡命运的最后一次机会，
譬如把自己 (this关键字) 赋值 给某个类变量或者对象的成员变量， 那在第二次标记时它将被移出“即将回收”的集 合;
如果对 象要在 finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可
如果对象这时候还没有逃 脱， 那基本上它就真的要被回收了。
稍后收集器将对F-Queue中的对象进行第二次小规模的标记
有必要:
筛选的条件是此对象是否有必要执行finalize()方法
第一次标记
两次标记处理流程
这样做的原因是， 如果某个对象的finalize()方法执行缓慢， 或者更极端地发生了死循环
将很可能导致F-Queue队列中的其他对象永久处于等待， 甚至导致整个内存回收子系统的崩溃。
2.2.2JVM之判断对象是否存活
Java中引用的定义很传统: 如果引用类型的数据中存储的数值代表的是另一块内存的起始地址，就 称这块内存代表着一个引用
这种定义有些狭隘，一个对象在这种定义下只有被引用或者没有被引用两种状态。
当内存空间还足够时，则能保存在内存中;
如果内存空间在进行垃圾回收后还是非常紧 张，则可以抛弃这些对象
场景
在JDK1.2以前
Java对引用的概念做了扩 充
强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它
当内存空间不足，Java虚拟 机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问 题。
A a = new A()
(1)强引用(StrongReference)
如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它;
如果内存空间不足了，就会回收这些对象的内存。
只要垃圾回收器没有回收它，该对象就可以被程序使用。
软引用可以和一个引用队列 (ReferenceQueue)联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到 与之关联的引用队列中。
(2)软引用(SoReference)
用来描述那些非必须对象， 但是它的强度比软引用更弱一些， 被弱引用关联的对象只能生存到下一次垃圾收集发 生为止
当垃圾收集器开始工作， 无论当前内存是否足够， 都会回收掉只 被弱引用关联的对象
在JDK 1.2版之 后提供了WeakReference类来实现弱引用
弱引用可以和一个引用队列(ReferenceQueue)联合使用，如果弱引用 所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。
1更短暂的生命周期;
2一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。
弱引用与软引用的区别在于 :
(3)弱引用(WeakReference)
“虚引用”顾名思义，它是最弱的一种引用关系。
虚引用主要用来跟踪对象被垃圾回收器回收的活动。
1虚引用必须和引用队列 (ReferenceQueue)联合使用。
2当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到 与之 关联的引用队列中。
虚引用与软引用和弱引用的一个区别在于 :
(4)虚引用(PhantomReference)
引用分类
在JDK1.2之后
2.2.3 再谈引用
判断对象是否存活-可达性分析算法
2.垃圾回收-对象是否已死
根据对象的生命周期将内存划分，然后进行分区管理。
思想
1) 弱分代假说(Weak Generational Hypothesis) : 绝大多数对象都是朝生夕灭的。
2) 强分代假说(Strong Generational Hypothesis) : 熬过越多次垃圾收集过程的对象就越难以消亡。
实际的经验法则建立在两个分代假说之上
最早出现也是最基础的垃圾收集算法是“标记-清除”(Mark-Sweep) 算法
在1960年由Lisp之父 John McCarthy所 提出
首先标记出所有需要回 收的对象， 在标记完成后
算法分为“标记”和“清除”两个阶段
如果Java堆中包含大量对象， 而且其中大部分是需要被回收的
这时必须进行大量标记和清除的动作， 导致标记和清除两个过 程的执行效率都随对象数量增长而降低;
第一个是执行效率不稳定
标记、 清除之后会产生大 量不连续的内存碎片
空间碎片太多可能会导致当以 后在程序运行过程中需要分配较大对象时无法找 到足够的连续内存而不得不提前触发另一次垃圾收集动作。
第二个是内存空间的碎片化问题
标记-清除算 法
面对大量可回收对象时执行效率低的问题
1969年Fenichel提出了一种称为“半区复 制”(Semispace Copying) 的垃圾收集算法， 它将可用 内存按容量划分为大小相等的两块
每次只使用其中的一 块。 当这一块的内存用完了， 就将还存活着 的对象复制到另外一块上面
然后再把已使用过的内存空间一次清理 掉
1)需要提前预留一半的内存区域用来存放存活的对象(经过垃圾收集后还存活的对象)，这样导致可用的对 象区域减小一半，总体的GC更加频繁了
2)如果出现存活对象数量比较多的时候，需要复制较多的对象，成本上升，效率降低
3)如果99%的对象都是存活的(老年代)，那么老年代是无法使用这种算法的。
IBM公司曾有一项专门研 究对新生代“朝生 夕灭”的特点做了更量化的诠释——新生代中的对象有98%熬不过第一轮收集
因此 并不需要按照1∶1的比例来划分 新生代的内存空间。
发生垃圾搜集时， 将Eden和Survivor中仍 然存活的对象一次性复制到 另外一块Survivor空间上， 然后直接清理掉Eden和已用过的那块Survivor空 间
HotSpot虚拟机默认Eden和Survivor 的大小比例是8∶1， 也即每次新生代中可用内存空间为整个新 生代容量的90%(Eden的80%加上一个Survivor的 10%)
只有一个Survivor空间， 即10%的新生代是会 被“浪费”的
Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的 Survivor空间， 每 次分配内存只使用Eden和其中一块Survivor。
现状
标记-复制算法
标记-复制算法在对象存活率较高时就要进行较多的复制操作， 效率将会降低。
如果不想浪费50%的 空间， 就需要有额外的空间进行分配担保， 以应对被使用的内存中所有对象都100%存活的极端情况， 所以在老年 代一般不能直接选用这种算法。
其中的标记过程仍然与“标记-清除”算法一样， 但后续步骤不是直接对可回收对象进行清理
而是让所有存活 的对象都向内存空间一端移动， 然后直接清理掉边界以外的内存 。
前者是一种非移动式的回收算法， 而后者是移动式的
是否移动 回收后的存活对象是一项优缺点并存的风险决策:
标记-清除算法与标记-整理算法的本质差异
是否移动对象都存在弊端， 移动则内存回收时会更复杂， 不移动则内存分配时会更复杂
从垃圾收集的停顿时间 来看， 不移动对象停顿时间会更短， 甚至可以不需要停顿， 但是从整个程序的吞吐量来看， 移动对象会更划算。
标记-整理算法
对不同的区域安 排与里面存储对象存亡特征 相匹配的垃圾收集算法
- 新生代收集(Minor GC/Young GC): 指目标只是新生代的垃圾收集。
- 老年代收集(Major GC/Old GC): 指目标只是老年代的垃圾收集，目前只有CMS收集器会有单 独收集老年代的行为。
- 混合收集(Mixed GC): 指目标是收集整个新生代以及部分老年代的垃圾收集。 目前只有G1收集器会有这种行为。
部分收集(Partial GC) : 指目标不是完整收集整个Java堆的垃圾收集， 其中又分为:
整堆收集(Full GC) : 收集整个Java堆和方法区的垃圾收集
回收类型
分代收集理论
3.垃圾收集算法
引用计数法
可达性分析算法
第一类算法判断对象生死算法
标记-清除算法
一般的实现采用分代回收算法
第二类收集死亡对象方 法有四种
垃圾回收算法分类
垃圾回收算法是内存回收的方法论
垃圾收集器是算法的落地实现 。
和回收算法一样，目前还没有出现完美的收集器，而是要根据具体的应用场景选择最合适的收集器，进行分代收集。
1.新生代串行回收器
1.老年代串行回收器
种类
串行垃圾回收是为单线程环境设计且只使用一个线程进行垃圾回收，会暂停所有的用户线程
不适合交互性强的服务器环境
串行回收器
1.新生代parNew回收器
2.新生代ParallelGC回收器
3.老年代ParallelGC回收器
多个垃圾收集器线程并行工作，同样会暂停用户线程，适用于科学计算、大数据后台处理等多交互场景。
并行回收器
用户线程和垃圾回收线程同时执行，不一定是并行的，可能是交替执行，可能一边垃圾回收，一边运行应用线程
不需要停顿用户线程，互联网应用程序中经常使用，适用对响应时间有要求的场景。
CMS回收器
G1垃圾回收器将堆内存分割成不同的区域然后并发地对其进行垃圾回收。
G1回收器
单线程收集器，“单线程”的意义不仅仅说明它只会使用一个CPU或一个收集线程去完成垃圾收集工作;
更重要的是它在垃圾收集的时候，必须暂停其他工作线程，直到垃圾收集完毕;
Serial收集器由于简单并且高效;
对于单CPU环境来说，由于Serial收集器没有线程间的交互，专心做垃圾收集自然可以做获得最高的垃圾收集效率
-XX:+UseSerialGC
使用方式
Serial收集器
ParNew收集器实质上是Serial收集器的多线程并行版本， 除了同时使用多条线程进行垃圾收集之 外
其余的行为 包括Serial收集器可用的所有控制参数 、 收集算法、 Stop The World、 对象分配规则
回收策略等都与Serial收集 器完全一致， 在实现上这两种收集器也共用了相当多的代码.
但是在多CPU服务器上，效果会明显比Serial好
ParNew收集器在单CPU服务器上的垃圾收集效率绝对不会比Serial收集器高;
ParNew 收集器
又称为吞吐量优先收集器，和ParNew收集器类似，是一个 新生代收集器
使用复制算法的并行多线程收集器。 Parallel Scavenge是Java1.8默认的收集器，特点是并行的多线程回收，以吞吐量优先。
Parallel Scavenge收集器的目标是达到一个可控制的吞吐量(Throughput); 吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间) (虚拟机总共运行100分钟，垃圾收集时间为1分钟，那么吞吐量就是99%)
适合后台运算，交互不多的任务，如批量处理，订单处理，科学计算等。
使用方式:-XX:+UseParallelGC
分别是控制:最大垃圾收集停顿时间-XX:MaxGCPauseMillis
吞吐量大小-XX:GCTimeRatio
设置年轻代线程数 XX:ParllGCThreads
参数
Parallel Scavenge收集器
新生代垃圾收集器:
Serial Old是Serial收集器的老年代版本， 它同样是一个单线程收集器， 使用标记-整理算法
这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。
针对老年代;
采用\"标记-整理\"算法;
单线程收集;
1)在JDK1.5及之前，与Parallel Scavenge收集器搭配使用(JDK1.6有Parallel Old收集器可搭配);
2)作为 CMS收集器的后备预案 ，在并发收集发生Concurrent Mode Failure时使用
应用场景:主要用于Client模式
使用方式:-XX:+UseSerialGC
参数设置
需要说明一下， Parallel Scavenge收集器架构中本身有PS MarkSweep收集器来进行老年代收集， 并非 直接调用 Serial Old收集器
但是这个PS MarkSweep收集器与Serial Old的实现几乎是一样的， 所以在官方的许多资料中都是 直接以Serial Old代替PS MarkSweep进行讲解.
注意事项
Serial Old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本， 支持多线程并发收集， 基于标记-整理算法实现
这个收集器 是直到JDK 6时才开始提供的， 在此之前， 新生代的Parallel Scavenge收集器一直处于相 当尴尬的状态
原因是如 果新生代选择了Parallel Scavenge收集器， 老年代除了Serial Old(PS MarkSweep) 收集器以外别无选择
其他表 现良好的老年代收集器， 如CMS无法与它配合工作。
JDK1.6及之后用来代替老年代的Serial Old收集器;
特别是在Server模式，多CPU的情况下;
这样在注重吞吐量以及CPU资源敏感的场景，就有了Parallel Scavenge加Parallel Old收集器的\"给力\"应用组合;
应用场景
\"-XX:+UseParallelOldGC\":指定使用Parallel Old收集器;
设置参数
Parallel Old收集器
CMS(concurrent mark sweep)是以获取最短垃圾收集停顿时间为目标的收集器
目前很大一部分的java应用几种在互联网 的B/S系统服务器上，这类应用尤其注重服务器的响应速度
系统停顿时间最短，给用户带来良好的体验，CMS收集器使用的算法是标记-清除算法实现的;
这个阶段程序所有的工作线程都将会因为\"Stop-the-Wold\"机制而出现短暂的的 暂停
这个阶段的主要任务标记处GC Roots 能够关联到的对象.一旦标记完成后就恢复之前被暂停的的所有应 用
由于直接关联对象比较小，所以这里的操作速度非常快。
1)初始标记
2) 并发标记
由于并发标记阶段，程序的工作线程会和垃圾收集线程同时运行或者交叉运行
为了修正并发标记期间因为用户继续运行而导致标记产生变动的那一部分对象的标记记录
这个阶段 的停顿时间通常比初始标记阶段长一些，但也远比并发标记阶段时间短。
3) 重新标记
由于不需 要移动存活对象，所以这个阶段可以与用户线程同时并发运行。
4) 并发清除
4个步骤
收集过程
由于最消耗事件的并发标记与并发清除阶段都不需要暂停工作，因为整个回收阶段是低停顿(低延迟)的。
当前主流编程语言的垃圾收集器基本上都是依靠可达性分析算法来判定对象 是否存活的，
可达性分析算法理论上要求全过程都基于一个能保障一致性的快照中才能够进行分析。
1. 标记 出哪些对象是存活的，哪些是垃圾(可回收);
2. 进行 回收 (清除/复制/整理)，如果有移动过对象(复制/整理)，还需要更新引用。
垃圾回收器的工作流程大体如下:
三色标记(Tri-color Marking)作为工具来辅助推导， 把遍历对象图过程中遇到的对象， 按照“是否访问过”这个条 件标记成以下三种颜色:
要找出存活对象，根据可达性分析，从GC Roots开始进行遍历访问，可达的则为存活对象:
白色 :尚未访问过。
黑色:本对象已访问过，而且本对象 引用到 的其他对象 也全部访问过了。
灰色:本对象已访问过，但是本对象 引用到 的其他对象尚未全部访问完。全部访问后，会转换为黑色。
三种颜色
1. 初始时，所有对象都在 【白色集合】中;
2. 将GC Roots 直接引用到的对象 挪到 【灰色集合】中;
3.1. 将本对象 引用到的 其他对象 全部挪到 【灰色集合】中;
3.2. 将本对象 挪到 【黑色集合】里面。
3. 从灰色集合中获取对象:
4. 重复步骤3，直至【灰色集合】为空时结束。
5. 结束后，仍在【白色集合】的对象即为GC Roots 不可达，可以进行回收。
注:如果标记结束后对象仍为白色，意味着已经“找不到”该对象在哪了，不可能会再被重新引用。
遍历过程
对象间的引用 是不会发生变化的，可以轻松完成标记。
假设已经遍历到E(变为灰色了)，此时应用执行了 objD.fieldE = null :
此刻之后，对象E/F/G是“应该”被回收的。然而因为 E已经变为灰色 了，其仍会被 当作存活对象 继续遍历下去
最终 的结果是:这部分对象仍会被标记为存活，即 本轮GC不会回收这部分内存 。
这部分本应该回收 但是 没有回收到的内存，被称之为“浮动垃圾”。
。浮动垃圾并不会影响应用程序的正确性，只是 需要等到下一轮垃圾回收中才被清除。
影响范围
多标-浮动垃圾
假设GC线程已经遍历到E(变为灰色了)，此时应用线程先执行了:
此时切回GC线程继续跑，因为 E已经没有对G的引用了，所以不会将G放到灰色集合 ;
尽管因为D重新引用了G，但 因为D已经是黑色了，不会再重新做遍历处理
最终导致的结果是:G会一直停留在白色集合中，最后被当作垃圾 进行清除
这直接 影响到了应用程序的正确性 ，是不可接受的。
条件一:灰色对象 断开了 白色对象的引用;即灰色对象 原来成员变量的引用 发生了变化。
条件二:黑色对象 重新引用了 该白色对象;即黑色对象 成员变量增加了 新的 引用。
需要同时满足两个条件
我们只要在上面这三步中的任意一步中做一些“手脚”， 将对象G记录起来，然后作为灰色对象再进行遍历 即可
比 如放到一个特定的集合，等初始的GC Roots遍历完(并发标记)，该集合的对象 遍历即可(重新标记)。
解决思路
因为应用程序一直在跑的话，该集合可能会一直增加新的对象，导致永远都跑不 完。
当然，并发标记期间也可以将该集合中的大部分先跑了，从而缩短重新标记STW的时间，这个是优化问 题了
重新标记是需要STW
方案
代码的角度
漏标
而当需要支持并 发标记时，即标记期间应用线程还在继续跑， 对象间的引用可能发生变化 ， 多标 和 漏标 的情况就有可能发生。
Stop The World (以下简称 STW)
三色标记
并发可达性分析
其实，面向并发设计的程序都对CPU资源比较敏感
在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用 了一部分线程而导致应用程序变慢，总吞吐量会降低。
CMS默认启动的回收线程数是(处理器核心数量 +3) /4， 也就是说， 如果处理器核心数在四个或以上， 并发回收时垃圾收集线程只占用不超过25%的 处理器运算资源， 并 且会随着处理器核心数量的增加而下降。
但是当处理器核心数量不足四个时， CMS对用户程序的影响就可能变得 很大
如果应用本来的处理器负载就很高， 还要分出一半的运算能 力去执行收集器线程， 就可能导致用户程序的 执行速度忽然大幅降低。
1.CMS收集器对CPU资源非常敏感。
由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在 标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为\"浮动垃 圾\"
同样也是由于在垃圾收集阶段用户线程还需要持续运 行， 那就还需要预留足够内存空间提供给用户线程使 用， 因此CMS收集器不能像其他收集器那样等待 到老年代几乎完全被填满了再进行收集， 必须预留一部分空间供 并发收集时的程序运作使用。
2.CMS收集器无法处理浮动垃圾，可能出现\"Concurrent Mode Failure\"失败而导致另一次Full GC的产生。
当空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。
为了解决这个问题， CMS收集器提供了一个-XX: +UseCMS-CompactAtFullCollection开关参数(默认是开启的， 此 参数从 JDK 9开始废弃) ， 用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程， 由于这个 内存 整理必须移动存活对象， 是无法并发的
3.空间碎片:CMS是一款基于标记-清除算法实现的收集器，所有会有空间碎片的现象。
CMS 收集器
老年代垃圾收集器:
Garbage First是一款面向服务端应用的垃圾收集器，主要针对配备多核CPU及大容量内存的机器
以极高概率满足 GC停顿时间的同时，还兼具高吞吐量的性能特征。
4.8.1 G1垃圾收集器简介
1. G1把内存划分为多个独立的区域Region
3. G1能够充分利用多CPU、多核环境硬件优势，尽量缩短STW
4.8.2 G1收集器特点
G1不再坚持固定大小以及固定数量的 分代区域划分， 而是把连续的Java堆划分为多个独立区域(Region)
每一 个Region都可以 根据需要， 扮演新生代的Eden空间、 Survivor空间， 或者老年代空间。
(1)将整个堆空间细分为若干个小的区域。
4.8.3 Region区域
选定所有年轻代里的Region
通过控制年轻代的region个数，即年轻代内存大小，来控制young GC 的时间开销。
堆分为大约2000个区域。最小大小为1Mb，最大大小为32Mb。
蓝色区域保存老年代对象，绿色区域保存年轻对象。
YoungGC执行前
将存活的对象(即复制或移动)到一个或多个幸存者区域。
如果满足老化阈值，则某些对象将被提升到老年代区域。
执行YoungGC
最近升级的对象以深蓝色显示。幸存者区域为绿色。
堆是单个内存空间，分为多个区域。
年轻代内存由一组非连续区域组成。
年轻一代的垃圾收集器或年轻的GC出现STW。将停止所有应用程序线程以进行操作。
年轻的GC使用多个线程并行完成。
将活动对象复制到新的幸存者或老年代的地区。
总而言之，关于G1的年轻一代，可以说以下几点:
G1的年轻GC结束
Young GC
选定所有年轻代里的Region，外加根据global concurrent marking统计得出收集收益高的若干老年代 Region
在用户指定的开销目标范围内尽可能选择收益高的老年代Region。
和CMS一样只标记GC Roots直接关联的对象
存活的对象的初始标记背负在年轻的垃圾收集器上
在日志中，此标记为 GC pause (young)(inital-mark) 。
初始标记
进行GC Roots Traceing过程
如果找到空白区域(如“ X”所示)，则在Remark阶段将其立即删除
另外，计算确定活跃度的信息
并发标记
空区域将被删除并回收。现在可以计算所有区域的区域活跃度。
最终标记
根据时间来进行价值最大化收集
G1选择“活度”最低的区域，这些区域可以被最快地收集
然后与年轻的GC同时收集这些区域。这在日志中表示为 [GC pause (mixed)] 。因此，年轻代和老年代都是同时收集的。
筛选回收阶段/复制清理阶段(Cleanup，STW)
选定的区域已被收集并压缩为图中所示的深蓝色区域和深绿色区域。
筛选回收阶段-(复制/清理)阶段之后
筛选回收
四个阶段
Mixed GC
两种GC模式
活动信息是在应用程序运行时同时计算的。
该活动信息标识在疏散暂停期间最适合回收的区域。
像CMS中没有清扫阶段。
并发标记阶段
使用开始快照(SATB)算法，该算法比CMS使用的算法快得多。
完全回收空区域。
最终标记阶段
同时回收年轻一代和老一代。
老年代地区是根据其活跃度来选择的。
筛选回收阶段
4.8.4 G1 GC过程
4.8.5 G1常用参数
整理收集器:G1
分代思想
JDK8中默认使用组合是: Parallel Scavenge GC 、ParallelOld GC
JDK9默认是用G1为垃圾收集器
JDK14 弃用了: Parallel Scavenge GC 、Parallel OldGC
JDK14 移除了 CMS GC
垃圾收集器的组合关系
七种垃圾收集器及其组合关系
垃圾收集器
即CPU用于运行用户代码的时间与CPU总消耗时间的比值(吞吐量 = 运行用户代码时间 / ( 运行用户代码时间 + 垃圾收集时间 ))
例如:虚拟机共运行100分钟，垃圾收集器花掉1分钟，那么吞吐量就是99%
吞吐量
执行垃圾回收时，程序的工作线程被暂停的时间
暂停时间
java堆所占内存的大小
内存占用
垃圾收集的频次
收集频率
4.GC性能指标
4.1垃圾收集器概述
4.垃圾收集器
4.垃圾回收机制及算法
jps 是Java版的ps命令，查看java进程及其相关的信息，如果你想找到一个java进程的pid
那可以用jps命令替代linux中的ps命令了，简单而方便。
-q : 显示进程id
options参数解释:
hostid : 主机或其他服务器ip
jps [options] [hostid]
命令格式
jps -l 输出jar包路径，类全名
jps -m 输出main参数
jps -v 输出JVM参数
示例
jinfo是用来查看JVM参数和动态修改部分JVM参数的命令
no options 输出所有的系统属性和参数
-flag 打印指定名称的参数
-flag [+|-] 打开或关闭参数
-flag = 设置参数
-flags 打印所有参数
-sysprops 打印系统配置
其中11666为pid
jinfo [option] <pid>
jinfo 11666
jinfo -flags 11666
jinfo -sysprops 11666
查看JVM参数和系统配置
jinfo -flag PrintGC 11666
jinfo -flag PrintGCDetails 11666
查看打印GC日志参数
jinfo -flag +PrintGC 11666
打开GC日志参数
jinfo -flag -PrintGC 11666
jinfo -flag -PrintGCDetails 11666
关闭GC日志参数
常用示例
参考代码
还可以使用下面的命令查看那些参数可以使用jinfo命令来管理:
1.2 jinfo
jstat命令是使用频率比较高的命令，主要用来查看JVM运行时的状态信息，包括内存状态、垃圾回收等。
-class class loader的行为统计
-compiler HotSpt JIT编译器行为统计
-gc 垃圾回收堆的行为统计
-gcutil 垃圾回收统计概述
-gccause 垃圾收集统计概述(同-gcutil)，附加最近两次垃圾回收事件的原因
-gcnew 新生代行为统计
-gcnewcapacity 新生代与其相应的内存空间的统计
-gcold 年老代和永生代行为统计
-gcoldcapacity 年老代行为统计
-printcompilation HotSpot编译方法统计
option参数解释:
其中VMID是进程id
interval是打印间隔时间(毫秒)
count是打印次数(默认一直打印)
jstat [option] VMID [interval] [count ]
11666为pid，每隔1000毫秒打印一次，打印3次
S0 survivor0使用百分比
S1 survivor1使用百分比
E Eden区使用百分比
O 老年代使用百分比
M 元数据区使用百分比
CCS 压缩使用百分比
YGC 年轻代垃圾回收次数
YGCT 年轻代垃圾回收消耗时间
FGC Full GC垃圾回收次数
FGCT Full GC垃圾回收消耗时间
GCT 垃圾回收消耗总时间
字段解释
jstat -gcutil 11666 1000 3
-gc和-gcutil参数类似，只不过输出字段不是百分比，而是实际的值。
S0C survivor0大小
S1C survivor1大小
S0U survivor0已使用大小
S1U survivor1已使用大小
EC Eden区大小
EU Eden区已使用大小
OC 老年代大小
OU 老年代已使用大小
MC 方法区大小
MU 方法区已使用大小
CCSC 压缩类空间大小
CCSU 压缩类空间已使用大小
jstat -gc 11666 1000 3
1.3 jstat
jstack是用来查看JVM线程快照的命令，线程快照是当前JVM线程正在执行的方法堆栈集合
使用jstack命令可以定 位线程出现长时间卡顿的原因，例如死锁，死循环等
jstack还可以查看程序崩溃时生成的core文件中的stack信 息。
-F 当使用jstack 无响应时，强制输出线程堆栈。
-m 同时输出java堆栈和c/c++堆栈信息(混合模式)
jstack [options]
1.使用Process Explorer工具找到cpu占用率较高的线程
2.在thread卡中找到cpu占用高的线程id
3.线程id转换成16进制
4.使用jstack -l 查看进程的线程快照
cpu占用过高问题
jstack -l 11666
执行指令:
打印结果
jstack检查死锁问题
1.4 jstack
jmap可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及finalizer 队列
如果使用不带选项参数的jmap打印共享对象映射，将会打印目标虚拟机中加载的每个共享对象的起始 地址、 映射大小以及共享对象文件的路径全称。
-heap 打印java heap摘要
-histo[:live] 打印堆中的java对象统计信息
-clstats 打印类加载器统计信息
-finalizerinfo 打印在f-queue中等待执行finalizer方法的对象
dump-options:
live 只转储存活的对象，如果没有指定则转储所有对象
format=b 二进制格式
file= 转储文件到
-dump: 生成java堆的dump文件
jmap [option] (连接正在执行的进程)
这个命令是要把java堆中的存活对象信息转储到dump.bin文件
输出结果的含义为当前没有在等待执行finalizer方法的对象
jmap -finalizerinfo 11666
输出堆的详细信息
jmap -heap 11666
输出存活对象统计信息
jmap -histo:live 11666 | more
1.5 jmap
jhat是用来分析jmap生成dump文件的命令，jhat内置了应用服务器，
可以通过网页查看dump文件分析结果，jhat一般是用在离线分析上。
-stack false: 关闭对象分配调用堆栈的跟踪
-refs false: 关闭对象引用的跟踪
-port : HTTP服务器端口，默认是7000
-debug : debug级别
-version 分析报告版本
jhat [option][dumpfile]
jhat dump.bin
1.6 jhat
1.常用指令
直接在jdk/bin目录下点击jconsole.exe即可启动
1.代码准备
3.运行监控代码
“概述”页
在\"内存\
内存页面
启动后主界面如下
监视和管理控制台
4.各个界面情况
2.1.1 内存监控
查看CPU使用率及活锁阻塞线程
线程死锁如图图所示
2.1.2 线程监控
2.1 Jconsole 监控管理工具
VisualVM 对 Java Development Kit (JDK) 工具所检索的 JVM 软 件相关数据进行组织，并通过一种使您可以快速查看有关多个 Java 应用程序的数据的方式提供该信息
您可以查 看本地应用程序以及远程主机上运行的应用程序的相关数据。
此外，还可以捕获有关 JVM 软件实例的数据，并将该 数据保存到本地系统，以供后期查看或与其他用户共享。
2.2.1 简介
显示虚拟机进程和进程的配置、环境信息( jps、jinfo)
监视应用程序的CPU、GC、堆、方法区及线程的信息( jstat、jstack)
dump及分析堆转储快照( jmap、jhat)
功能特性
主程序界面
安装方法
2.2.2 概述与插件安装
在\"应用程序\
在\"监视\"页签中选择\"堆 Dump\"
两种方式生成堆dump文件
2.2.3 堆转储快照
CPU分析将会统计每个方法的执行次数、执行耗时; 内存分析则会统计每个方法关联的对 象数及对象所占空间。
2.2.4 分析程序性能
2.2 VisualVM 可视化优化工具
2. JVM常用工具
5.常用指令与可视化调优工具
GC日志是一个很重要的工具，它准确记录了每一次的GC的执行时间和执行结果
通过分析GC日志可以优化堆设置和GC设置，或者改进应用程序的对象分配模式。
不同的垃圾收集器，输出的日志格式各不相同，但也有一些相同的特征
熟悉各个常用垃圾收集器的GC日志，是 进行JVM调优的必备一步。 解析GC日志，首先需要收集日志，常用的有以下JVM参数用来打印输出日志信息:
日志参数
使用如下参数启动:
1.1 GC日志参数
1.2 常用垃圾收集器参数
1.GC日志参数
GC 日志理解起来十分简单，因为日志本来就是要给开发人员看的，所以设计的很直观。
a: GC 或者是 Full GC
b: 用来说明发生这次 GC 的原因
c: 表示发生GC的区域，这里表示是新生代发生了GC，上面那个例子是因为在新生代中内存不够给新对象分配了，然后触发了 GC
d: GC 之前该区域已使用的容量
e: GC 之后该区域已使用的容量
f: 该内存区域的总容量
g: 表示该区域这次 GC 使用的时间
h: 表示 GC 前整个堆的已使用容量
i: 表示 GC 后整个堆的已使用容量
j: 表示 Java 堆的总容量
k: 表示 Java堆 这次 GC 使用的时间
l: 代表用户态消耗的 CPU 时间
m: 代表内核态消耗的 CPU 时间
n: 整个 GC 事件从开始到结束的墙钟时间(Wall Clock Time)
将上面 GC 日志抽象为各个部分，然后我们再分别说明各个部分的含义
2.1 日志的含义
-Xms20M -Xmx20M -Xmn10M -XX:+UseParNewGC -XX:+PrintGCDetails -XX:SurvivorRatio=8
设置JVM参数
测试代码
因为分配allocation的时 候，Eden区已经没有足够的区域来分配了，所以发生来本次 MinorGC
经过 MinorGC 之后新生代的已使用容量从 6146K->753K，然而整个堆的内存总量却几乎没有减少
原因就是，由于发现新生代没有可以回收的对象，所以不 得不使用内存担保将allocation1~3 三个对象提前转移到老年代
此时再在 Eden 区域为 allocation 分配 4MB 的空 间，因此最后我们发现 Eden 区域占用了 4MB，老年代占用了 6MB
2.2使用ParNew+Serial Old的组合进行内存回收
此时再在 Eden 区域为 allocation 分配 4MB 的空 间，因此最后我们发现 Eden 区域占用了 4MB，老年代占用了 6MB
执行结果
2.3使用Parallel Scavenge+Parallel Old的组合进行内存回收
大对象直接进入老年代 虚拟机提供一个参数 -XX:PretenureSizeThreshold 用来设置直接在老年代分配的 对象的大小
如果对象大于这个值就会直接在老年代分配。这样做的目的是避免在 Eden 区及两个Survivor 区之间发生大量的内存复制。
-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+UseParNewGC -XX:+PrintGCDetails -XX:PretenureSizeThreshold=3145728
通过上面的堆的内存占用情况很容易看出我们分配的4MB大小的对象直接被放到了老年代
结果分析
2.4 大对象回收分析
2.GC日志分析
通过GC日志可视化分析工具，我们可以很方便的看到JVM各个分代的内 存使用情况、垃圾回收次数、垃圾回收的原因、垃圾回收占用的时间、吞吐量等
这些指标在我们进行JVM调优的 时候是很有用的。
可以通过GC日志分析进行内存泄露检测、GC暂停原因分析、JVM配置建 议优化等功能，而且是可以免费使用
在线分析工具 https://gceasy.io/index.jsp
GCeasy是一款在线的GC日志分析器
免费开源使用，你需要安装jdk或者java环境才可以使用。
软件为GC日志分析人员提供了强大的功能支持，有利于大大提高分析效率
GCViewer是一款实用的GC日志分析软件
两个可视化工具
3.1 日志工具简介
编写代码生成gc.log日志准备分析
在d:/logs/gc.log 生成日志
3.2 测试准备
这是一个在线分析日志的工具，主要功能是免费的，存在部分收费，地址: https://gceasy.io/
jvm堆:
关键绩效指标:
交互式图表:
3.3 GCeasy
GCViewer是一个小工具，可以可视化展示 生成的详细GC输出。支持Sun / Oracle，IBM，HP和BEA的Java虚拟机。它是GNU LGPL下发布的免费软件。
介绍
https://sourceforge.net/projects/gcviewer /
下载地址
java -jar gcviewer-1.37-SNAPSHOT.jar
使用简介
打开之后，点击File->Open File打开我们的GC日志，可以看到如下图，图标是可以放大缩小的
主要内容就是红线 圈住的部分，里面的内容跟上面的GCeasy的比较类似，具体的可以看下GitHub中的描述。
打开gc文件
3.4 GCViewer
3.日志分析工具
6.GC日志分析
tomcat服务器在JavaEE项目中使用率非常高，所以在生产环境对tomcat的优化也变得非常重要了
对于tomcat的优化，主要是从2个方面入手，一是，tomcat自身的配置，另一个是 tomcat所运行的jvm虚拟机的调优。
1.tomcat与JVM调优
2.1 下载并安装tomcat
2.2 配置tomcat8
2.3 部署web项目
2.安装tomcat部署项目
3.1下载安装jmeter
3.2 使用步骤
3.使用Apache Jmeter进行测试
什么是AJP呢? AJP(Apache JServer Protocol)是定向包协议 。
WEB服务器和Servlet容器通过TCP连接来交互;
为 了节省SOCKET创建的昂贵代价，WEB服务器会尝试维护一个永久TCP连接到servlet容器，并且在多个请求和响应周 期过程会重用连接。
1. 第一个连接器监听8080端口，负责建立HTTP连接。在通过浏览器访问Tomcat服务器的Web应用时，使用的就 是这个连接器。
2. 第二个连接器监听8009端口，负责和其他的HTTP服务器建立连接。在把Tomcat与其他HTTP服务器集成时， 就需要用到这个连接器。AJP连接器可以通过AJP协议和一个web容器进行交互
Tomcat在 server.xml 中配置了两种连接器。
<Connector port=\"8009\" protocol=\"AJP/1.3\" redirectPort=\"8443\" />
Nginx+tomcat的架构，所以用不着AJP协议，所以把AJP连接器禁用。修改conf下的server.xml文件，将AJP服务禁用 掉即可。
禁用
重启tomcat，查看效果。 可以看到AJP服务以及不存在了。
4.1.1 禁用AJP服务
4.1.2 设置执行器(线程池)
4.1.3 设置最大等待队列
4.1.4 设置nio2的运行模式
4.1 优化吞吐量
4.调整tomcat参数进行优化
5.1 设置并行垃圾回收器
5.2 查看GC日志文件
5.3调整年轻代大小
5.4查看GC日志
5.5 设置G1垃圾收集器
5.调整JVM参数进行优化
7.JVM调优实战
职业：暂无
0 条评论
回复 删除
下一页
