深入理解java虚拟机读书笔记

深入理解java虚拟机（jvm高级特性与最佳实践）

一、前沿

二、第一部分-走进java

三、第二部分-走进内存管理机制

四、第三部分-虚拟机执行子系统

五、程序编译与代码优化

六、高效并发

                                                                  一、前沿

   Java的技术体系主要由支撑：Java程序运行的虚拟机、 提供各开发领域接口支持的Java API、Java编程语言及许多第三方Java框架（如Spring、Struts等）构成。Java开发技术本身的一个重要优点：在虚拟机层面隐藏了底层技术的复杂性以及机器与操作系统的差异性。运行程序的物理机器的情况千差万别，而Java虚拟机则在千差万别的物理机上建立了统一的运行平台，实现了在任意一台虚拟机上编译的程序都能在任何一台虚拟机上正常运行。程序员可以把主要精力集中在具体业务逻辑上，而不是物理硬件的兼容性上。在一般情况下，一个程序员只要了解了必要的Java API、 Java语法，以及学习适当的第三方开发框架，就已经基本能满足日常开发的需要了。虚拟机会在用户不知不觉中完成对硬件平台的兼容及对内存等资源的管理工作。随着程序的性能、 稳定性和可扩展性方面都需要迫切提高，了解java虚拟机为了写出最适合虚拟机运行和自优化的代码。

   JDK 1.7在2011年7月28日正式发布，新版本增加了新特性和改进，1.7中最新的G1收集器，以及JDK 1.7中JSR-292InvokeDynamic（对非Java语言的调用支持）的分析讲解等内容。书本面向的读者：

（1）使用Java技术体系的中、高级开发人员。Java虚拟机作为中、 高级开发人员必须修炼的知识。

（2）系统调优师：系统调优师是近几年才兴起的职业。
（3）系统架构师：保障系统的性能、 并发和伸缩等能力是系统架构师的主要职责之一，而这部分与虚拟机的运作密不可分。

                                                            二、走进java

2、1概述

Java不仅仅是一门编程语言，还是一个由一系列计算机软件和规范形成的技术体系，这个

技术体系提出了 完整的用于软件开发和跨平台部署的支持环境，并广泛应用到各种终端。

java语言的有点不仅仅他是一种结构严谨的面向对象的语言还有其它的优点：1：它摆脱

了硬件平台的束缚，实现了“一次编写，到处运行”的理想；2：它提供了一个相对安全

的内存管理和访问机制，避免了绝大部分的内存泄露和指针越界问题；3：它实现了热点

代码检测和运行时编译及优化，这使得Java应用能随着运行时间的增加而获得更高的性能

4：它有一套完善的应用程序接口，还有无数来自商业机构和开源社区的第三方类库来帮

助它实现各种各样的功能。

2、2  java体系结构

  从广义上讲，运行于Java虚拟机上的语言及其相关的程序都属于Java技术体系中的一员。 如果仅从传统意义上来看，Sun官方所定义的Java技术体系包括以下几个组成部分：
1：Java程序设计语言。2：各种硬件平台上的Java虚拟机。3：Class文件格式。4：Java API类库。5：来自商业机构和开源社区的第三方Java类库。

可以把Java程序设计语言、Java虚拟机、Java API类库这三部分统称为JDK（JavaDevelopment Kit），JDK是用于支持Java程序开发的最小环境。可以把Java API类库中的JavaSE API子集 和Java虚拟机这两部分统称为JRE（Java Runtime Environment），JRE是支持Java程序运行的标准环境。如图体系结构（以组成部分功能划分），按照技术领域划分主要是右图的三个方向还有java Card：支持一下小程序运行在小内存设备如智能卡上的平台。java ME：支持移动动端平台以前也称J2ME。java SE：支持桌面级应用程序。java EE：企业级开发。（J2EE）

2.3 java发展史

1995年5月23日，Oak语言改名为Java，并且在SunWorld大会上正式发布Java 1.0版本。JDK 1.0版本的代表技术包括：Java虚拟机、Applet、AWT等。

