本篇如果没有特殊说明，都是针对的是HotSpot虚拟机。
对于java程序员来说，在虚拟机自动内存管理机制下，不再需要像C/C++语言的程序员这样为每一个new操作去写对应的delete/free操作，不容易出现内存泄漏和内存溢出问题。正式因为java程序员把内存控制权利交给java虚拟机，一旦出现内存泄漏和溢出方面的问题，如果不了解虚拟机是怎样使用内存的，那么排查错误将会是一个非常艰巨的任务。
运行时数据区域
java虚拟机在执行java程序的过程中会把它管理的内存划分成若干个不同的数据区域。jdk1.8和之前的版本有较大的不同。下面会介绍到。
JDK1.8之前
JDK1.8
线程私有的：
- 程序计数器
- 虚拟机栈
- 本地方法栈
线程共享的：
- 堆
- 方法区
- 直接内存
java虚拟机规范对于运行时数据区域的规定是相当宽松的。以堆为例：堆可以是连续空间，也可以不连续。堆的大小可以固定，也可以在运行时按需扩展。虚拟机实现者可以使用任何垃圾回收算法管理堆，甚至完全不进行垃圾回收也是可以的。
程序计算器
程序计数器是一块比较小的内存空间，可以看做是当前线程所执行的字节码的行号指示器。字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令。分支，循环，跳转，异常处理，线程恢复等功能都需要以来这个计数器来完成。
另外为了线程切换后能恢复到正确的执行位置。每条线程都需要有一个独立的程序计数器。各个线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
从上面的介绍中我们知道了程序计数器主要有两个作用：
- 字节码解释器通过改变程序计数器来依次读取指令，从而实现代码的流程控制，如：顺序执行，选择，循环，异常处理。
- 在多线程的情况下，程序计数器用于记录当前线程的执行的位置。从而当线程被切换回来的时候能够知道该线程上次运行到哪儿了。
注意：程序计数器是唯一一个不会出现OOM的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。
java虚拟机栈
与程序计数器一样，java虚拟机也是线程私有的，它的生命周期和线程相同。随着线程的创建而创建，随着线程的死亡而死亡。
栈绝对算得上是JVM运行时数据区域的一个核心。除了一些native方法调用是通过本地方法栈实现的，其他所有的java方法调用都是通过栈来实现的。
方法调用的数据需要通过栈进行传递，每一次方法调用都会有一个对应的栈帧被压入栈中，每一个方法调用结束后，都会有一个栈帧被弹出。
栈由一个个栈帧组成，而每个栈帧中都拥有：局部变量表，操作数栈，动态链接，方法返回地址。和数据结构上的栈类似，两者都是先进后出的数据结构，只支持出栈和入栈两种操作。
栈
局部变量表：主要存放了编译期可知的各种数据类型，对象引用(reference类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置。)
操作数栈：主要作为方法调用的中转站使用，用于存放方法执行过程中产生的中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。
动态链接：主要服务一个方法需要调用其它方法的场景。在java源文件被编译成字节码文件时，所有的变量和方法引用都作为符号引用保存在class文件的常量池里。当一个方法要调用其它方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用。动态链接的作用就是为了将符号引用转换为调用方法的直接引用。
动态链接
栈空间虽然不是无限的，但是一般正常调用的情况下是不会出现问题的。不过，如果函数调用陷入无限循环的话，就会导致栈中被压入太多栈帧而占用太多空间，导致栈空间过深。那么当线程请求栈的深度超过当前java虚拟机栈的最大深度的时候，就抛出StackOverFlowError错误。
java方法有两种返回方式，一种是return语句正常返回。一种是抛出异常、不管哪种 返回方式，都会导致栈帧被弹出。也就是说栈帧随着方法调用而创建，随着方法结束而销毁。无论方法是正常完成还是异常完成都算做方法结束。
除了StackOverFlowError错误之外，栈还可能会出现OOM错误，这是因为如果栈的内存大小可以动态扩展，如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出OOM异常。
简单总结下程序运行时栈可能会出现的两个错误：
- StackOverFlowError:若栈的内存大小不允许动态扩展，那么当线程请求栈的深度超过当前java虚拟机栈的最大深度时，就会抛出StackOverFlowError错误。
- OutOfMemoryError:如果栈的内存大小可以动态扩展，如果虚拟机在动态扩展栈的时候无法申请到足够的内存空间，则抛出OOM异常。
本地方法栈
和虚拟机栈所发挥的作用非常相似，区别是：虚拟机栈为虚拟机执行java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的native方法服务。在HotSpot虚拟机中和java虚拟机栈合二为一。
本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放本地方法的局部变量表，操作数栈，动态链接，出口信息。
方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现StackOverFlowError和OutOfMemoryError两种错误。
堆
java虚拟机所管理的内存中最大的一块。java堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。
java世界中“几乎”所有的对象都在堆中分配，但是随着jit编译器的发展与逃逸分析技术逐渐成熟，栈上分配，标量替换优化技术将会导致一些微妙的变化。所有的对象都分配到堆上渐渐变得不那么绝对了。从jdk1.7开始已经默认开启逃逸分析。如果某些方法中的对象引用没有被返回或者未被外面使用(也就是未逃逸出去)，那么对象可以直接在栈上分配内存。
java对是垃圾收集器管理的主要区域。因此也被称作GC堆。从垃圾回收的角度。由于现在收集器基本都采用分代垃圾收集算法，所以java堆还可以细分为：新生代和老年代。再细致一点有：Eden,Survivor,Old等空间。进一步划分的目的是为了更好的回收内存。或者更快的分配内存。
在JDK7版本以及7版本之前，堆内存通常被分为下面三部分：
- 新生代内存
- 老年代
- 永久代
上面说的Eden和两个Survivor都属于新生代。如下图所示：
jdk1.7及其以前堆结构
JDK8版本之后永久代被元空间取代，元空间使用的是直接内存。如下图所示：
jdk1.8堆结构
大部分情况对象都会首先在Eden区域分配。再一次新生代垃圾回收后如果对象还存活，则会进入S0或者S1.并且对象的年龄+1.当它的年龄增加到一定程度(默认15)就会被晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold来设置。
ps：这里有一个需要注意的点：Hotspot有个机制：遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过survivor区的一半的时候，取这个年龄和MaxTenuringThreshold中更小的一个值，作为新的晋升年龄阈值。
动态计算年龄的代码如下：
uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
//survivor_capacity是survivor空间的大小
size_t desired_survivor_size = (size_t)((((double) survivor_capacity)*TargetSurvivorRatio)/100);
size_t total = 0;
uint age = 1;
while (age < table_size) {
total += sizes[age];//sizes数组是每个年龄段对象大小
if (total > desired_survivor_size) break;
age++;
}
uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;
...
}
堆里很容易出现OOM错误，并且还会有几种表现形式，比如：
- java.lang.OutOfMemoryError: GC Overhead Limit Exceeded： 当JVM花费太多的时间执行垃圾回收并且只能回收很少的堆空间，就会发生此错误。
- java.lang.OutOfMemoryError: Java heap space：假如在创建新的对象时，堆内存中的空间不足以存放新创建的对象就会引发此错误。(和配置的最大堆内存有关，且受制于物理内存的大小)
方法区
方法区属于是JVM运行时数据区域的一块逻辑区域。是各个线程共享的内存区域。
《java虚拟机规范》只规定了有方法区这么个概念和它的作用，方法区到底如何实现就是虚拟机自己要考虑的事了，也就是说不通的虚拟机，方法区的实现是不同的。
当虚拟机要使用一个类时，他需要读取并解析class文件获取相关信息。再将信息存入到方法区。方法区会存储已经被虚拟机加载的类信息，字段信息，方法信息，常量，静态变量，即时编译器编译后的代码缓存等数据。
方法区和永久代以及元空间是什么关系呢？方法区和永久代已经元空间的关系很像java中接口和类的关系，类实现了接口，这里的类就可以看做是永久代和元空间。接口可以看做是方法区。也就是说永久代以及元空间是HotSpot虚拟机对虚拟机规范中方法区的两种实现方式。并且永久代是1.8之前的方法区的实现。元空间是1.8之后的方法区的实现。
方法区，永久代，元空间关系
为什么要将永久代换成元空间呢？
- 整个永久代有一个JVM本身设置的固定大小上限。无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍然可能溢出，但是相比原来出现的几率会更小。
元空间溢出会报错：java.lang.OutOfMemoryError:MetaSpace
可以使用-XX: MaxMetaspaceSize标志设置最大元空间大小，默认值为unlimited。这意味着它只受系统内存的限制。-XX: MaxMetaspaceSize调整标志定义元空间的初始大小如果未指定此标志，则Metaspace将根据运行时的应用程序需求动态的重新调整大小。
- 元空间里存放的是类的元数据，这样加载多少类的元数据就不由MaxPermSize控制了，而是由系统的实际可用空间来控制，这样就能加载更多的类了。
- 在JDK8，合并HotSpot和JRockit的代码时，JRockit从没有一个叫永久代的东西，合并之后也没必要额外设置这么一个永久代的地方了。
方法区常用参数有哪些？
JDK1.8之前永久代还没有被彻底移除的时候通常通过下面这些参数来调节方法区的大小。
-XX:PermSize = N //方法区(永久代)初始大小
-XX:MaxPermSize = N //方法区(永久代)最大大小，超过这个值会抛出OOM:PermGen
相对而言，垃圾收集行为在这个区域是比较少出现的，但是并非数据进入方法区后就永久存在了。
JDK1.8的时候方法区(HopSpot的永久代)被彻底移除了(JDK1.7开始)，取而代之的是元空间，元空间使用的是直接内存，下面是一些常用参数：
-XX:MetaspaceSize = N //设置Metaspace的初始(和最小大小)
-XX:MaxMetaspaceSize =N//设置Metaspace的最大大小
与永久代很大的不同就是。如果不指定大小的话，随着更多的类的创建，虚拟机会耗尽所有可用的系统内存。
运行时常量池
Class文件中除了有类的版本，字段，方法，接口等描述信息外。还有用于存放编译器生成的各种字面量和符号引用的常量池表。
字面量是源代码中的固定值的表示法，即通过字面我们就能知道其值得含义。字面量包括整数，浮点数和字符串字面量，符号引用包括类符号引用，字段符号引用，方法符号引用和接口方法符号引用。
常量池表会在类加载后存放到方法区的运行时常量池中。
运行时常量池的功能类似于传统编程语言的符号表，尽管它包含了比典型符号表更广泛的数据。
既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出OOM错误。
字符串常量池
字符串常量池是JVM为了提升性能和减少内存消耗针对字符串专门开辟的一块区域。主要目的是为了避免字符串的重复创建。
// 在堆中创建字符串对象”ab“
// 将字符串对象”ab“的引用保存在字符串常量池中
String aa = "ab";
// 直接返回字符串常量池中字符串对象”ab“的引用
String bb = "ab";
System.out.println(aa==bb);// true
HoSpot虚拟机中字符串常量池的实现是src/hotspot/share/classfile/stringTable.cpp。StringTable本质上就是一个HashSet<String>,容量为StringTableSize(可以通过-XX：StringTableSize参数来设置)。
StringTable中保存的是字符串对象的引用。字符串对象的引用指向堆中的字符串对象。
JDK1.7之前，字符串常量池存放在永久代，JDK1.7字符串常量池和静态变量从永久代移动到了java堆中。
JDK1.6
JDK1.7
JDK1.8
JDK1.7为什么要将字符串常量池移动到堆中？
主要是因为永久代(方法区的实现)的GC回收效率太低只有在整堆收集(Full GC)的时候才会被执行GC，java程序中通常会有大量的被创建的字符串等待回收。将字符串常量池放到堆中，能够更高效及时的回收字符串内存。
运行时常量池，方法区，字符串常量池这些都是不随虚拟机实现而改变的逻辑概念。是公共且抽象的，Metaspace，Heap是与具体某种虚拟机实现相关的物理概念。是私有且具体的。
直接内存
直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域。但是这部分内存也被频繁的使用，而且也可能导致OOM错误出现。
JDK1.4中加入的NIO(New Input/Output)类，引入了一种基于通道(Channel)与缓存区的I/O方式，它可以直接使用Native函数库直接分配堆外内存，然后通过存储一个在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样就能在一些场景中显著提高性能。因为避免了在java堆和Native堆之间来回复制数据。
本机直接内存的分配不会受到java堆的限制。但是既然是内存就会收到本级总内存大小以及处理器寻址空间的限制。
HotSpot虚拟机对象探秘
通过上面的介绍我们大概知道了虚拟机的内存情况，下面我们来详细的了解一下HotSpot虚拟机在java堆中对象分配，布局和访问的全过程。
java对象的创建过程：
1. 类加载检查
虚拟机遇到一条new指令时，首先将去检查这个指令的参数是否在常量池中定位到这个类的符号引用。并检查这个符号引用代表的类是否已被加载过，解析和初始化过。如果没有， 那必须先执行相应的类加载过程。
2. 分配内存
在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需的内存大小在类加载完成后便可确定。为对象分配空间的任务等同于把一块确定大小的内存从java堆中划分出来。分配方式有指针碰撞和空闲列表两种，选择哪种分配方式由java堆是否规整决定。而java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定的。
内存分配的两种方式:
-
指针碰撞：
- 适用场景：堆内存规整(没有内存碎片)的情况下。
- 原理：用过的内存全部整合到一边，没有用过的内存放在另一边，中间有一个分界指针，只需要向着没用过的内存方向将该指针移动对象内存大小位置即可。
- 使用该分配方式的GC收集器：Serial,ParNew
-
空闲列表：
- 适用场合：堆内存不规整的情况下。
- 原理：虚拟机会维护一个列表，该列表中会记录哪些内存块是可用的。在分配的时候，找一块足够大的内存块来划分给对象实例，最后更新列表记录。
- 使用该分配方式的GC收集器：CMS
选择以上两种方式中的哪一种，取决于java堆内存是否规整。而java堆内存是否规整取决于GC收集器的算法是标记-清除还是标记-整理。值得注意的是，复制算法内存也是规整的。
内存分配并发问题
在创建对象的时候，有一个很重要的问题，就是线程安全。因为在实际开发过程中，创建对象是很频繁的实情。作为虚拟机来说，必须要保证线程是安全的。通常来讲，虚拟机采用两种方式来保证线程安全：
- CAS+失败重试：CAS是乐观锁的一种实现。所谓乐观锁就是每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。虚拟机采用CAS配上失败重试的方式保证更新操作的原子性。
- TLAB：为每一个线程预先在Eden区分配一块内存，JVM在给线程中的对象分配内存时，首先在TLAB分配，当对象大于TLAB中的剩余内存或者TLAB的内存已经用尽时，再采用上述的CAS进行内存分配。
3. 初始化零值
内存分配完成后，虚拟机需要将分配到的内存空间都初始化成零值(不包括对象头)。这一步操作保证了对象的实例字段在java代码中可以不赋初始值就直接使用。程序能访问到这些字段的数据类型所对应的零值。
4. 设置对象头
初始化零值完成之后，虚拟机要对对象进行必要的设置，例如这个对象是哪个类的实例，如何才能找到类的元数据信息，对象的哈希码，对象的GC分代年龄信息。这些信息存放在对象头中。另外，根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。
5. 执行init方法
在上面的工作全部完成之后，从虚拟机的视角来看，一个新的对象已经产生了。但是从java程序的视角来看，对象创建才刚刚开始。init方法还没有执行，所有的字段都还是零，所以一般来说执行new指令之后会接着执行init方法，把对象按照程序员的意愿进行初始化，这样一个振中可用的对象才算完成产生出来。
对象的内存布局
在HotSpot虚拟机中，对象在内存中的布局分为三块区域：对象头，实例数据和对齐填充。
HotSpot虚拟机的对象头包括两部分信息：第一部分用于存储对象自身的运行时数据(哈希码，GC分代年龄，锁状态标志等)，另一部分是类型指针、即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
实例数据部分是对象真正存储的有效信息。也是在程序中所定义的各种类型的字段内容。
对齐填充部分不是必然存在的。也没有什么特别的含义，仅仅起占位作用。因为HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换说话说对象的大小必须是8字节的整数倍。而对象头部分正好是8字节的倍数(1倍或者2倍)，因此当对象实例数据部分没有对齐时，就需要通过对齐填充来补全。
对象的访问定位
建立对象就是为了使用对象。我们的java程序通过栈上的reference数据来操作堆上的具体对象。对象的访问方式由虚拟机实现而定。目前主流的访问方式有：使用句柄，直接指针。
句柄
如果使用句柄的话，那么java堆中会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。
句柄
直接指针
如果使用直接指针访问，那么java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象的地址。
直接指针
这两种对象访问方式各有优势，使用句柄来访问的最大好处是reference中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例指针，而reference本身不需要修改。使用直接指针访问方式最大的好处就是速度快，它节省了一次指针定位的时间开销。
本篇笔记就记到这里，如果稍微帮到你了记得点个喜欢点个关注。文章中都是很浅显和直接的东西，适合当八股文背。想要深入了解可以自己去查阅一些资料。也祝大家工作顺顺利利，每天进步哟~！
网友评论