笔者花了一个星期的晚上时间看完了前面三章，由于之前在其他博客看过JVM的东西，所以看起来比较快。

前l两章内容分别是--走近Java；Java内存区域与内存溢出异常。其中部分除黑色内容属于扩展性内容或解释性内容。第一章可以大致看一遍，其中链接部分可仔细阅读。

第一章：走近Java

1.1 JDK、JRE定义以及关系

Java技术体系包括五个部分

• Java程序设计语言
• 各种硬件平台上的Java虚拟机
• Class文件格式
• Java API类库
• 来自商业机构和开源社区的第三方类库

JDK（Java Developmenet kit）：包含的部分有Java程序设计语言、Java虚拟机、Java API类库这三部分，JDK又称是用于支持Java程序开发的最小环境；

JRE（Java RunTime Environment）：属于JDK的一部分，它包含了Java虚拟机和Java核心类库（即Java API类库的子集）；

两种解释方式，同一个意思

• JDK包含JRE，JDK中编译器、调试器和其他工具JRE是没有的。如果需要编译.java文件，是需要JDK的支持的。
• JDK可以看作是JRE的一个超集，提供了更多的工具，比如编译器、各种诊断工具等

1.2 Java技术体系可划分为四个　　

• Java Card：支持一些Java小程序（Applets）运行在小内存设备（如智能卡）上的平台。——关于Applets之前有在面试一家公司时了解到，他们是用作于ERP系统的开发；
• Java ME：支持Java程序运行在移动终端（手机、PDA）上的平台，对于Java API有所精简，并加入了针对移动终端的支持，之前叫J2ME。——09年的之前时候，每个人的非智能手机上应该都接触过Java开发的手机游戏，打开游戏时会第一个显示出Java，和一杯咖啡。关于Java为什么图标是一杯咖啡呢，是因为class文件的魔数（一种鉴别文件的编码，因为文件的后缀名是很容易更改的，才有了魔数来确定文件类型，具体的可以看看百度的简单介绍）为0x CA FE BA BE （在16进制编辑器中打开），名字；也是印度尼西亚一个岛的名称，就叫爪哇岛，且岛上盛产咖啡；
• Java SE：支持面向桌面级应用的Java平台，提供了完整的Java核心API，这个版本以前称为J2SE。——我们之前也做过QQ-Java版本的，主要是由JavaSwing包下面和awt包下面的类来构建，下载了相应的插件也可以做到拉扯式编程，但是每个对象一定要自己重新命名，否则到时候自己找不到哪个对象是哪个控件；
• Java EE：支持使用多层架构的企业应用（如ERP、CRM应用）的Java平台，除了提供Java SE API外，还对其做了大量的扩充并提供了相关的部署支持，以前叫J2EE。——就是我们熟知的网站后端项目，扩充就是javax.*包下的类。现在流行前后端分离，所以完全可以舍弃JSP了，后端开发人员只需提供相应的JSON数据与前端对接就够了，这也是以后项目的必然发展趋势。

1.3 Java虚拟机的品种（服务器端主要的）

• Classic VM——世界上第一款商用Java虚拟机。毕竟是开国元勋，纪念还是要的
• HotSpot VM——它是SunJDK和OpenJDK自带的虚拟机，也是目前使用范围最广的Java虚拟机。打开cmd，输入java -version，会显示如下图的信息（前提是你装的是1.8版本的）。关于SunJDK和OpenJDK其实就是一个不开源，一个开源，基本功能都差不多。
• JRockit / J9——一个是BEA公司的，一个属于IBM公司，都说是 "世界上速度最快的Java虚拟机"。可是默认的虚拟机还是HotSpot，淘宝就基于OpenJDK开发出了属于自己的TaoBao VM。

图1.1  java -version示意图

1.4 展望Java技术未来之多核并行

随着多核时代的来临，软件开发越来越关注并行编程的领域。早在JDK1.5就已经引入了java.util.concurrent包实现了一个粗粒度的并发框架。而JDK1.7中加入的java.util.concurrent.forkjoin包则是对这个框架的一次重要扩充。敲黑板，重点——java.util.concurrent包下的类很重要，其中ConcurrentHashMap面试时一般会问到，可以去看看极客时间的杨晓峰讲的源码解析，以及最基本的AQS（AbstractQueuedSynchronizer）同步结构类也是值得去看看的。有关并发编程，Java并发编程的艺术 这本书讲的非常好，通俗易懂，可以去看看。作为一名合格的Java程序猿，CAS机制也是必须要了解的，还有CAS中的ABA问题。

1.5 有关作者介绍的自己编译JDK

因为我是在Eclipse下操作的，关于作者NetBeans IDE下的操作，我就不照做了。其中看到有八皇后问题（33页），这个可能有些人不太了解，关于八皇后问题，链接里面讲的很清楚，此公众号讲解的算法及概念理解都很有趣，推荐。

2. Java内存区域与内存溢出异常

2.1 运行时数据区域

