JVM水挺深，我拿脚丫子划下水。

Java Virtual Machine（Java虚拟机）。

Windows 系统上的软件包装包是 exe 后缀的，而这个软件包在苹果的 Mac OSX 系统上是无法安装的。

MacOSX 系统上的软件安装包则是 dmg 后缀，同样无法在 Windows 系统上安装。

为什么不同系统上的软件无法安装，这是因为操作系统底层的实现是不一样的。

对于 Windows 系统来说，exe 后缀的软件代码最终编译成 Windows 系统能识别的机器码。

而对于Mac OSX 系统来说，dmg 后缀的软件代码最终编译成 Mac OSX 系统能识别的机器码。

上边这个图就可以说明java程序为什么可以<一次编译，到处运行>了，可以理解为真正让java到处跑的是jvm,

既然，JVM是操作.class文件的，那么给它制定一套规范是理所应当的咯，

《Java 虚拟机规范》规定了 Java 虚拟机结构、Class 类文件结构(百度一下)、字节码指令等内容。其中类文件结构是有必要了解的一个内容。

对应图里第4步，实际上是JVM将.class文件(必须符合JAVA虚拟机规范的Class类文件结构)，加载到内存。

而加载的工作，是由类加载器（ClassLoader）完成的。

聊类加载器的话，先聊JDK和JRE吧，

JDK（Java Development Kit）

　　JDK是Java开发工具包，是Sun Microsystems针对Java开发员的产品。

　　JDK中包含JRE，在JDK的安装目录下有一个名为jre的目录，里面有两个文件夹bin和lib，在这里可以认为bin里的就是jvm，lib中则是jvm工作所需要的类库，而jvm和 lib和起来就称为jre。

　　JDK是整个JAVA的核心，包括了Java运行环境JRE（Java Runtime Envirnment）、一堆Java工具（javac/java/jdb等）和Java基础的类库（即Java API 包括rt.jar）。

Java Runtime Environment（JRE）

　　是运行基于Java语言编写的程序所不可缺少的运行环境。也是通过它，Java的开发者才得以将自己开发的程序发布到用户手中，让用户使用。

　　RE中包含了Java virtual machine（JVM），runtime class libraries和Java application launcher，这些是运行Java程序的必要组件。

如果只是运行java程序，有JRE就够了。如果要开发java程序，则必须还有jdk。

JVM（java virtual machine）

　　只有JVM还不能成class的执行，因为在解释class的时候JVM需要调用解释所需要的类库lib，而jre包含lib类库。

PATH中的路径就是为了让上述javac和java可以找到对应的编译和执行工具。

当我们将工具路径注册到Path后，我们可以在任何盘符下，任何位置去使用javac和java命令，当执行这个命令行的时候，windows能够在path中找到对应的工具。

接下来主要解释CLASSPATH配置的路径是干嘛的？

.;%JDK_HOME%\lib\dt.jar;%JDK_HOME%\lib\tools.jar;

或许此时正是你的疑问，CLASSPATH可以不配置啊

CLASSPATH中为什么要添加".;",不添加可不可以？
配置的这两个JAR包路径是干什么的？
上述问题，最终解释为一句话：CLASSPATH中配置的路径是告诉AppClassLoader要去哪里加载.class文件"点分号"所代表的路径确实就是当前DOS(黑窗口)中所操作的盘符路径

当我们在DOS中进入到要执行的.class文件存放路径后执行对应的.class文件，AppClassLoader的类库加载路径会被默认添加上这个路径。
AppClassLoader在扫描用户类路径的时候，根据CLASSPATH中的配置信息，是存在相对的位置关系的严格顺序的，
他会沿着这个顺序去寻找，当在某一个路径下找到.class文件的时候，他就不会再继续往后找了。。即便后续的路径中仍旧存在着相同名字的.class文件。。

1. rt.jar
rt.jar 默认就在Root Classloader的加载路径里面的，而在Claspath配置该变量是不需要的；同时jre/lib目录下的

其他jar:jce.jar、jsse.jar、charsets.jar、resources.jar都在Root Classloader中

2. tools.jar

tools.jar 是系统用来编译一个类的时候用到的，即执行javac的时候用到

javac XXX.java

实际上就是运行

java -Calsspath=%JAVA_HOME%\lib\tools.jar xx.xxx.Main XXX.java

javac就是对上面命令的封装所以tools.jar 也不用加到classpath里面

3. dt.jar
dt.jar是关于运行环境的类库,主要是swing的包在用到swing时最好加上。

启动类加载器，那个类库搜索路径，主要是基础核心类库，就是java.开头的包内类

　　扩展类加载器，那个类库搜索路径，主要是拓展类库，就是javax.开头的包内类（这只是很粗的一种便于理解的叙述，我们已经知道dt.jar中有javax.swing,并且其被　　　　　　我们放在了CLASSPATH中）

AppClassLoader的路径是通过CLASSPATH来配置的，这很直观，但是我们没有配置启动类加载器和扩展类加载器的路径啊？他们的类库搜索路径是怎么配置的？是什么时候配置的？
我们来看JDK中的源码：
为了理解这个东西，我们先来看这样一个知识：

首先，JVM是”按需加载“的，这个之前已经介绍过了，JVM在启动的时候，不会傻傻的将所有的类和资源都加载进内存程序在启动的时候，或者说JVM在启动的时候，JVM是会负责先装载所有的ClassLoader的，这一部分，涉及到很底层的JVM指令问题，无需深入，我们只需要知道JVM实例化了sun.misc.Launcher这个类就行，如上图所示。
来看图示为sun.misc.Launcher的构造方法，他加载了扩展类加载器和AppClassLoader，并且注意看图中最后一个标注的地方，他把AppCLassLoader设置为了线程上下文的类加载器，哈哈，是不是长知识了。。。由于启动类加载器是有C++编写的，不是JAVA语言所写的，所以暂且是需要知道，JVM启动的时候，也会有JVM自己加载这个启动类加载器的。
然后我们回到上面的JDK源码，看图中标注的那几个获取系统变量的操作：