1.1版的技术代表有：JAR文件格式、JDBC、JavaBeans、RMI。Java语法也有了一定的发展，如内部类（Inner Class）和反射（Reflection）都是在这个时候出现的。
JDK 1.2把Java技术体系拆分为3个方向，分别是面向桌面应用开发的。J2SE（Java 2 Platform,Standard Edition）、 面向企业级开发的J2EE（Java 2 Platform,EnterpriseEdition）和面向手机等移动终端开发的J2ME（Java 2 Platform,Micro Edition）。
JDK 1.4是Java真正走向成熟的一个版本。JDK 1.4同样发布了很多新的技术特性，如正则表达式、 异常链、 NIO、 日志类、 XML解析器和XSLT转换器等。 
JDK 1.5在Java语法易用性上做出了非常大的改进如，自动装箱、 泛型、 动态注解、 枚举、 可变长参数、 遍历循环（foreach循环）等语法特性。
JDK 1.6的改进包括：提供动态语言支持（通过内置MozillaJavaScript Rhino引擎实现）、 提供编译API和微型HTTP服务器API等。 同时，这个版本对Java虚拟机内部做了大量改进，包括锁与同步、 垃圾收集、 类加载等方面的算法都有相当多的改动。

2.4 java的未来

1：模块化：模块化是解决应用系统与技术平台越来越复杂、 越来越庞大问题的一个重要途径。

2：混合语言：Java平台上的多语言混合编程，越来越多基于Java虚拟机的语言开发被应用到软件项目中。

3：多核并行：并行编程多核并行运算解决任务。在Java 8中，将会提供Lambda支持，这将会极大改善目前Java语言不适合函数式编程的现状（目前Java语言使用函数式编程并不是不可以，只是会显得很臃肿）。

4：进一步丰富语法。

5: 64位虚拟机：Java虚拟机在很早之前就推出了支持64位系统的版本。 但Java程序运行在64位虚拟机上需要付出比较大的额外代价：首先是内存问题，由于指针膨胀和各种数据类型对齐补白的原因，运行于64位系统上的Java应用需要消耗更多的内存，通常要比32位系统额外增加10%～30%的内存消耗；其次，多个机构的测试结果显示，64位虚拟机的运行速度在各个测试项中几乎全面落后于32位虚拟机，两者大约有15%左右的性能差距。

                                                 二、第二部分-走进内存管理机制

2.1 Java内存区域与内存溢出异常

java有了虚拟机就不会那么容易出现内存泄漏和内存溢出，但不可能杜绝这种情况，所以一旦出现这种情况了解怎样处理非常有必要了解java虚拟机。如图java运行时内存区域划分。

内存划分不同的区域有着不同的用途以及创建和销毁时间下面具体举例说一下不同区域的作用：

       1): 程序计数器：(Program Counter Register)是一块较小的内存空间，它可以看作是当前线
