JVM学习点

垃圾回收算法

复制算法：将可用内存按容量分成大小相等的两块，每次只使用其中一块，当这块内存使用完了，就将还存活的对象复制到另一块内存上去，然后把使用过的内存空间一次清理掉。
标记清除算法：将垃圾回收分成了两个阶段：标记阶段和清除阶段。首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。缺点：1、效率问题，标记和清除效率都不高。2、空间问题，标记清除后产生大量不连续的内存碎片。
标记-整理算法：标记过程和标记清除算法一样，后续是让所有活着的对象都向一端移动，然后直接清理掉端边界以外的内存。
分代收集算法：根据内存对象存活周期的不同划分几块，根据每块内存区间的特点，使用不同的回收算法，从而提高垃圾回收的效率。Java虚拟机中的堆就采用了这种方法分成了新生代和老年代。

serial收集器：针对新生代的收集器，复制算法
ParNew收集器（并行）： 新生代采用复制算法，老年代采用标记整理
parallel scavenge收集器（并行）： 针对新生代，采用复制收集算法
Seral Old（串行）： 收集器 新生代采用复制，老年代采用标记清除
Parallel Old（并行）：收集器，针对老年代，标记整理
CMS收集器：基于标记清除
G1收集器：整体上是基于标记整理，局部采用复制
综上：新生代基本采用复制算法，老年代采用标记整理或标记清除算法。cms采用标记清理。

2017-12-04T18:10:33.109+0800: 11.912: [GC (Allocation Failure) 2017-12-04T18:10:33.109+0800: 11.912: [ParNew: 419456K->12890K(471872K), 0.0210005 secs] 441241K->34675K(2044736K), 0.0211066 secs] [Times: user=0.08 sys=0.00, real=0.02 secs] 

Allocation Failure – 引起垃圾回收的原因，本次GC是因为年轻代中没有任何合适的区域能够存放需要分配的数据结构而触发的.

Serial + Serial Old
DefNew:serial收集器新生代(Default New Generation)
Tenured:老年代
Perm:永久代

Serial + ParNew
ParNew:ParNew收集器新生代(parallel New Generation)
Tenured:老年代
Perm:永久代

Parallel Scavenge + Parallel Old 
PSYoungGen:新生代
ParOldGen:老年代
PSPermGen:永久代

ParNew + CMS + Serial Old 
DefNew：新生代(def new generation) 
CMS：老年代：
CMS Perm：永久代

[Times: user=0.08 sys=0.00, real=0.02 secs]  
user 是用户态消耗的CPU时间，sys 是内核态消耗的CPU时间，而real 是操作从开始到结束的墙钟时间

Minor GC：Eden 没有足够空间分配时，触发 Minor GC，非常频繁
Major GC：清理老年代
Full GC：清理整个堆空间—包括年轻代和老年代

java命令行工具

jps：虚拟机进程状况工具
-q
只输出LVMID，同进程pid
-m
输出JVM启动时传给主类main()的参数。
-l
输出主类全名。如果进程执行的是jar包，则输出包名。
-v
输出JVM启动时JVM参数

jstat：虚拟机统计信息监视工具
命令格式
jstat [ option vmid [interval[s|ms] [count]] ]

option参数：
-class
监视类装载、卸载数量，字节数，以及类装载所耗费的时间。
-gc
监视java堆状况，包括Eden区，Survivor区，Old区，Perm区的容量，已使用容量及YGC，FGC发生的次数及耗费的时间。
-gccapacity
监视Java堆各个区的最大，最小使用容量及配置容量。
-gcutil
监视Java堆各个区的空间使用百分比及YGC，FGC发生的次数及耗费的时间。
-gccause
同-gcutil功能相同，额外输出上一次GC产生的原因。
-compiler
输出JIT编译器编译过的方法个数，耗时等信息。
-printcompilation
输出已经被JIT编译的方法

例：jstat -gc vmid 1000 5

jinfo：Java配置信息工具
实时查看和调整虚拟机各项参数。
jinfo [ option ] pid

option参数：
-flag name
打印给定name对应的命令行参数值。
-flag [+|-]name
更改boolean类型的命令行参数值
-flag name=value
更改name对应的命令行参数值为value。
-flags
打印传给JVM的命令参数值。
-sysprops
打印系统属性值。

jmap:Java内存映像工具
用于生成堆转储快照。
命令格式
jmap [ option ] vmid

option参数：
-finalizerinfo
显示在F-Queue中等待Finalizer线程执行finalize方法的对象。Only for Linux。
-heap
显示Java堆栈详细信息，例如GC收集器，参数配置，JVM内存分区情况。Only for Linux。
-histo
显示堆中对象的统计信息，包括类、实例数量、容量大小。
-permstat
按照ClassLoader统计Perm区的内存状态。Only for Linux。
-F
与-dump参数一起使用，强制生成dump文件。

jhat:虚拟机堆转储快照分析工具
与jmap搭配使用，分析jmap生成的堆转储快照。

-port
指定http启动的端口，默认7000
-J<flag>
指定传给jhat JVM的参数，-J-Xmx512m表示jhat进程最大堆大小为512m。

jstack：java堆栈跟踪工具
用于生成当前时刻的线程快照。
命令格式：
jstack [ option ] vmid

option参数：
-F
当正常输出请求得不到响应时，强制输出堆栈信息。
-l
除堆栈外，显示关于锁的附加信息。
-m
如果调用native方法，则可以打出c/c++的线程堆栈。

JDK可视化工具
jconsole：java监视与管理控制台
JConsole是一款基于JMX的可视化管理工具，将自动搜索本机运行的jvm进程，不需要jps命令来查询指定。双击其中一个jvm进程即可开始监控，也可使用“远程进程”来连接远程服务器。

jvisualvm：多合一故障处理工具

 

基于NetBeans平台开发，它具备了插件扩展功能的特性，通过插件的扩展，可用于显示虚拟机进程及进程的配置和环境信息(jps，jinfo)，监视应用程序的CPU、GC、堆、方法区及线程的信息(jstat、jstack)等

 

 

类加载机制

类加载的过程
类加载生命周期：加载--验证--准备--解析--初始化--使用--卸载，其中准备、验证、解析3个部分统称为连接

加载
在加载阶段，虚拟机需要完成以下3件事情：

1、通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
加载阶段和连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
验证阶段大致会完成4个阶段的检验动作：

1、文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型等等。
2、元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外、这个类的父类是否继承了不允许被继承的类、如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法...。第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息。
3、字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
4、符号引用验证：目的是确保解析动作能正确执行。如果无法通过符号引用验证，那么会抛出一个java.lang.IncompatibleClassChangeError异常的子类。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：
public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123.因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
至于“特殊情况”是指：public static final int value=123，即当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0.

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的java程序代码。
在准备阶段，变量已经付过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主管计划去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器<clinit>()方法的过程。
1、遇到new,getstatic,putstatic,invokestatic这失调字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
2、使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3、当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4、当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
5、当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。

 

类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。也就是说，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的“相等”包括了代表类的Class对象的equals（）、isAssignableFrom（）、isInstance（）等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。

双亲委派模型
从Java虚拟机的角度来讲，只存在两种不同的类加载器：
启动类加载器（Bootstrap ClassLoader）：它使用C++实现，是虚拟机自身的一部分。
所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。
从java开发人员的角度来讲，类加载器可以大致划分为以下三类：
启动类加载器（Bootstrap ClassLoader）：它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
扩展类加载器（Extension ClassLoader）：该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。
应用程序类加载器（Application ClassLoader）：该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

 

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这边保证了Object类在程序中的各种类加载器中都是同一个类。