System.out.println(System.getProperty("sun.boot.class.path"));
 System.out.println(System.getProperty("java.ext.dirs"));
 System.out.println(System.getProperty("java.class.path"));

很直观的来看，这三个系统变量就对应了三个类加载器的类库加载路径。。

类加载器：
1.从Java虚拟机的角度来说，只存在两种不同的类加载器：

一种是启动类加载器，这个类加载器使用C++语言实现，是虚拟机自身的一部分；

另一部分就是所有的其他的类加载器，这些类加载器都是由java语言实现，独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader

2.从Java开发人员的角度，类加载器可以划分的更为细致，绝大部分java程序都是用到三种系统提供的类加载器

①启动类加载器：这个类加载器负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使存放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法直接被Java程序直接引用。

②扩展类加载器：这个加载器由sun.misc.Launcher$ExtClassLoader实现，他负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的所有类库，开发者可以直接使用扩展类加载器。

③应用程序类加载器：这个类加载器由sun.misc.Launcher$AppClassLoader实现。由于这个类加载时ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也被称为系统类加载器。他负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器。

双亲委派加载机制图示：

简单的例子去理解：

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着他的类加载器一起具备了一种带有优先级的层次关系。

例如：类java.lang.Object，它存放在rt.jar中，无论哪一个类加载器去加载这个类，最终都是委派给处于模型最顶端的启动类加载器中去加载，

因此Object在程序的各种类加载器环境中都是同一个类（最终真正加载的类加载器是同一个）。

相反，如果没有使用双亲委派模型，有各个类加载器自行去完成加载的话，如果用户自己编写了一个java。lang。Object类，并放在程序的Classpath中，

那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将变的混乱。

类加载过程：

加载

通过一个类的全限定名获取定义此类的二进制字节流
将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

验证

主要是为了保证加载进来的字节流符合虚拟机规范，不会造成安全错误。

包括对于文件格式的验证，比如常量中是否有不被支持的常量？文件中是否有不规范的或者附加的其他信息？

对于元数据的验证，比如该类是否继承了被final修饰的类？类中的字段，方法是否与父类冲突？是否出现了不合理的重载？

对于字节码的验证，保证程序语义的合理性，比如要保证类型转换的合理性。

对于符号引用的验证，比如校验符号引用中通过全限定名是否能够找到对应的类？校验符号引用中的访问性（private，public等）是否可被当前类访问？

准备

内存分配的对象。Java 中的变量有「类变量」和「类成员变量」两种类型，「类变量」指的是被 static 修饰的变量，而其他所有类型的变量都属于「类成员变量」。在准备阶段，JVM 只会为「类变量」分配内存，而不会为「类成员变量」分配内存。「类成员变量」的内存分配需要等到初始化阶段才开始。

例如下面的代码在准备阶段，只会为 factor 属性分配内存，而不会为 website 属性分配内存。

public static int factor = 3;
public String website = "www.cnblogs.com/chanshuyi";

初始化的类型。在准备阶段，JVM 会为类变量分配内存，并为其初始化。但是这里的初始化指的是为变量赋予 Java 语言中该数据类型的零值，而不是用户代码里初始化的值。

例如下面的代码在准备阶段之后，sector 的值将是 0，而不是 3。

public static int sector = 3;

但如果一个变量是常量（被 static final 修饰）的话，那么在准备阶段，属性便会被赋予用户希望的值。例如下面的代码在准备阶段之后，number 的值将是 3，而不是 0。

public static final int number = 3;

之所以 static final 会直接被赋值，而 static 变量会被赋予零值。其实我们稍微思考一下就能想明白了。

两个语句的区别是一个有 final 关键字修饰，另外一个没有。而 final 关键字在 Java 中代表不可改变的意思，意思就是说 number 的值一旦赋值就不会在改变了。既然一旦赋值就不会再改变，那么就必须一开始就给其赋予用户想要的值，因此被 final 修饰的类变量在准备阶段就会被赋予想要的值。而没有被 final 修饰的类变量，其可能在初始化阶段或者运行阶段发生变化，所以就没有必要在准备阶段对它赋予用户想要的值。

解析

将常量池内的符号引用替换为直接引用的过程。

两个重点：

符号引用。即一个字符串，但是这个字符串给出了一些能够唯一性识别一个方法，一个变量，一个类的相关信息。
直接引用。可以理解为一个内存地址，或者一个偏移量。比如类方法，类变量的直接引用是指向方法区的指针；而实例方法，实例变量的直接引用则是从实例的头指针开始算起到这个实例变量位置的偏移量

举个例子来说，现在调用方法hello()，这个方法的地址是1234567，那么hello就是符号引用，1234567就是直接引用。

在解析阶段，虚拟机会把所有的类名，方法名，字段名这些符号引用替换为具体的内存地址或偏移量，也就是直接引用。

初始化（重点）

JVM规范枚举了下述几种情况：

当虚拟机启动时，初始化用户指定的主类
当遇到调用 静态方法 的指令时，初始化该静态方法所在的类
当遇到访问 静态字段 的指令时，初始化该静态字段所在的类
当遇到用以新建目标类实例的 new 指令时，初始化 new 指令的目标类
子类的初始化会触发父类的初始化
如果一个接口定义了 default 方法，那么直接或者间接实现该接口的类的初始化，会触发该接口的初识化
使用反射 API 对某个类进行反射调用时，初始化这个类
当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类

看到上面几个条件你可能会晕，但是不要紧，不需要背，知道一下就好，后面用到的时候回到找一下就可以了。

