JVM-内存模型（jmm）和|JVM-内存模型（jmm）和 GC JVM-内存模型（jmm）和GC

1 CPU和内存的交互了解jvm内存模型前，了解下cpu和计算机内存的交互情况。【因为Java虚拟机内存模型定义的访问操作与计算机十分相似】
有篇很棒的文章，从cpu讲到内存模型: 什么是java内存模型
在计算机中，cpu和内存的交互最为频繁，相比内存，磁盘读写太慢，内存相当于高速的缓冲区。
但是随着cpu的发展，内存的读写速度也远远赶不上cpu。因此cpu厂商在每颗cpu上加上高速缓存，用于缓解这种情况。现在cpu和内存的交互大致如下。

文章图片
image cpu上加入了高速缓存这样做解决了处理器和内存的矛盾(一快一慢)，但是引来的新的问题 - 缓存一致性
在多核cpu中，每个处理器都有各自的高速缓存(L1,L2,L3)，而主内存确只有一个。
以我的pc为例,因为cpu成本高，缓存区一般也很小。

文章图片
image

CPU要读取一个数据时，首先从一级缓存中查找，如果没有找到再从二级缓存中查找，如果还是没有就从三级缓存或内存中查找，每个cpu有且只有一套自己的缓存。

如何保证多个处理器运算涉及到同一个内存区域时，多线程场景下会存在缓存一致性问题，那么运行时保证数据一致性？
为了解决这个问题，各个处理器需遵循一些协议保证一致性。【如MSI，MESI啥啥的协议。。】

大概如下

文章图片
image 在CPU层面，内存屏障提供了个充分必要条件
1.1.1 内存屏障(Memory Barrier)
CPU中，每个CPU又有多级缓存【上图统一定义为高速缓存】，一般分为L1,L2,L3，因为这些缓存的出现，提高了数据访问性能，避免每次都向内存索取，但是弊端也很明显，不能实时的和内存发生信息交换，分在不同CPU执行的不同线程对同一个变量的缓存值不同。

硬件层的内存屏障分为两种：Load Barrier 和 Store Barrier即读屏障和写屏障。【内存屏障是硬件层的】

为什么需要内存屏障

由于现代操作系统都是多处理器操作系统，每个处理器都会有自己的缓存，可能存在不同处理器缓存不一致的问题，而且由于操作系统可能存在重排序，导致读取到错误的数据，因此，操作系统提供了一些内存屏障以解决这种问题. 简单来说: 1.在不同CPU执行的不同线程对同一个变量的缓存值不同，为了解决这个问题。 2.用volatile可以解决上面的问题，不同硬件对内存屏障的实现方式不一样。java屏蔽掉这些差异，通过jvm生成内存屏障的指令。对于读屏障:在指令前插入读屏障，可以让高速缓存中的数据失效，强制从主内存取。

内存屏障的作用

cpu执行指令可能是无序的，它有两个比较重要的作用 1.阻止屏障两侧指令重排序 2.强制把写缓冲区/高速缓存中的脏数据等写回主内存，让缓存中相应的数据失效。

volatile型变量当我们声明某个变量为volatile修饰时，这个变量就有了线程可见性，volatile通过在读写操作前后添加内存屏障。
我看到有些文章说volatile可以用以下代码去理解

//相当于读写时加锁，保证及时可见性，并发时不被随意修改。 public class SynchronizedInteger { private long value; public synchronized int get() { return value; }public synchronized void set(long value) { this.value = https://www.it610.com/article/value; } }

这是不对的，因为这是两个特性，可见性与原子性是两个不同的特点，如果你用volatile去修饰一个变量，在多线程模式下可能得不到正确的值，比如i++，在1000个线程都去执行的情况下，就可能得到998这样结果。
volatile型变量拥有如下特性