程所执行的字节码的行号指示器。在虚拟机的概念模型里(仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现)，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、 循环、 跳转、 异常处理、 线程恢复等基础功能都需要依赖这个计数器来完成。java的多线程是快速切换线程任务依此获得cpu执行，对于单核的处理器一个时刻只能执行一条指令，所以执行结束要切换回来为了保证之前的指令正确继续执行，每条线程都有一个独立的程序计数器，称之为线程私有内存区。如果正在执行java方法，程序计数器执行的是虚拟机字节码指令的地址。如果是本地native方法，则计数器值为空，此区域是唯一一个java虚拟机中没有规定OutOfMemoryError情况的区域。

        2):  Java虚拟机栈：(Java Virtual Machine Stacks)也是线程私有,生命周期与线程相同，他描述的是java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表、 操作数栈、 动态链接、 方法出口等信息。 每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。一般java内存划分为堆(Heap)和栈(Stack)，粗糙的划分涉及最密切的两个区域，栈就是虚拟机栈或者说是虚拟机栈中局部变量的表示部分。局部变量表存放的是各种基本类型、引用类型(不等同于本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置)和returnAddress类型(指向了一条字节码指令的地址)。long和double数据占用2个局部变量空间，其余只占一个，他们所需的内存空间在编译时期完成分配。在方法运行期间不会改变局部变量表的大小。关于本区域的两种异常：1、如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；2:、如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。

        3）本地方法区：(Native Method Stack)与虚拟机栈所发挥的作用是非常相似的它们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的Native方法服务。 在虚拟机规范中对本地方法栈中方法使用的语言、 使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。 甚至有的虚拟机直接就把本地方法栈和虚拟机栈合二为一。 与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

        4）java堆：java虚拟机管理的最大的一块内存，被所有线程共享的一块内存，虚拟机启动时创建。它就是用来存放对象实例(规范写道：所有的对象实例以及数组都分配在堆上)不过随着JIT编译器的发展与逃逸技术的成熟，不是那么绝对的区域了。现在得垃圾收集器都是基于分代收集算法，堆是垃圾回收的主要区域，java堆又分为新生代和老年代；再细致一点的有Eden空间、 From Survivor空间、 To Survivor空间等。进一步的划分是为了更好地回收或者是更快的分配与存放内容无关。

        5）方法区(Non-Heap)：(Method Area)和堆一样是线程共享的区域，用于存储已被虚拟机加载的类信息、常量、静态常量、即时编译后的代码数据。这部分区区域在HotSpot虚拟上会和永久代联系在一起。但并不等同，垃圾回收一般不会触及到这部分区域但是这部分的回收还是很有必要一般针对常量池和对类型的卸载。关于内存溢出，当方法区无法满足内存分配的需求时将抛出OutOfMemoryError异常。

        6）运行池常量：(Runtime Constant Pool)是方法区的一部分Class文件中除了有类的本、字段、 方法、 接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。运行池常量池的一个特征是动态性，并非预置的才能进入，运行期间也有可能进入新的常量(String类的 intern()方法)也会出现无法满足申请时的OutOfMemoryError异常 。

        7） 直接内存： ( Direct Memory) 并不是虚拟机运行时数据区的一部分，也不是 Java 虚拟机规 范中定义的内存区域但是这部分内存也被频繁地使用而且也可能导OutOfMemoryError异常出现。对象的创建：（HotSpot虚拟机上探讨）虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、 解析和初始化过。 如果没有，那必须先执行相应的类加载过程。类加载完后就是内存划分，内存的划分又涉及到内存是否规整，内存是否规整又和虚拟机采用的垃圾收集器是否带有压缩整理功能有关：所以对象的分配两种方式1:、指针碰撞（内存规整，即内存中用过的放一边没用的放另一边中间放一些指针作为作为分界点指示器），分配就是指针移动画出与对象大小内存一样的空间。 2、空闲列表（内存不规整）这种方式虚拟机要建立一个维护列表记录哪些可用哪些不可用。 在使用Serial、 ParNew等带Compact过程的收集器时，系统采用的分配算法是指针 碰撞，而使用CMS这种基于Mark-Sweep算法的收集器时，通常采用空闲列表。划分时又涉及到安全问题，即同步时一个对象划分指正没有完成，另一个对象也来用该指针划分。解决有1、对内存分配进行同步处理保证原子性操作。2、把分配动作按照线程划分到不同的空间中进行。即每个线程在java堆中预先分配一小块的内存区域成为线程分配缓冲（TLAB）。内存分配完成虚拟机进行内存空间的初始化零值，保证对象的实例在java代码中不赋值就能直接使用。接下来是对象的一些设置如这个对象是哪个类的实例、 如何才能找到类的元数据信息、 对象的哈希码、 对象的GC分代年龄等信息。 这些信息存放在对象的对象头(Object Header)之中。 根据虚拟机当前的运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。从虚拟机层面讲对象的创建已经完成但是还没用执行<init>方法，此方法的执行才是按照程序员的意愿进行对象的初始化。
 

                                                垃圾收集器与内存分配策略

        1、对象是否存活。（1）引用计数算法。通过计算引用计数器的值判断，对象是否被应用，这种方法无法解决自引用。（2）可达性分析算法。搜索路径判断引用链。

        2、不同类引用：强引用：程序中普遍使用的引用，这类引用垃圾回收器永远不会收掉的对象。