1：类初始化方法。编译器会按照其出现顺序，收集类变量(静态变量)的赋值语句、静态代码块，最终组成类初始化方法（main方法执行时，先初始化main方法所在类）

2：对象初始化方法。编译器会按照其出现顺序，收集成员变量的赋值语句、普通代码块，最后收集构造函数的代码，最终组成对象初始化方法。对象初始化方法一般在实例化类对象的时候执行。

JVM1.8内存区域划分：

线程共享（公共）部分：Java堆、方法区、常量池

Java堆：指的是从 JVM 划分出来的一块区域，这块区域专门用于 Java 实例对象的内存分配，几乎所有实例对象都在会这里进行内存的分配。之所以说几乎是因为有特殊情况，有些时候小对象会直接在栈上进行分配，这种现象我们称之为「栈上分配」。

Java 堆根据对象存活时间的不同，Java 堆还被分为年轻代、老年代两个区域，年轻代还被进一步划分为 Eden 区、From Survivor 0、To Survivor 1

为什么默认的虚拟机配置，Eden：from ：to = 8:1:1 呢？

其实这是 IBM 公司根据大量统计得出的结果。根据 IBM 公司对对象存活时间的统计，他们发现 80% 的对象存活时间都很短。于是他们将 Eden 区设置为年轻代的 80%，这样可以减少内存空间的浪费，提高内存空间利用率。

方法区：指的是存储 Java 类字节码数据的一块区域，它存储了每一个类的结构信息，例如运行时常量池、字段和方法数据、构造方法等。可以看到常量池其实是存放在方法区中的，但《Java 虚拟机规范》将常量池和方法区放在同一个等级上，这点我们知晓即可。

方法区在不同版本的虚拟机有不同的表现形式，在 1.7 版本的 HotSpot 虚拟机中，方法区被称为永久代（Permanent Space），而在 JDK 1.8 中则被称之MetaSpace。

线程私有部分：PC寄存器、Java 虚拟机栈、本地方法栈

PC寄存器：（程序计数器），指的是保存线程当前正在执行的方法。如果这个方法不是 native 方法，那么 PC 寄存器就保存 Java 虚拟机正在执行的字节码指令地址。如果是 native 方法，那么 PC 寄存器保存的值是 undefined。任意时刻，一条 Java 虚拟机线程只会执行一个方法的代码，而这个被线程执行的方法称为该线程的当前方法，其地址被存在 PC 寄存器中。

Java 虚拟机栈：这个栈与线程同时创建，用来存储栈帧，即存储局部变量与一些过程结果的地方。栈帧存储的数据包括：局部变量表、操作数栈。

当 Java 虚拟机使用其他语言（例如 C 语言）来实现指令集解释器时，也会使用到本地方法栈。如果 Java 虚拟机不支持 natvie 方法，并且自己也不依赖传统栈的话，可以无需支持本地方法栈。

Java 虚拟机的内存结构是学习虚拟机所必须掌握的地方，其中以 Java 堆的内存模型最为重要，因为线上问题很多时候都是 Java 堆出现问题。因此掌握 Java 堆的划分以及常用参数的调整最为关键。

JVM垃圾回收：GC

到底谁是垃圾？

联想其日常生活中，如果一个东西经常没被使用，那么这个对象可以说就是垃圾。

在 Java 中也是如此，如果一个对象不可能再被引用，那么这个对象就是垃圾，应该被回收。

1：「引用计数法」在一个对象被引用时加一，被去除引用时减一，这样我们就可以通过判断引用计数是否为零来判断一个对象是否为垃圾。

这种方法虽然简单，但是其存在一个致命的问题，那就是循环引用。A 引用了 B，B 引用了 C，C 引用了 A，它们各自的引用计数都为 1。永远无法回收。

2：现今的Java虚拟机判断垃圾对象使用的是：GC Root Tracing 算法。大概过程是：从 GC Root 出发，所有可达的对象都是存活的对象，不可达的对象都是垃圾。

如何进行垃圾回收？

垃圾回收算法简单地说有三种算法：标记清除算法、复制算法、标记压缩算法。

标记清除算法。从名字可以看到其分为两个阶段：标记阶段和清除阶段。一种可行的实现方式，在标记阶段，标记所有由 GC Root 触发的可达对象。此时，所有未被标记的对象就是垃圾对象。之后在清除阶段，清除所有未被标记的对象。标记清除算法最大的问题就是空间碎片问题。如果空间碎片过多，则会导致内存空间的不连续。虽说大对象也可以分配在不连续的空间中，但是效率要低于连续的内存空间。

复制算法。复制算法的核心思想是将原有的内存空间分为两块，每次只使用一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中。之后清除正在使用的内存块中的所有对象，之后交换两个内存块的角色，完成垃圾回收。该算法的缺点是要将内存空间折半，极大地浪费了内存空间。

标记压缩算法。标记压缩算法可以说是标记清除算法的优化版，其同样需要经历两个阶段，分别是：标记结算、压缩阶段。在标记阶段，从 GC Root 引用集合触发去标记所有对象。在压缩阶段，其则是将所有存活的对象压缩在内存的一边，之后清理边界外的所有空间。

这三种算法都有各自的优点和缺点。

标记清除算法虽然会产生内存碎片，但是不需要移动太多对象，比较适合在存活对象比较多的情况。

复制算法虽然需要将内存空间折半，并且需要移动存活对象，但是其清理后不会有空间碎片，比较适合存活对象比较少的情况。

而标记压缩算法，则是标记清除算法的优化版，减少了空间碎片。

分代思想

如果我们单独采用任何一种算法，那么最终的垃圾回收效率都不会很好。其实 JVM 虚拟机的建造者们也是这么想的，因此在实际的垃圾回收算法中采用了分代算法。