以下是《Java虚拟机规范（JavaSE 7版）》的规定，Java虚拟机所管理的内存将会包括以下几个运行时数据区域。左边暗粉色区域为线程共享区域，右边为线程私有的。

图2.1 Java虚拟机运行时数据区

2.1.1  程序计数器

程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里面（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释工作时就是通过改变这个计数器的值来选去下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程回复等基础功能都需要以来这个计数器来完成。

由于Java虚拟机的多线程是通过现场曾轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器是一个内核）都会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

如果线程正在执行的是一个Java方法，这个计数器记录的事正在执行的虚拟机字节码指令的地址：如果正在执行的是native方法，这个计数器值则为空。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。native方法可以在Unsafe类中发现大量的这种方法，关于Unsafe类，AtomicInteger中的CAS操作方法中最后调用的还是Unsafe里面的native修饰的compareAndSwapInt方法，关于native关键字,我觉得这个讲的比较好。

2.1.2  Java虚拟机栈

与程序计数器一样，Java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

Java虚拟机栈中还有着局部变量表部分，局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、doublle）、对象引用（reference类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。

其中64位长度的long和double类型的数据会占用2个局部变量空间（Slot），其余的数据类型只占用1个。局部变量表所需要的内存空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈）如果扩展是无法申请到足够的内存，就会抛出OOME异常。OutOfMemoryError后文就简称为OOME了。

2.1.3  本地方法栈

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

2.1.4 Java堆

对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。这一点Java虚拟机规范的描述是：所有的对象实例以及数组都要在堆上分配，但是随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。

Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”（Garbage Collected Heap）。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor 空间、To Survivor 空间等。从内存分配的角度来看，线程共享Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer，TLAB敲黑板：后面常提）。不过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，将进一步划分的目的是为了更好地回收内存，或者更快的分配内存。

根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OOME异常。关于参数我们可以看看安装的Eclipse安装目录下eclipse配置信息里面的参数，-vmargs以下的是虚拟机配置参数。如下图

图2.2 eclipse配置信息

在 -vmargs 下面是 JVM 的配置信息，使用 JDK1.8 版本，使用 G1 垃圾收集器，使用字符串去重机制，最小堆内存256M，最大堆内存1024M，关闭使用偏向锁。关于垃圾收集器第三章会重点介绍，堆内存的话一般 weblogic 和 tomcat 服务器优化是把最小和最大堆内存写成一样的，避免了扩展时产生不必要的内存碎片。偏向锁的话，在Java并发编程的艺术中有详细介绍，这里就不BB了。

2.1.5 方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即使编译器后的代码等数据。虽然Java虚拟机规范把方法区描述为对的一个逻辑部分，但是它却有一个别名叫做Nonn-Heap（非堆），目的应该是与Java堆区分开来。

对于习惯在HotSpot虚拟机上开发、部署程序的开发者来说，很多人都更愿意把方法区成为“永久代”（Permanent Generation）再敲黑板：JDK1.8后移除了永久代，本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已，这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存，能够省去专门为方法区编写内存管理代码的工作。对于其他虚拟机（如BAE JRockit、IBM J9等）来说是不存在永久代的概念的。原则上，如何实现方法区属于虚拟机实现细节，不受虚拟机规范约束，但使用永久代来实现方法区，并不是一个好主意，这样更容易遇到内存溢出问题（永久代有-XX:MaxPermSize的上限，其他两个虚拟机只要没有触碰到进程可用内存的上限，例如32为系统中的4GB，就不会出现问题），而且有极少数方法（例如String.intern()）会因为这个原因导致不同虚拟机下有不同的表现。因此，对于HotSpot虚拟机，根据官方发布的路线图信息，现在也有放弃永久代并逐渐改为采用Native Memory来实现方法区的规划了，在JDK1.7的HotSpot中，已经将字符串常量池从永久代中移除了。

Java虚拟机规范对方法区的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾手机。相对而言，垃圾收集行为在这区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说，这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是必要的。在Sun公司的BUG列表中，曾出现过的若干个严重的BUG就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。

2.1.6 运行时常量池

运行时常量池（Runtime  Pool）是方法区的一部分。Class文件中除了有类的版本，字段，方法，接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

运行时常量是相对于常量来说的，它具备一个重要特征是：动态性。当然，值相同的动态常量与我们通常说的常量只是来源不同，但是都是储存在池内同一块内存区域。Java语言并不要求常量一定只能在编译期产生，运行期间也可能产生新的常量，这些常量被放在运行时常量池中。这里所说的常量包括：基本类型包装类（包装类不管理浮点型，整形只会管理-128到127）和String（也可以通过String.intern()方法可以强制将String放入常量池）。

2.1.7 直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范定义中的内存区域。但那是这部分内存也被频繁地使用，而且也可能异常能导致OOME异常出现，所以放在一起讲。

JDK1.4中新加入了NIO（New Input / Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的 I / O 方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java堆和Native堆中来回复制数据。关于NIO以及NIO2（也叫AIO），非阻塞IO / 异步非阻塞IO，以后再进行讲解。

