《深入理解java虚拟机》

本文将周志明的《深入理解java虚拟机》中需要记忆的内容提取，方便回忆，一起学习一下大神对JVM的理解。

一、Java内存区域与内存溢出异常

1、内存区域划分

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。

程序计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。如果线程执行Java方法，计数器记录的是正在执行的虚拟机字节码指令的地址；如果执行Native方法，这个计数器值则为空（Undefined）。程序计数器区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

虚拟机栈

与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成对应着一个栈帧入栈到出栈的过程。局部变量表存放各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。

本地方法栈

本地方法栈则为虚拟机使用到的Native方法（Native Method：该方法的实现由非java语言实现）服务。与虚拟机栈一样，本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。

Java堆

Java堆（Java Heap）一般是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，启动时创建。此内存区域的唯一目的就是存放对象实例，分配内存。Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、方法、即时编译器编译后的代码等数据。

2、JVM中的对象

对象的创建

虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。在类加载检查通过后，接下来虚拟机将为新生对象分配内存。分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”。虚拟机维护一个列表，记录上哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称为“空闲列表”。像Serial、ParNew等带Compact过程的垃圾收集器采用指针碰撞分配内存，而CMS等基于Mark-Sweep的采用空闲列表分配内存。

对象的访问定位

目前主流的访问方式有使用句柄和直接指针两种。为了使用对象，我们的Java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置，所以对象访问方式也是取决于虚拟机实现而定的。修改对象的指针就会产生给对象A分配内存时指针还未修改，又给对象B分配内存的同步锁问题，解决这种问题，主要有两种方案，一是CAS加失败重试机制来保证更新操作的同步，二是将内存分配动作划分在不同空间进行，及本地线程分配缓冲（TLAB）

3、OutOfMemoryError异常

Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。解决这个区域的异常，一般的是先通过内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。内存泄漏是指本该被回收的对象与GC Roots进行关联导致GC不能回收，我们需要通过引用链来定位对象是在何地泄漏引用。内存溢出是指内存已经不够分配出存放对象的空间，我们可以通过调整JMV的堆参数 -Xmx -Xms来调大，同时减少对象生命周期的办法解决。

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

当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

引用计数算法

对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。引用计数算法有一个缺陷就是，如果A与B互相引用，它们的引用计数都不为0，就一直不会被回收。

可达性分析算法

从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连，从GC Roots到这个对象不可达时，则证明此对象是不可用的。

回收方法区

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

类需要同时满足3个条件才能算是“无用的类”：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

垃圾收集算法

标记-清除算法、复制算法、标记-整理算法、分代收集算法

Minor GC

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，Minor GC非常频繁，一般回收速度也比较快。

Major GC/Full GC

指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC。Major 的速度一般会比Minor GC慢10倍以上。

四、虚拟机性能监控与故障处理工具

JDK的命令行工具

jps : 虚拟机进程状况工具

jps[options][hostid]
//列出正在运行的虚拟机进程,并显示虛拟机执行主类名称以及这些进程的本地虛拟机唯一ID 

jstat :虚拟机统计信息监视工具

jstat[option vmid[interval[s|ms][count]]]
//监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据

jinfo : Java配置信息工具

jinfo[option]pid
//实时地查看和调整虚拟机各项参数。

jmap : Java内存映像工具

jmap[option]vmid
//用于生成堆转储快照(一般称为heapdump或dump文件 )

jhat :虚拟机堆转储快照分析工具
分析jmap生成的堆转储快照。

jstack : Java堆栈跟踪工具

jstack [option] vmid
//生成虚拟机当前时刻的线程快照

五、虚拟机类加载机制

类加载的生命周期：

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段

加载
（1）生成二进制字节流（2）将字节流转化为方法区的运行时数据结构。（3）在内存中生成Class对象

验证
（1）文件格式验证（2）元数据验证（3）字节码验证（4）符号引用验证

准备
在方法区为类变量分配内存并设置类变量初始值的阶段

解析
虚拟机将常量池内的符号引用替换为直接引用的过程

初始化
执行类中定义的Java程序代码

类加载器

类加载器虽然只用于实现类的加载动作，任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。

双亲委派模型

从 Java 虚拟机的角度来讲，只存在两种类加载器：

• 启动类加载器（Bootstrap ClassLoader）

• 其它类的加载器：
  扩展类加载器（Extension ClassLoader）
  应用程序类加载器（Application ClassLoader）
  自定义类加载器（User ClassLoader）

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。 

破坏双亲委派模型

由于系统自带的三个类加载器都加载特定目录下的类，如果我们自己的类加载器放在一个特殊的目录，那么系统的加载器就无法加载，也就是最终还是由我们自己的加载器加载。

到目前为止，双亲委派模型主要出现过3较大规模的“被破坏”情况。

（1）用户去继承java.lang.ClassLoader覆盖loadClass（）方法

（2）线程上下文类加载器（Thread Context ClassLoader）

（3）热插拔：热替换（HotSwap）、模块热部署（Hot Deployment）

为什么要采用委托机制？

防止内存中出现多份同样的字节码。

• 如果不用委托而是自己加载自己的，那么类A就会加载一份System字节码，然后类B又会加载一份System字节码，这样内存中就出现了两份System字节码。
• 如果使用委托机制，会递归的向父类查找，也就是首选用Bootstrap尝试加载，如果找不到再向下。这里的System就能在Bootstrap中找到然后加载，如果此时类B也要加载System，也从Bootstrap开始，此时Bootstrap发现已经加载过了System那么直接返回内存中的System即可而不需要重新加载，这样内存中就只有一份System的字节码了。