所谓分代算法，就是根据 JVM 内存的不同内存区域，采用不同的垃圾回收算法。例如对于存活对象少的新生代区域，比较适合采用复制算法。这样只需要复制少量对象，便可完成垃圾回收，并且还不会有内存碎片。而对于老年代这种存活对象多的区域，比较适合采用标记压缩算法或标记清除算法，这样不需要移动太多的内存对象。

试想一下，如果没有采用分代算法，而在老年代中使用复制算法。在极端情况下，老年代对象的存活率可以达到100%，那么我们就需要复制这么多个对象到另外一个内存区域，这个工作量是非常庞大的。

在这里我们再深入地聊一聊新生代里采取的垃圾回收算法。如我们上面所说，新生代的特点是存活对象少，适合采用复制算法。而复制算法的一种最简单实现便是折半内存使用，另一半备用。但实际上我们知道，在实际的 JVM 新生代划分中，却不是采用等分为两块内存的形式。而是分为：Eden 区域、from 区域、to 区域这三个区域。那么为什么 JVM 最终要采用这种形式，而不用 50% 等分为两个内存块的方式？

要解答这个问题，我们就需要先深入了解新生代对象的特点。根据IBM公司的研究表明，在新生代中的对象 98% 是朝生夕死的，所以并不需要按照1:1的比例来划分内存空间。所以在HotSpot虚拟机中，JVM 将内存划分为一块较大的Eden空间和两块较小的Survivor空间，其大小占比是8:1:1。当回收时，将Eden和Survivor中还存活的对象一次性复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Eden空间。

通过这种方式，内存的空间利用率达到了90%，只有10%的空间是浪费掉了。而如果通过均分为两块内存，则其内存利用率只有 50%，两者利用率相差了将近一倍。

分区思想

分代思想按照对象的生命周期长短将其分为了两个部分（新生代、老年代），

但 JVM 中其实还有一个分区思想，即将整个堆空间划分成连续的不同小区间。

每一个小区间都独立使用，独立回收，这种算法的好处是可以控制一次回收多少个区间，可以较好地控制 GC 时间。

到这里我们基本上把 JVM 的垃圾回收都将清除了，从一开始什么是垃圾，到之后如何判断垃圾，到如何回收垃圾，到垃圾回收的两个重要思想：分代思想、分区思想。通过这么一个脉络，我们了解了垃圾回收的整体概括。在下面的章节中，我们将深入介绍这其中的细节。

深入学习的话，自行搜索：垃圾回收器和垃圾回收的几种类型

JVM基于1.8参数之堆栈空间配置

堆配置

我们使用 -Xms 设置堆的初始空间大小，使用 -Xmx 设置堆的最大空间大小。

java -Xms20m -Xmx30m GCDemo

在上面的命令中，我们设置 JVM 的初始堆大小为 20M，最大堆空间为 30M。

年轻代

在 JDK1.8 中，堆分为年轻代和老年代。JVM 提供了参数 -Xmn 来设置年轻代内存的大小，但没有提供参数设置老年代的大小。但其实老年代的大小就等于堆大小减去年轻代大小。

java -Xms20m -Xmn10M GCDemo

上面的命令中，我们设置 JVM 堆初始大小为20M。其中年轻代的大小为 10M，那么剩下的就是老年代的大小，有 10M了。我们可以给上述命令加上-XX:+PrintGCDetails 参数来查看内存区域的分配信息。

如上图所示，我们可以看到老年代的大小为 10M。

Eden区

在年轻代中，分为三个区域，分别是：eden 空间、from 空间、to 空间。如果要设置这部分的大小，那么就使用 -XX:SurvivorRatio 这个参数，该参数设置 eden / from 空间的比例关系，该参数的公式如下：

-XX:SurvivorRatio = eden/from = eden/to

例如我们的年轻代有 10 M，而我们设置 -XX:SurvivorRatio 参数为 2。也就是说 eden / from = eden / to = 2。这里教一个快速计算的方法，我们假设 eden = 2，那么 from = 1，to = 1，那么 eden + from + to = 10M。这样就可以算出每一份大小是 10/4 = 2.5M。所以 Eden 区 = 2.5 * 2 = 5M，from 区是 2.5 M，to 区是 2.5 M。

下面我们运行下命令来验证一下。

java -Xms20m -Xmn10M -XX:SurvivorRatio=2 -XX:+PrintGCDetails GCDemo

在上面的启动参数中，我们设置堆初始大小为 20M，年轻代大小为 10M，年轻代的 SurvivorRatio 比例为 2。那么最终分配的结果将会是：年轻代 10M，其中 Eden 区 5M、From 区 2.5M、To 区 2.5 M，老年代 10M。

从上图可以看到：eden 空间是 5120 K，from 和 to 空间是 2560 K。

上图还有一个细节，即 PSYoungGen 这里的 total 只有 7680K，难道年轻代只有 7.5M 的内存吗？为什么不是 10M 呢？其实是因为这里的 total 指的是可用内存，from space 和 to space 两个区域，同一时间只有一个区域是可以用的。所以可用内存是 5120 + 2560 = 7680。

永久代（JDK1.7）

在 JDK 1.8 之前，所加载的类信息都放在永久代中。我们用 -XX:PermSize 设置永久代初始大小，用 -XX:MaxPermSize 设置永久代最大大小。

java -XX:PermSize10m -XX:MaxPermSize50m -XX:+PrintGCDetails GCDemo

在上面的启动参数中，我们设置永久代初始大小为 10M，最大大小为 50M。我们在 JDK1.7 的环境下运行上面的命令，会看到如下的 GC 日志。

在上图中，我们可以看到永久代的大小为我们设置的 10M。

元空间（JDK1.8）

在 JDK 1.8 之前，所有加载的类信息都放在永久代中。但在 JDK1.8 之时，永久代被移除，取而代之的是元空间（Metaspace）。在元空间这块内存中，有两个参数很相似，它们是： -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize。