软引用：描述一些有用但并非必要的对象，在系统将要发生内存溢出之前，将会把这些对象列进回收范围之中进行第二次回收。如果内存不足，就会回收这些对象的内存。只要没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。

弱引用：野是用来描述非必要对象，强队比软引用更弱，只能生存在下一次垃圾回收发生之前，无论当前内存是否足够都会回收这些内存。

虚引用：最弱的一种引用，一个对象是否有虚引用的存在完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象，设置虚引用的关联的唯一目的是在这个对象被收集之前收到一个系统通知。

        3、回收方法区：方法区（或者HotSpot的永久代），在这个区的回收比较低，在堆中尤其是新生代，常规回收70%-95%的空间，永久代回收效率远远低于此。永久代的回收只要是两个，废弃常亮和无用的类，判断常量池对象是否无用直接看是否引用，判断对象是否有用比较麻烦满足：1）该类所有实例已经被回收，即java堆中不存在该类的任何实例。2）加载该类的classLoader已经被回收。3）该类的对应的java.lang.class对象没有任何地方被引用无法在任何地方通过反射访问该类的方法。

垃圾收集算法：标记清楚算法。标记和清除：一是效率不高，二是清理的空间产生大量的空间碎片。

复制算法：内存分两块，只对一个块进行垃圾回收。

标记-整理算法：复制算法在对象存活率高时，会进行较多复制效率会低，如果不想浪费50%空间就要进行分配担保，标记整理与标记清楚差别在于，不仅要清楚还要对存活的对象进行整理，向一端移动。

分代收集算法：根据对象存活周期的不同划分不同的块，一般java堆划分为新生代和老年代。新生代收集时会有大批对象死去，所以一般采用复制算法，老年代存活对象比较多且没有多余空间用于分配担保一般采用标记清楚和标记整理。

hotspot的算法实现：GC发起垃圾回收，枚举根节点检查引用量，通过OopMap的数据结构实现，GC扫描到停顿点安全点，只有到达安全点程序才会暂停，GC让所有线程到达安全点的停顿的方式有抢占式和主动式两种，抢占式是让代码主动配合，GC发生时让所有线程中断，没到安全点继续，主动式是设置一个标志，标志点和安全点重合。线程在sleep或者Blocked时无法向应JVM中断请求，安全区域解决这个问题。

4、垃圾收集器：内存回收的具体实现，

Serial收集器：java虚拟机中最基本，最老的收集器，单线程收集器，这里并不是说明他会使用一个cpu或一条收集线程去完成垃圾回收，重要的是他在垃圾回收时要停掉其他所有的工作，直到收集结束。直到jDK1.7为止他仍是虚拟机Client模式下默认的新生代收集器。优点，简单高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本上不会再大了），停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
ParNew收集器： 使用多线程进行垃圾回收其余与serial一致，是许多运行在server模式下的新生代收集器，

Parallel Scavenge收集器：采用复制算法的新生代收集器。也是并行多线程收集器。CMS关注于减少停顿时间，PS关注于达到一个可控制的吞吐量，吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值。

CMS收集器 ：  CMS（Concurrent Mark Sweep）收集器是基于“标记-清除”算法实现的，它使用多线程的算法去扫描堆（标记）并对发现的未使用的对象进行回收（清除）。整个过程分为4个步骤，包括：
初始标记（CMS initial mark）、并发标记（CMS concurrent mark）、重新标记（CMS remark）、并发清除（CMS concurrent sweep）。其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。其他动作都是并发的。CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序的运行自然还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好留待下一次GC时再将其清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即还需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。还有一个缺点，CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会产生大量空间碎片。空间碎片过多时，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数，用于在“享受”完Full GC服务之后额外免费附送一个碎片整理过程，内存整理的过程是无法并发的。空间碎片问题没有了，但停顿时间不得不变长了。

G1收集器 ：G1垃圾收集器在JDK7 update 4之后对大于4G的堆有了更好的支持，G1是一个针对多处理器大容量内存的服务器端的垃圾收集器，其目标是在实现高吞吐量的同时，尽可能的满足垃圾收集暂停时间的要求。G1在执行一些Java堆空间中的全区域操作（如：全局标记）时是和应用程序线程并发进行的，因此减少了Java堆空间的中断比例。