可见性，对于一个该变量的读，一定能看到读之前最后的写入。防止指令重排序，执行代码时, 为了提高执行效率, 会在不影响最后结果的前提下对指令进行重新排序，使用volatile可以防止，比如单例模式双重校验锁的创建中有使用到，如(https://www.jianshu.com/p/b30a4d568be4)注意的是volatile不具有原子性，如i++这样的复合操作就可能会出现

至于volatile底层是怎么实现保证不同线程可见性的，这里涉及到的就是硬件上的，被volatile修饰的变量在进行写操作时，会生成一个特殊的汇编指令，该指令会触发mesi协议，会存在一个总线嗅探机制的东西，简单来说就是这个cpu会不停检测总线中该变量的变化，如果该变量一旦变化了，由于这个嗅探机制，其它cpu会立马将该变量的cpu缓存数据清空掉，重新的去从主内存拿到这个数据。简单画了个图。

文章图片
image 关于volatitle更多的详解，请参考：JVM 谈谈Volatile关键字？为什么不能保证原子性？用什么可以替代？为什么？
2. Java内存区域

前提:本文讲的基本都是以Sun HotSpot虚拟机为基础的，Oracle收购了Sun后目前得到了两个【Sun的HotSpot和JRockit(以后可能合并这两个),还有一个是IBM的IBMJVM】

之所以扯了那么多计算机内存模型，是因为java内存模型的设定符合了计算机的规范。
Java程序内存的分配是在JVM虚拟机内存分配机制下完成。
Java内存模型（Java Memory Model ,JMM）就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。

简要言之，jmm是jvm的一种规范，定义了jvm的内存模型。它屏蔽了各种硬件和操作系统的访问差异，不像c那样直接访问硬件内存，相对安全很多，它的主要目的是解决由于多线程通过共享内存进行通信时，存在的本地内存数据不一致、编译器会对代码指令重排序、处理器会对代码乱序执行等带来的问题。可以保证并发编程场景中的原子性、可见性和有序性。

从下面这张图可以看出来，Java数据区域分为五大数据区域。这些区域各有各的用途，创建及销毁时间。

其中方法区和堆是所有线程共享的，虚拟机栈，本地方法栈和程序计数器则为线程私有的。

根据java虚拟机规范，java虚拟机管理的内存将分为下面五大区域。

文章图片
image 2.1 五大内存区域
2.1.1 程序计数器

程序计数器是一块很小的内存空间，它是线程私有的，可以认作为当前线程的行号指示器。

为什么需要程序计数器

我们知道对于一个处理器(如果是多核cpu那就是一核)，在一个确定的时刻都只会执行一条线程中的指令，一条线程中有多个指令，为了线程切换可以恢复到正确执行位置，每个线程都需有独立的一个程序计数器，不同线程之间的程序计数器互不影响，独立存储。
注意：如果线程执行的是个java方法，那么计数器记录虚拟机字节码指令的地址。如果为native【底层方法】，那么计数器为空。这块内存区域是虚拟机规范中唯一没有OutOfMemoryError的区域。

2.1.2 Java栈（虚拟机栈）同计数器也为线程私有，生命周期与相同，就是我们平时说的栈，栈描述的是Java方法执行的内存模型。
每个方法被执行的时候都会创建一个栈帧用于存储局部变量表，操作栈，动态链接，方法出口等信息。每一个方法被调用的过程就对应一个栈帧在虚拟机栈中从入栈到出栈的过程。【栈先进后出，下图栈1先进最后出来】
对于栈帧的解释参考 Java虚拟机运行时栈帧结构

栈帧: 是用来存储数据和部分过程结果的数据结构。栈帧的位置:内存 -> 运行时数据区 -> 某个线程对应的虚拟机栈 -> here[在这里] 栈帧大小确定时间: 编译期确定，不受运行期数据影响。

通常有人将java内存区分为栈和堆，实际上java内存比这复杂，这么区分可能是因为我们最关注，与对象内存分配关系最密切的是这两个。
平时说的栈一般指局部变量表部分。

局部变量表:一片连续的内存空间，用来存放方法参数，以及方法内定义的局部变量，存放着编译期间已知的数据类型(八大基本类型和对象引用(reference类型),returnAddress类型。它的最小的局部变量表空间单位为Slot，虚拟机没有指明Slot的大小，但在jvm中，long和double类型数据明确规定为64位，这两个类型占2个Slot，其它基本类型固定占用1个Slot。
reference类型:与基本类型不同的是它不等同本身，即使是String，内部也是char数组组成，它可能是指向一个对象起始位置指针，也可能指向一个代表对象的句柄或其他与该对象有关的位置。
returnAddress类型:指向一条字节码指令的地址【深入理解Java虚拟机】怎么理解returnAddress

文章图片
image 需要注意的是，局部变量表所需要的内存空间在编译期完成分配，当进入一个方法时，这个方法在栈中需要分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表大小。

Java虚拟机栈可能出现两种类型的异常：

线程请求的栈深度大于虚拟机允许的栈深度，将抛出StackOverflowError。

虚拟机栈空间可以动态扩展，当动态扩展是无法申请到足够的空间时，抛出OutOfMemory异常。

2.1.3 本地方法栈 【JVM-内存模型（jmm）和|JVM-内存模型（jmm）和 GC】本地方法栈是与虚拟机栈发挥的作用十分相似,区别是虚拟机栈执行的是Java方法(也就是字节码)服务，而本地方法栈则为虚拟机使用到的native方法服务，可能底层调用的c或者c++,我们打开jdk安装目录可以看到也有很多用c编写的文件，可能就是native方法所调用的c代码。
2.1.4 堆对于大多数应用来说，堆是java虚拟机管理内存最大的一块内存区域，因为堆存放的对象是线程共享的，所以多线程的时候也需要同步机制。因此需要重点了解下。
java虚拟机规范对这块的描述是: 所有对象实例及数组都要在堆上分配内存，但随着JIT编译器的发展和逃逸分析技术的成熟，这个说法也不是那么绝对，但是大多数情况都是这样的。

即时编译器: 可以把把Java的字节码，包括需要被解释的指令的程序）转换成可以直接发送给处理器的指令的程序)
逃逸分析: 通过逃逸分析来决定某些实例或者变量是否要在堆中进行分配，如果开启了逃逸分析，即可将这些变量直接在栈上进行分配，而非堆上进行分配。这些变量的指针可以被全局所引用，或者其其它线程所引用。
参考逃逸分析

注意: 它是所有线程共享的，它的目的是存放对象实例。同时它也是GC所管理的主要区域，因此常被称为GC堆，又由于现在收集器常使用分代算法，Java堆中还可以细分为新生代和老年代，再细致点还有Eden(伊甸园)空间之类的不做深究。
根据虚拟机规范，Java堆可以存在物理上不连续的内存空间，就像磁盘空间只要逻辑是连续的即可。它的内存大小可以设为固定大小，也可以扩展。
当前主流的虚拟机如HotPot都能按扩展实现(通过设置 -Xmx和-Xms)，如果堆中没有内存内存完成实例分配，而且堆无法扩展将报OOM错误(OutOfMemoryError)

2.1.5 方法区方法区同堆一样，是所有线程共享的内存区域，为了区分堆，又被称为非堆。
用于存储已被虚拟机加载的类信息、常量、静态变量，如static修饰的变量加载类的时候就被加载到方法区中。

运行时常量池
是方法区的一部分，class文件除了有类的字段、接口、方法等描述信息之外，还有常量池用于存放编译期间生成的各种字面量和符号引用。

在老版jdk，方法区也被称为永久代【因为没有强制要求方法区必须实现垃圾回收，HotSpot虚拟机以永久代来实现方法区，从而JVM的垃圾收集器可以像管理堆区一样管理这部分区域，从而不需要专门为这部分设计垃圾回收机制。不过自从JDK7之后，Hotspot虚拟机便将运行时常量池从永久代移除了。】

jdk1.7开始逐步去永久代。从String.interns()方法可以看出来 String.interns() native方法: 作用是如果字符串常量池已经包含一个等于这个String对象的字符串，则返回代表池中的这个字符串的String对象，在jdk1.6及以前常量池分配在永久代中。可通过 -XX:PermSize和-XX:MaxPermSize限制方法区大小。

public class StringIntern { //运行如下代码探究运行时常量池的位置 public static void main(String[] args) throws Throwable { //用list保持着引用防止full gc回收常量池 List list = new ArrayList(); int i = 0; while(true){ list.add(String.valueOf(i++).intern()); } } } //如果在jdk1.6环境下运行同时限制方法区大小将报OOM后面跟着PermGen space说明方法区OOM，即常量池在永久代 //如果是jdk1.7或1.8环境下运行同时限制堆的大小将报heap space 即常量池在堆中

idea设置相关内存大小设置
这边不用全局的方式，设置main方法的vm参数。
做相关设置，比如说这边设定堆大小。（-Xmx5m -Xms5m -XX:-UseGCOverheadLimit）

这边如果不设置UseGCOverheadLimit将报java.lang.OutOfMemoryError: GC overhead limit exceeded，这个错是因为GC占用了多余98%（默认值）的CPU时间却只回收了少于2%（默认值）的堆空间。目的是为了让应用终止，给开发者机会去诊断问题。一般是应用程序在有限的内存上创建了大量的临时对象或者弱引用对象，从而导致该异常。虽然加大内存可以暂时解决这个问题，但是还是强烈建议去优化代码，后者更加有效，也可通过UseGCOverheadLimit避免[不推荐，这里是因为测试用，并不能解决根本问题]

文章图片
image

文章图片
image jdk8真正开始废弃永久代，而使用元空间(Metaspace)

java虚拟机对方法区比较宽松，除了跟堆一样可以不存在连续的内存空间，定义空间和可扩展空间，还可以选择不实现垃圾收集。

2.2 对象的内存布局在HotSpot虚拟机中。对象在内存中存储的布局分为

1.对象头 2.实例数据 3.对齐填充

2.2.1 对象头【markword】在32位系统下，对象头8字节，64位则是16个字节【未开启压缩指针，开启后12字节】。

markword很像网络协议报文头，划分为多个区间，并且会根据对象的状态复用自己的存储空间。为什么这么做:省空间，对象需要存储的数据很多，32bit/64bit是不够的，它被设计成非固定的数据结构以便在极小的空间存储更多的信息，

假设当前为32bit，在对象未被锁定情况下。25bit为存储对象的哈希码、4bit用于存储分代年龄，2bit用于存储锁标志位，1bit固定为0。

不同状态下存放数据

文章图片
image 这其中锁标识位需要特别关注下。锁标志位与是否为偏向锁对应到唯一的锁状态。
锁的状态分为四种无锁状态、偏向锁、轻量级锁和重量级锁
不同状态时对象头的区间含义，如图所示。

文章图片
image HotSpot底层通过markOop实现Mark Word，具体实现位于markOop.hpp文件。

markOop中提供了大量方法用于查看当前对象头的状态，以及更新对象头的数据，为synchronized锁的实现提供了基础。[比如说我们知道synchronized锁的是对象而不是代码，而锁的状态保存在对象头中，进而实现锁住对象]。

关于对象头和锁之间的转换，网上大神总结

文章图片
image 2.2.2 实例数据

存放对象程序中各种类型的字段类型，不管是从父类中继承下来的还是在子类中定义的。分配策略:相同宽度的字段总是放在一起，比如double和long

2.2.3 对齐填充这部分没有特殊的含义，仅仅起到占位符的作用满足JVM要求。

由于HotSpot规定对象的大小必须是8的整数倍，对象头刚好是整数倍，如果实例数据不是的话，就需要占位符对齐填充。

2.3 对象的访问定位 java程序需要通过引用(ref)数据来操作堆上面的对象，那么如何通过引用定位、访问到对象的具体位置。

对象的访问方式由虚拟机决定，java虚拟机提供两种主流的方式 1.句柄访问对象 2.直接指针访问对象。(Sun HotSpot使用这种方式)

参考Java对象访问定位
2.3.1 句柄访问

简单来说就是java堆划出一块内存作为句柄池,引用中存储对象的句柄地址,句柄中包含对象实例数据、类型数据的地址信息。
优点:引用中存储的是稳定的句柄地址,在对象被移动【垃圾收集时移动对象是常态】只需改变句柄中实例数据的指针，不需要改动引用【ref】本身。

文章图片
image 2.3.2 直接指针

与句柄访问不同的是，ref中直接存储的就是对象的实例数据,但是类型数据跟句柄访问方式一样。
优点:优势很明显，就是速度快，相比于句柄访问少了一次指针定位的开销时间。【可能是出于Java中对象的访问时十分频繁的,平时我们常用的JVM HotSpot采用此种方式】

文章图片
image 3. 内存溢出

两种内存溢出异常[注意内存溢出是error级别的] 1.StackOverFlowError:当请求的栈深度大于虚拟机所允许的最大深度 2.OutOfMemoryError:虚拟机在扩展栈时无法申请到足够的内存空间[一般都能设置扩大]

java -verbose:class -version 可以查看刚开始加载的类，可以发现这两个类并不是异常出现的时候才去加载，而是jvm启动的时候就已经加载。这么做的原因是在jvm启动过程中我们把类加载起来，并创建几个没有堆栈的对象缓存起来，只需要设置下不同的提示信息即可，当需要抛出特定类型的OutOfMemoryError异常的时候，就直接拿出缓存里的这几个对象就可以了。
比如说OutOfMemoryError对象，jvm预留出4个对象【固定常量】，这就为什么最多出现4次有堆栈的OutOfMemoryError异常及大部分情况下都将看到没有堆栈的OutOfMemoryError对象的原因。
参考OutOfMemoryError解读