java -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=50m -XX:+PrintGCDetails GCDemo

上面的命令中，我们设置 MetaspaceSize 为 10M，MaxMetaspaceSize 为 50M。但其实它们并不是设置初始大小和最大大小的。

从上面的执行结果可以看到，Metaspace 空间的大小为 2.6M 左右，并不是我们设置的 10M。那是因为 MetaspaceSize 设置的是元空间发生 GC 的初始阈值。当达到这个值时，元空间发生 GC 操作，这个值默认是 20.8M。而 MaxMetaspaceSize 则是设置元空间的最大大小，默认基本是机器的物理内存大小。虽然可以不设置，但还是建议设置一下，因为如果一直不断膨胀，那么 JVM 进程可能会被 OS kill 掉。

栈空间

栈空间是每个线程各自有的一块区域，如果栈空间太小，也会导致 StackOverFlow 异常。而要设置栈空间大小，只需要使用 -Xss 参数就可以。

java -Xss2m GCDemo

上面的启动命令设置最大栈空间为 2M。

直接内存

在 JVM 中还有一块内存，它独立于 JVM 的堆内存，它就是：直接内存。我们可以使用 -XX:MaxDirectMemorySize 设置最大直接内存。如果不设置，默认为最大堆空间，即 -Xmx。

java -XX:MaxDirectMemorySize=50m GCDemo

上面的启动命令设置直接内存最大值为 50M。

当直接内存使用达到设置值时，就会触发垃圾回收。如果不能有效释放足够空间，就会引发直接内存溢出导致系统的 OOM。

总结

参数	含义
-Xms	初始堆大小
-Xmx	最大堆空间
-Xmn	设置新生代大小
-XX:SurvivorRatio	设置新生代eden空间和from/to空间的比例关系
-XX:PermSize	方法区初始大小
-XX:MaxPermSize	方法区最大大小
-XX:MetaspaceSize	元空间GC阈值（JDK1.8）
-XX:MaxMetaspaceSize	最大元空间大小（JDK1.8）
-Xss	栈大小
-XX:MaxDirectMemorySize	直接内存大小，默认为最大堆空间

JVM之参数查看：

打印显式参数 -XX:+PrintVMOptions

该参数表示程序运行时，打印虚拟机接受到的命令行显式参数。我们用下面的命令运行程序：

java  -XX:+UseSerialGC -XX:+PrintVMOptions com.chenshuyi.ClassLoadDemo

输出结果：

VM option '+UseSerialGC'
VM option '+PrintVMOptions'
Hello, I'm chenshuyi

可以看到我们设置了+UseSerialGC和+PrintVMOptions两个参数，最后运行时也将这两个参数打印出来了。

打印显式隐式参数 -XX:+PrintCommandLineFlags

该参数打印传递给虚拟机的显式和隐式参数。我们用下面的命令运行程序：

java  -XX:+UseSerialGC -XX:+PrintCommandLineFlags com.chenshuyi.ClassLoadDemo

输出结果：

-XX:InitialHeapSize=134217728 -XX:MaxHeapSize=2147483648 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC
Hello, I'm chenshuyi

可以看到程序不仅输出了我们显式设置的参数，还将虚拟机默认的参数打印了出来，包括初始堆大小（134217728），最大堆大小（2147483648）等。

打印所有系统参数 -XX:+PrintFlagsFinal

该参数会打印所有的系统参数的值。我们用下面的命令运行程序：

java  -XX:+UseSerialGC -XX:+PrintFlagsFinal com.chenshuyi.ClassLoadDemo  > jvm_flag_final.txt

之后打开 jvm_flag_final.txt 文件，可以看到有 800 多行，这是因为程序将虚拟机的所有参数都打印了出来。下面列几个我们常用的参数看看就可以：

...
uintx InitialHeapSize := 134217728 {product}
...
uintx MaxMetaspaceSize = 18446744073709547520 {product}
...
uintx MetaspaceSize = 21807104 {pd product}

从上面我们列出的部分参数可以看到，上面三个参数分别是设置初始堆大小、元空间最大大小、初始元空间大小。

最后，让我们来总结一下，加强记忆。

-XX:+PrintVMOptions 程序运行时，打印虚拟机接受到的命令行显式参数。
-XX:+PrintCommandLineFlags 打印传递给虚拟机的显式和隐式参数。
-XX:+PrintFlagsFinal 打印所有的系统参数的值

JVM之参数追踪类信息

我们都知道 JVM 在启动的时候会去加载类信息，那么我们怎么得知他加载了哪些类，又卸载了哪些类呢？我们这一节就来介绍四个 JVM 参数，使用它们我们就可以清晰地知道 JVM 的类加载信息。

为了方便演示，我们使用下面的程序作为本次的演示程序。

/**
 * @author chenshuyi
 * @date 2018.09.30
 */
public class ClassLoadDemo {
    public static void main(String[] args) {
        String name = "chenshuyi";
        System.out.println("Hello, I'm " + name);
    }
}

跟踪类的加载和卸载 -verbose:class

我们使用下面的参数运行程序：

java -verbose:class com.zk.service.ClassLoadDemo > class_load_info.txt

之后我们打开 class_load_info.txt 文件。因为该文件太大，所以我们节选一部分：

...省略...
[Loaded java.util.ArrayList from /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/rt.jar]
...省略...
[Loaded java.util.HashMap from /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/rt.jar]
...省略...	
[Loaded com.chenshuyi.ClassLoadDemo from file:/Users/yurongchan/Yosemite/Code/practice/target/classes/]
...省略...

从上面可以看到 JVM 分别加载了 ArrayList、HashMap 类，以及我们自己定义的 ClassLoadDemo 类。

跟踪类的加载 -XX:+TraceClassLoading