优点：1）并行与并发，G1充分利用多CPU，多核环境下的硬件优势，使用多CPU缩短停段时间，

2）分代收集，保留分代，不需要配合其他收集器完成收集工作，但是采取不同方式完成对新生对象和经过几次GC存活下来的对象。3）空间整合一是G1收集器是基于“标记-整理”算法实现的收集器，也就是说它不会产生空间碎片，这对于长时间运行的应用系统来说非常重要。二是它可以非常精确地控制停顿，既能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，具备了一些实时Java（RTSJ）的垃圾收集器的特征。4）可预测停顿：G1追求降低停顿外还追求建立可预测模型，能让使用者明确指定在一个长度为M的毫秒内，消耗在垃圾收集上的时间不得超过N毫秒。

5、java的内存分配：1）对象优先在新生代Eden区分配，当Eden没有足够空间时，虚拟机发生一次minor GC。2）大对象直接进入老年代，长的字符串或者数组，3）长期存活对象将进入老年代
由于虚拟机垃圾收集是基于“分代算法”的，故虚拟机必须能够识别哪些对象存放在新生代，哪些对象应该存放在老年代虚拟机设计了一个对象年龄计数器，如果对象在Eden区出生并且经过第一次Minor GC后依然存活，并且可以被Survivor区容纳，就会被复制至Survivor区并将对象年龄设置为1。以后对象每熬过一次Minor GC，对象年龄便+1。当对象年龄超过对象晋升老年代的年龄阀值（该阀值默认为15）时，便会晋升至老年代。4）动态对象年龄判定为了使内存分配更加灵活，虚拟机并不要求对象年龄达到MaxTenuringThreshold才晋升老年代如果Survivor区中相同年龄所有对象大小的总和大于Survivor区空间的一半，年龄大于或等于该年龄的对象在Minor GC时将复制至老年代。5）在触发Minor GC时，虚拟机会先检测之前GC时租借的老年代内存的平均大小是否大于老年代的剩余内存，如果大于，则将Minor GC变为一次Full GC，如果小于，则查看虚拟机是否允许担保失败（-XX:+/-HandlePromotionFailure。从jdk6.0开始，允许担保失败已变为HotSpot虚拟机所有收集器默认设置，虚拟机将不再识别该参数设置，详见JDK-6990095 : Deprecate and eliminate -XX:-HandlePromotionFailure），如果允许担保失败，则只执行一次Minor GC，否则也要将Minor GC变为一次Full GC（直到GC结束时才能确定到底有多少对象需要被移动至老年代，所以在GC前，只能使用粗略的平均值进行判断）。

                                                        虚拟机性能监控与故障处理

JDK的工具程序体积都很小，因为这些工具大多是jdk/lib/tools.jar类库的一层包装而已，他们主要的功能代码是在tools类库中实现的，假如使用的是Linux版本的JDK，还会发现这些工具中很多甚至就是由Shell脚本直接写成的，可以用vim直接打开它们。JDK开发团队选择采用Java代码来实现这些监控工具是有特别用意的，当应用程序部署到生产环境后，无论是直接接触物理服务器还是远程Telnet到服务器上都可能会受到限制，借助tools.jar类库里面的工具，我们可以直接在应用程序中实现功能强大的监控分析功能。（JDK版本的影响）如果在工作中需要监控运行于JDK 1.5的虚拟机之上的程序，在程序启动时请添加参数“-Dcom.sun.management.jmxremote”开启JMX管理功能，否则由于部分工具都是基于JMX，它们都将无法使用如果被监控程序运行于JDK 1.6的虚拟机之上，那JMX管理默认是开启的，虚拟机启动时无须再添加任何参数。

1、jps：虚拟机进程状况工具