显然本机直接内存的分配不会受到Java堆大小的限制，但是，既然是内存，肯定还是会受到本机总内存（包括RAM以及SWAP区挥着分页文件）大小以及处理器寻址空间的限制。服务器管理员在配置虚拟机参数是，会根据实际内存设置 -Xmx等参数信息，但经常忽略直接内存，值得各个区域综合大于物理内存限制（包括物理的和操作系统级的限制），从而导致动态扩展时出现OOME异常。是你本机的内存，不属于Java虚拟机规范里面的东西，毕竟程序运行的时候，不止你Java虚拟机在运行。

2.2  关于HotSpot虚拟机

2.2.1 对象的创建

Java中对象的创建方式有4种（new、反序列化），这里只是讲用new关键字来创建时的状况。虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程。关于类加载过程在第七章，有关BootStrapClassLoader  相关类的介绍，和双亲委派机制是啥，一句话：在执行类加载时，会先去找父类加载器可不可以解决，可以，就让父类加载器来做，没有才轮到你。说到类加载，有三种类加载器：BootStrapClass Loader （启动类加载器） --- Extension ClassLoader（扩展类加载器）---Application ClassLoader （应用程序类加载器）。这里的类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

在类加载检查通过后，接下来虚拟机将为新生对象分配内存，为对象分配内存就是把一块确定大小的内存从Java堆中划分出来。对象所需要内存的大小在类加载完成后便可完全确定。对于给对象分配内存，作者讲解了两种方式。

• 指针碰撞：假设Java堆中内存是绝对规整的，所有内存都放在一遍，空闲的内存放在另一边，中间放一个指针作为分解点的指示器，那所分配内存仅仅是把那个指针向空闲空间那边挪一段与对象大小相等的距离。
• 空闲列表：因为堆内存在物理上是不连续的，而在逻辑上是连续的。当虚拟机在给对象在堆中分配内存时，会出现图2.3的状况。为了让对象能够在堆中能分到内存，虚拟机必须维护一个列表，记录上哪些内存块是可以用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。

选择哪种分配方式，由Java堆是否规整决定，而Java堆是否规整由垃圾收集器是否带有压缩整理功能决定。对象创建在虚拟机中是非常频繁的行为，在并发的情况下，很可能线程正在创建A对象，还没来的及修改指针位置，对象B又用了原来的指针来分配内存。这种情况下有两种解决方案：

• 用CAS操作；
• 用TLAB，第二种就是把内存分配的动作按照流程划分不同的空间之中进行，即每个线程在Java堆中预定一块内存（这不就占座吗），哪个线程要分配线程，就在那个线程的TLAB上分配。可以设置参数-XX:+UserTLAB参数来设定（使用），-XX:-UserTLAB（禁用）

内存分分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头），如果使用TLAB，这一工作可以提前至TLAB分配时进行。这一步操作保证的对象的实例字段在Java代码中可以不不赋初始值就直接使用，程序可以访问到这些字段的对应的零值（null、0）。

图2.3 Java堆中内存图

2.2.2 对象的布局

在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头、实例数据、对齐填充。

• 对象头：
  1. MarkWord：用于存储对象自身的运行时数据。根据你使用的计算机是32bit还是64bit，这里以32bit举例。就是32个0和1，前面25bit是对象的哈希码，4bit存年龄，1bit是否是偏向锁，2bit锁标记位；运行时又不一样了，百度一下
  2. 类型指针： 即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，也就 是，查找对象的元数据信息并不一定要经过对象本身。另外，如果对象是Java数组，那在对象头中必须还有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定对象的大小，但是从数组的元数据中无法确定数组的大小。

• 实例数据：　　

对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容。无论是父类继承下来的，还是子类中定义的，都要记录下来。HotSpot虚拟机默认的分配策略是相同宽度的字段分配到一起（longs/doubles、shorts/chars.....为什么记long占8个字节/double占8字节，char占2字节...）。满足这个前提下，在父类 中定义的变量会出现在子类之前。如果CompactFields参数值为true，那么子类中较窄的变量也可能会插入到父类变量的空隙中。

• 对齐填充：

并不是必然存在的，没有特别含义，仅仅是起着站位符的作用，由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，就是对象的大小必须是8字节整数倍。而对象头部分正好是8字节的倍数（1或2倍），so，当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。

2.2.3 对象的访问定位

Java程序需要通过站上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用怎么来实现，不同  虚拟机有不同实现，目前主流的访问方式有两种，句柄和直接指针。

• 句柄：使用句柄（Handle）访问，在Java堆中会划分一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息，如图2.4。

图 2.4 通过句柄访问对象

• 　  指针：使用指针，Java堆对象的布局就必须考虑如何防止访问类型数据的相关信息，而reference中存储的直接就是对象地址，如图2.5所示。

2.5  通过直接指针访问对象

　　HotSpot采用第二种方式实现。