该参数与可以显示类的加载信息，输出的结果和 -verbose:class 一样，但比起它少了类的卸载信息。

跟踪类的卸载 -XX:+TraceClassUnloading

该参数与可以显示类的加载信息，输出的结果和 -verbose:class 一样，但比起它少了类的加载信息。

但实际上我们通过上面这个简单的例子，没有发现类的卸载信息，或许是例子太简单了，所以没有这个。

-XX:+PrintClassHistogram

该参数表示遇到 Ctrl-Break 后打印类实例的柱状信息，与 jmap -histo 功能相同。

了解了这些参数，能够让我们更好地了解哪些类已经被加载到 JVM 中，从而更好地排查问题。最后来个总结，加强记忆：

参数	含义
-verbose:class	跟踪类的加载和卸载
-XX:+TraceClassLoading	跟踪类的加载
-XX:+TraceClassUnloading	跟踪类的卸载
-XX:+PrintClassHistogram	显示类信息柱状图

JVM参数之GC日志配置:

说到 Java 虚拟机，不得不提的就是 Java 虚拟机的 GC（Garbage Collection）日志。而对于 GC 日志，我们不仅要学会看懂，而且要学会如何设置对应的 GC 日志参数。今天就让我们来学习一下 Java 虚拟机中所有与 GC 日志有关的参数。相信掌握了这些参数之后，对于大家线上打印 GC 日志是有不少帮助的。

为了能够更直观地显示出每个参数的作用，我们将以下面的 Demo 为例子去设置 GC 日志参数。

/**
 * @author 陈树义
 * @date 2018.09.29
 */
public class GCDemo {
    public static void main(String[] args) {
        // allocate 4M space
        byte[] b = new byte[4 * 1024 * 1024];
        System.out.println("first allocate");
        // allocate 4M space
        b = new byte[4 * 1024 * 1024];
        System.out.println("second allocate");
    }
}

在上面的程序中，我们两次分配了 4M 的内存空间。为了认为制造 GC，我们启动时的 JVM 参数固定加上下面几个参数：

-XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8

-XX:+UseSerialGC 表示强制使用Serial+SerialOld收集器组合
-Xms20m 表示堆空间初始大小为 20 M。
-Xmx20m 表示堆空间最大大小为 20 M。
-Xmn10m 表示新生代大小为 10M。
-XX:SurvivorRatio=8 表示Eden:Survivor=8:1

经过上面这个设置，此时我们的堆空间的内存比例情况如下：Eden区 8M，FromSurvivor 1M，ToSurvivor 1M，老年代 10M。

下面就让我们来看看油管 GC 的参数有哪些吧。

打印GC日志

在 GC 日志参数中，最简单的一个参数就是打印 GC 日志：-XX:PrintGC。我们用下面的命令运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGC com.chenshuyi.GCDemo

输出结果：

first allocate
second allocate
[GC (Allocation Failure)  4767K->4374K(19456K), 0.0045179 secs]

可以看到程序在第一次分配数组空间的时候发生了 GC，并且把 GC 前后以及堆空间大小都打印了出来。该日志显示 GC 前堆空间使用量为 4767K（4M左右）。GC 后堆空间为 4374K，当前可用堆大小为 19456K。

但你会发现使用 PrintGC 参数打印出来的日志比较简单，无法查看更详细的信息。如果你要查看更详细的信息，那么就需要下面这个参数。

打印详细GC日志

如果要查看更加详细的 GC 日志，那么就要使用 -XX:+PrintGCDetails 参数。下面我们使用该参数运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGC com.chenshuyi.GCDemo

程序输出：