jps典型的unix命名格式，名字与功能都和ps命令类似：可以列出正在运行的虚拟机进程，并显示虚拟机执行主类(Main Class，main()函数所在的类)名称以及这些进程的本地虚拟机唯一ID(Local Virtual Machine Identifier，LVMID)。功能单一但使用频率较高。对于本地虚拟机进程来说，LVMID与操作系统的进程ID（Process Identifier，PID）是一致的。以下是jsp主要功能选项1、jps -l：输出主类的全名，如果进程执行的是Jar包，输出Jar路径：2、jps -v：输出虚拟机进程启动时JVM参数。3、jps -m：输出虚拟机进程启动时传递给主类main()函数的参数。4、jps -q：只输出LVMID，省略主类的名称。

2、jstat：虚拟机统计信息监视工具

jstat（JVM Statistics Monitoring Tool）是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载，内存，垃圾收集，JIT编译等运行数据。在没有GUI图形界面，只提供了纯文本控制台环境的服务器上，它将是运行期定位虚拟机性能问题的首选。
jstat命令格式为：jstat [option vmid [interval [s | ms] [count]]]。interval和count代表查询间隔和次数。省略说明只查一次。选项option代表用户希望查询的虚拟机信息，主要分为3类：类加载、垃圾收集、运行期编译状况。对于命令格式中的VMID与LVMID需要特别说明一下：如果是本地虚拟机进程，VMID与LVMID是一致的，如果是远程虚拟机进程，那VMID的格式应当是：[protocol:][//]lvmid[@hostname[:port]/servername]
命令1：jstat -gc 13991 200 5：每200毫秒查询一次进程2764垃圾收集状况，一共查询5次：
命令2：jstat -gcutil 13991 200 5：监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比。

3、jinfo：Java配置信息工具

jinfo的作用是实时地查看和调整虚拟机各项参数。使用jps命令的-v参数可以查看虚拟机启动时显示指定的参数列表，但如果想知道未被显示指定的参数系统默认值，除了去找资料外，就只能使用jinfo的-flag选项进行查询了（如果只限于JDK 1.6或以上版本的话，使用java -XX:+PrintFlagsFinal查看参数默认值也是一个很好的选择），jinfo还可以使用-sysprops选项把虚拟机进程的System.getProperties()的内容打印出来。使用-flag [+|-] name或者 -flag name=value 修改一部分运行期可写的虚拟机参数值。
命令：jinfo -flag CMSInitiatingOccupancyFraction 13991：查询CMSInitiatingOccupancyFraction参数值。

4、 jmap：Java内存映射工具

jmap（memory map for java）命令用于生成堆转储快照（一般称为heapdump或dump文件）。如果不使用jmap命令，要想获取Java堆转储快照，譬如通过“暴力手段”-XX:+HeapDumpOnOutOfMemoryError参数，可以让虚拟机在OOM异常出现之后自动生成dump文件；通过-XX:+HeapDumpOnCtrlBreak参数则可以使用[Ctrl] + [Break]键让虚拟机生成dump文件；或者在linux系统下通过kill -3命令发送进程退出信号“吓唬”一下虚拟机，也能拿到dump文件。
jmap除了获取dump文件，它还可以查询finalize执行队列，Java堆和永久代的详细信息，如：空间使用率，当前使用的是哪种收集器等。命令：jmap -dump:format=b,file=idea.bin 13991

5、jhat：虚拟机堆转储快照分析工具

Sun JDK提供jhat命令与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器中查看。不过在实际工作中，很少使用jhat命令来分析dump文件，主要原因有二：一般不会在部署应用程序的服务器上直接分析dump文件，即使可以这样做，也会尽量将dump文件复制到其他机器上进行分析，因为分析工作是一个耗时且消耗硬件资源的过程；另外就是jhat命令分析功能相对来说比较简陋。

6、jstack：Java堆栈跟踪工具

jstack（stack trace for java）命令用于生成虚拟机当前时刻的线程快照。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如：线程死锁，死循环，请求外部资源导致的长时间等待都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以直到没有响应的线程到底在后台做写什么事情，或者等待着什么资源。命令格式：jstack[option]vmid
option选项不同所代表含义：-F 当正常输出的请求不被响应时，强制输出线程堆栈。-l 除堆栈外，显示关于锁的附加信息。-m 如果调用到本地方法的话，可以显示C/C++的堆栈。在JDK 1.5中，java.lang.Thread类新增了一个getAllStackTraces()方法用于获取虚拟机中所有线程的StackTraceElement对象。

7、HSDIS：JIT生成代码反汇编

高性能虚拟机真正的细节实现方式已经渐渐与虚拟机规范所描述的内容产生了越来越大的差距，虚拟机规范中的描述逐渐成了虚拟机实现的“概念模型”—即实现只能保证规范描述等效。基于这个原因，我们分析程序的执行语义问题（虚拟机做了什么）时，在字节码层面上分析完全可行，但分析程序的执行行为问题（虚拟机是怎样做的，性能如何）时，在字节码层面上分析就没有什么意义了，需要通过其他方式解决。
分析程序如何执行，通过软件调试工具来断点调试是最常见的手段，但是这样的调试方式在Java虚拟机中会遇到很大困难，因为大量执行代码是通过JIT编译器动态生成到CodeBuffer中的，没有很简单的手段来处理这种混合模式的调试。因此，不得不通过一些特别的手段来解决问题，基于这种场景，HSDIS插件终于登场了。HSDIS是一个Sun官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件，它包含在HotSpot虚拟机的源码之中，但没有提供编译后的程序。它的作用是让HotSpot的-XX:+PrintAssembly指令调用它来把动态生成的本地代码还原为汇编代码输出，同时还生成了大量非常有价值的注释，这样我们就可以通过输出的代码来分析问题。

JDK的可视化工具

1、JConsole：Java监视与管理控制台

JConsole是一种基于JMX的可视化监视管理工具，它管理部分的功能是针对JMX MBean进行管理，由于MBean可以使用代码，中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问。1、启动JConsole：将自动搜索出本机运行的所有虚拟机进程，也还可以对远程进程监控（相当于jps）。2、内存监控：用于监视收集器管理的虚拟机内存（Java堆和永久代）的变化趋势（相当于jstat）。3、线程监控：用于线程停顿时可以使用此进行监控（相当于jstack）。

Visual VM：多合一故障处理工具

Visual VM是到目前为止随JDK发布的功能最强大的运行监视和故障处理程序，并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具。包括：运行监视，故障处理，性能分析等。而且Visual VM的还有一个很大的优点：不需要被监视的程序基于特殊Agent运行，因此它对应用程序的实际性能的影响很小，使得它可以直接应用在生产环境中。注意：Visual VM是在JDK 1.6 update 7中才首次出现，但并不意味着它只能监控运行于JDK1.6上的程序，它具备很强的向下兼容能力。早于JDK 1.6的平台，需要打开-Dcom.sun.management.jmxremote参数才能被Visual VM管理。

1、Visual VM兼容范围与插件安装 ：1、显示虚拟机进程以及进程的配置，环境信息（jps，jinfo），2、监视应用程序的CPU，GC，堆，方法区以及线程的信息（jstat，jstack）。 3、dump以及分析堆转储快照（jmap，jhat）。 4、方法级的程序运行性能分析，找出被调用最多，运行时间最长的方法。 5、离线程序快照：收集程序的运行时配置，线程dump，内存dump等信息建立一个快照，可以将快照发送开发者进行Bug反馈。6、其他plugins的无限的可能性。

2、生成，浏览堆转储快照。

3、分析程序性能 在Profiler页签中，Visual VM提供了程序运行期间方法级的CPU执行时间分析以及内存分析，做Profiling分析肯定会对程序运行性能有比较大的影响，所以一般不在生产环境中使用这项功能。如果是CPU分析，将会统计每个方法的执行次数，执行耗时；如果是内存分析，则会统计每个方法关联的对象数以及这些对象所占的空间。

4、BTrace动态日志跟踪 BTrace的作用是在不停止目标程序运行的前提下，通过HotSpot虚拟机的HotSwap技术动态加入原本并不存在的调试代码。HotSwap技术：代码热替换技术，HotSpot虚拟机允许在不停止运行的情况下，更新已经加载的类的代码。