first allocate
second allocate
[GC (Allocation Failure) [DefNew: 4603K->278K(9216K), 0.0036744 secs] 4603K->4374K(19456K), 0.0037100 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
 def new generation   total 9216K, used 4538K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  52% used [0x00000007bec00000, 0x00000007bf0290e0, 0x00000007bf400000)
  from space 1024K,  27% used [0x00000007bf500000, 0x00000007bf545920, 0x00000007bf600000)
  to   space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
 tenured generation   total 10240K, used 4096K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
   the space 10240K,  40% used [0x00000007bf600000, 0x00000007bfa00010, 0x00000007bfa00200, 0x00000007c0000000)
 Metaspace       used 2649K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 286K, capacity 386K, committed 512K, reserved 1048576K

从上面的日志可以看出，该参数能打印出更加详细的 GC 信息，包括：年轻代的信息、永久代的信息。

[GC (Allocation Failure) [DefNew: 4603K->278K(9216K), 0.0036744 secs] 4603K->4374K(19456K), 0.0037100 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

该参数还会在退出之前打印出整个堆的详细信息：

Heap
 def new generation   total 9216K, used 4538K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  52% used [0x00000007bec00000, 0x00000007bf0290e0, 0x00000007bf400000)
  from space 1024K,  27% used [0x00000007bf500000, 0x00000007bf545920, 0x00000007bf600000)
  to   space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
 tenured generation   total 10240K, used 4096K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
   the space 10240K,  40% used [0x00000007bf600000, 0x00000007bfa00010, 0x00000007bfa00200, 0x00000007c0000000)
 Metaspace       used 2649K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 286K, capacity 386K, committed 512K, reserved 1048576K

GC前后打印堆信息

上面两个命令基本上可以应付 90% 的使用场景了，但有时候我们在 GC 前后还想获取更加详细的信息。那么我们可以使用 PrintHeapAtGC 参数，该参数会在 GC 前后打印堆信息。

使用下面的命令运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintHeapAtGC com.chenshuyi.GCDemo

输出结果：

first allocate
second allocate
{Heap before GC invocations=0 (full 0):
 def new generation   total 9216K, used 4767K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  58% used [0x00000007bec00000, 0x00000007bf0a7e98, 0x00000007bf400000)
  from space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
  to   space 1024K,   0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
 tenured generation   total 10240K, used 0K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
   the space 10240K,   0% used [0x00000007bf600000, 0x00000007bf600000, 0x00000007bf600200, 0x00000007c0000000)
 Metaspace       used 2646K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 286K, capacity 386K, committed 512K, reserved 1048576K
Heap after GC invocations=1 (full 0):
 def new generation   total 9216K, used 278K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,   0% used [0x00000007bec00000, 0x00000007bec00000, 0x00000007bf400000)
  from space 1024K,  27% used [0x00000007bf500000, 0x00000007bf545950, 0x00000007bf600000)
  to   space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
 tenured generation   total 10240K, used 4096K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
   the space 10240K,  40% used [0x00000007bf600000, 0x00000007bfa00010, 0x00000007bfa00200, 0x00000007c0000000)
 Metaspace       used 2646K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 286K, capacity 386K, committed 512K, reserved 1048576K
}

仔细看一下，会发现在 GC 发生前后都打印了一次堆空间信息。

通过这个参数，我们可以详细了解每次 GC 时堆空间的详细信息。

打印GC发生的时间 -XX:+PrintGCTimeStamps

这个参数非常简单，就是在每次 GC 日志的前面加上一个时间戳。这个时间戳表示 JVM 启动后到现在所逝去的时间。

使用下面的参数运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGC -XX:+PrintGCTimeStamps com.chenshuyi.GCDemo

输出结果：

first allocate
second allocate
0.130: [GC (Allocation Failure)  4767K->4374K(19456K), 0.0051351 secs]

上面日志第 3 行中的「0.130」就是该 GC 发生的时间。

-XX:+PrintGCApplicationConcurrentTime 打印应用程序的执行时间

使用下面的命令运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGC -XX:+PrintGCApplicationConcurrentTime com.chenshuyi.GCDemo

运行结果：

first allocate
second allocate
Application time: 0.0371892 seconds
[GC (Allocation Failure)  4767K->4374K(19456K), 0.0040074 secs]
Application time: 0.0010712 seconds

-XX:+PrintGCApplicationStoppedTime 打印应用由于GC而产生的停顿时间

使用下面的命令运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime com.chenshuyi.GCDemo

运行结果：

first allocate
second allocate
[GC (Allocation Failure)  4767K->4374K(19456K), 0.0045644 secs]
Total time for which application threads were stopped: 0.0047873 seconds, Stopping threads took: 0.0000329 seconds

可以看到最后一行打印出了因为 GC 而暂停的时间。

保存GC日志 -Xloggc

这个参数可以将 GC 日志输出到文件中保存起来。

使用下面的参数运行程序：

java -XX:+UseSerialGC -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGC -XX:+PrintReferenceGC -Xloggc:gc.log com.chenshuyi.GCDemo

运行之后在本目录会生成一个 gc.log 文件，打开该文件：

Java HotSpot(TM) 64-Bit Server VM (25.181-b13) for bsd-amd64 JRE (1.8.0_181-b13), built on Jul  7 2018 01:02:31 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Memory: 4k page, physical 8388608k(45132k free)

/proc/meminfo:

CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:NewSize=10485760 -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintReferenceGC -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC 
0.124: [GC (Allocation Failure)  4767K->4374K(19456K), 0.0047748 secs]

可以看到堆的相关信息，以及 GC 的信息。

总结

除了上面这些参数，还有可以查看弱引用的参数：-XX:+PrintReferenceGC。它跟踪软引用、弱引用、虚引用和Finallize队列的信息，但是使用场景较为狭窄。基本上掌握上面的几个常用的 GC 日志参数就足够排查使用，最重要的是弄清楚每个参数的作用和用法。

最后用列表的形式总结一下，加深一下印象。

参数	含义
-XX:PrintGC	打印GC日志
-XX:+PrintGCDetails	打印详细的GC日志。还会在退出前打印堆的详细信息。
-XX:+PrintHeapAtGC	每次GC前后打印堆信息。
-XX:+PrintGCTimeStamps	打印GC发生的时间。
-XX:+PrintGCApplicationConcurrentTime	打印应用程序的执行时间
-XX:+PrintGCApplicationStoppedTime	打印应用由于GC而产生的停顿时间
-XX:+PrintReferenceGC	跟踪软引用、弱引用、虚引用和Finallize队列。
-XLoggc	将GC日志以文件形式输出。

JVM基础系列第15讲：JDK性能监控命令

查看虚拟机进程：jps 命令

jps 命令可以列出所有的 Java 进程。如果 jps 不加任何参数，可以列出 Java 程序的进程 ID 以及 Main 函数短名称，如下所示。

$ jps
6540 Jps
64447 Main

除此之外，还可以指定下面的参数自定义输出信息：

参数	含义
-q	指定jps只输出进程ID
-m	输出传递给Java进程的参数
-l	输出主函数的完整路径
-v	显示传递给Java虚拟机的参数

虚拟机统计信息：jstat 命令

jstat 用于观察 Java 堆信息的详细情况，其基本使用语法位：

jstat -<option> [-t] [-h<lines>] <vmid> [<interval>] [<count>]]

其中 option 可以由以下值构成。

参数	含义
-class	监视类装载、卸载数量、总空间以及类装载所耗费的时间
-gc	监视Java堆状况，包括Eden区、两个Survivor区、老年代、永久代等的容量、已用空间、GC时间合计等信息
-gccapacity	监视内容与-gc基本相同，但输出主要关注Java堆各个区域使用到的最大、最小空间
-gcutil	监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比
-gccause	与-gcutil功能一样，但是会额外输出导致上一次GC产生的原因
-gcnew	监视新生代GC状况
-gcnewcapacity	监视内容与-gcnew基本相同，输出主要关注使用到的最大、最小空间
-gcold	监视老年代GC状况
-gcoldcapacity	监视内容与-gcold基本相同，输出主要关注使用到的最大、最小空间
-gcpermcapacity	输出永久代使用到的最大、最小空间
-compiler	输出JIT编译器编译过的方法、耗时信息
-printcompilation	输出已经被JIT编译的方法

-t 参数表示输出时间戳、-h 参数表示在多少行后输出一个表头、vmid 则是虚拟机的进程ID、interval 和 count 表示输出间隔以及输出次数。

例如：我们用jstat命令来监视一个LVMID为2365的JVM进程。

$ jstat -gcutil 2365 
  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00  12.05   0.00  14.17      0    0.000     0    0.000    0.000

其中每个选项的意义如下：

参数	含义
S0、S1	表示Survivor0、Survivor1，还未使用。
E	表示Eden区使用了12.05%的空间。
O	表示老年代还未使用。
P	表示永久代使用了14.17%的空间
YUC、YGCT	表示从程序运行以来一共发生了0次Minor GC（YGC，Young GC），总共耗时0秒。
FGC、FGCT	表示从程序运行以来一共发生了0次Full GC（FGC，Full GC），总共耗时0秒。

查看虚拟机参数：jinfo 命令

jinfo 可以用来查看正在运行的 Java 应用程序的扩展参数，甚至支持在运行时，修改部分参数。它的基本语法是：

jinfo <option> <pid>

执行例子，查询 CMSInitiatingOccupancyFraction 参数值

$ jinfo -flag CMSInitiatingOccupancyFraction 2618
-XX:CMSInitiatingOccupancyFraction=-1

导出堆到文件：jmap 命令

jmap 是一个多功能命令，可以生成 Java 程序的 Dump 文件，也可以查看堆内对象实例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。

jmap [option] vmid

执行样例，使用 jmap 生成一个正在运行的 Eclipse 的 dump 快照文件的例子。例子中的2618是通过jps名称查询到的LVMID。

$ jmap -dump:format=b,file=Desktop/dump.bin 2618
Dumping heap to /Users/yurongchan/Desktop/dump.bin ...
Heap dump file created

堆分析工具：jhat 命令

jhat 命令用于分析 Java 应用的对快照内存。Sun JDK 提供了 jhat 命令与 jmap 搭配使用，来分析 jmap 生成的堆转储快照。jhat 内置了一个微型的 HTTP/HTML 服务器，生成 dump 文件的分析结果后，可以在浏览器中查看。下面我们用 jhat 来分析上面生成的 dump.bin 文件：

$ jhat dump.bin 
Reading from dump.bin...
Dump file created Sun May 15 23:04:19 CST 2016
Snapshot read, resolving...
Resolving 13822 objects...
Chasing references, expect 2 dots..
Eliminating duplicate references..
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

之后在浏览器输入 http://localhost:7000 就可以看到分析结果，如下图所示：

不过一般情况下不用 jhat 命令来分析 dump 文件，主要有以下两个原因：一是一般不会再部署应用的服务器上分析 dump 文件，因为分析工作是一个耗时而且消耗硬件资源的过程。另一个原因是 jhat 的分析功能还比较简陋，比起后面介绍的 VisualVM 等工具还差得很多。

查看线程堆栈：jstack 命令

jstack 命令用于导出 Java 应用程序的线程堆栈。jstack命令格式：

jstack [option] vmid

下面使用jstack查看一个线程对战的例子：

nobody $ jstack -l 2618
2016-05-15 23:39:04
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode):
"Attach Listener" daemon prio=5 tid=0x00007f83228e6000 nid=0x280b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   Locked ownable synchronizers:
    - None
"DestroyJavaVM" prio=5 tid=0x00007f832387e800 nid=0x1303 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   Locked ownable synchronizers:
    - None

posted @ 2021-07-29 13:49 冰糖ღ 阅读(62) 评论(0) 收藏举报

刷新页面返回顶部

冰糖ღ

JVM水挺深，我拿脚丫子划下水。

接下来主要解释CLASSPATH配置的路径是干嘛的？

加载

验证

准备

解析

初始化（重点）

线程共享（公共）部分：Java堆、方法区、常量池

线程私有部分：PC寄存器、Java 虚拟机栈、本地方法栈

到底谁是垃圾？

如何进行垃圾回收？

分代思想

如果我们单独采用任何一种算法，那么最终的垃圾回收效率都不会很好。其实 JVM 虚拟机的建造者们也是这么想的，因此在实际的垃圾回收算法中采用了分代算法。

分区思想

JVM基于1.8参数之堆栈空间配置

堆配置

年轻代

Eden区

永久代（JDK1.7）

元空间（JDK1.8）

栈空间

直接内存

总结

JVM之参数查看：

打印显式参数 -XX:+PrintVMOptions

打印显式隐式参数 -XX:+PrintCommandLineFlags

打印所有系统参数 -XX:+PrintFlagsFinal

JVM之参数追踪类信息

跟踪类的加载和卸载 -verbose:class

跟踪类的加载 -XX:+TraceClassLoading

跟踪类的卸载 -XX:+TraceClassUnloading

-XX:+PrintClassHistogram

JVM参数之GC日志配置:

打印GC日志

打印详细GC日志

GC前后打印堆信息

打印GC发生的时间 -XX:+PrintGCTimeStamps

-XX:+PrintGCApplicationConcurrentTime 打印应用程序的执行时间

-XX:+PrintGCApplicationStoppedTime 打印应用由于GC而产生的停顿时间

保存GC日志 -Xloggc

总结

JVM基础系列第15讲：JDK性能监控命令

查看虚拟机进程：jps 命令

虚拟机统计信息：jstat 命令

查看虚拟机参数：jinfo 命令

导出堆到文件：jmap 命令

堆分析工具：jhat 命令

查看线程堆栈：jstack 命令

公告