JVM内存结构和内存模型是不一样的东西，内存结构是指 Jvm 运行时将数据分区域存储，强调对内存空间的划分。

而内存模型（Java Memory Model，简称 JMM ）是定义了线程和主内存之间的抽象关系，即 JMM 定义了 JVM 在计算机内存(RAM)中的工作方式，是虚拟机的内存管理模型，是一种虚拟机工程规范。

JVM 内存结构

JDK1.7以前的内存结构

JDK-1.7-以前的结构

JVM内存结构主要有三大块：堆、方法区和栈。

堆是JVM中最大的一块，由年轻代和老年代组成，而年轻代内存又被分成三部分，Eden空间、From Survivor空间、To Survivor空间，默认情况下年轻代的这3种空间年轻代按照8:1:1的比例来分配;

方法区存储类信息、常量、静态变量等数据，是线程共享的区域，为与Java堆区分，方法区还有一个别名Non-Heap(非堆);

栈又分为java虚拟机栈和本地方法栈主要用于方法的执行;

JDK1.8以后的内存结构

JDK-1.8-开始的结构

以前的方法区(或永久代)，用来存放class，Method等元数据信息，但在JDK1.8已经没有了，取而代之的是MetaSpace(元空间)，元空间不在虚拟机里面，而是直接使用本地内存。

为什么要用元空间代替永久代？

(1) 类以及方法的信息比较难确定其大小，因此对于永久代的指定比较困难，太小容易导致永久代溢出，太大容易导致老年代溢出。

(2) 永久代会给GC带来不需要的复杂度，并且回收效率偏低。

JVM架构概览

虚拟机运行架构

1. Java堆（Heap）

对于大多数应用来说，Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。

为什么“几乎所有的对象实例都在这里分配内存，而不是全部”？

随着JIT编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换导致了上面的现象。

标量替换

标量是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。相对的，那些还可以分解的数据叫做聚合量，Java中的对象就是聚合量，因为他可以分解成其他聚合量和标量。

在JIT阶段，如果经过逃逸分析，发现一个对象不会被外界访问的话，那么经过JIT优化，就会把这个对象拆解成若干个其中包含的若干个成员变量来代替，这个过程就是标量替换。

```java

public static void main(String[] args) {

  alloc();

}

private static void alloc() {

  Point point = new Point（1,2）;

  System.out.println("point.x="+point.x+"; point.y="+point.y);

}

class Point{

    private int x;

    private int y;

}```

以上代码中，point对象并没有逃逸出alloc方法，并且point对象是可以拆解成标量的。那么，JIT就会不会直接创建Point对象，而是直接使用两个标量int x ，int y来替代Point对象。

以上代码，经过标量替换后，就会变成：

private static void alloc() {

  int x = 1;

  int y = 2;

  System.out.println("point.x="+x+"; point.y="+y);

}

可以看到，Point这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个聚合量了。那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。

标量替换为栈上分配提供了很好的基础。

2.3栈上分配(为什么有对象不再堆上分配)

在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。在一般情况下，对象和数组元素的内存分配是在堆内存上进行的。但是随着JIT编译器的日渐成熟，很多优化使这种分配策略并不绝对。JIT编译器就可以在编译期间根据逃逸分析的结果，来决定是否可以将对象的内存分配从堆转化为栈。这样就无需在堆上分配内存，也无须进行垃圾回收了。

public static void main(String[] args) {

  long a1 = System.currentTimeMillis();

  for (int i = 0; i < 1000000; i++) {

      alloc();

  }

  // 查看执行时间

  long a2 = System.currentTimeMillis();

  System.out.println("cost " + (a2 - a1) + " ms");

  // 为了方便查看堆内存中对象个数，线程sleep

  try {

      Thread.sleep(100000);

  } catch (InterruptedException e1) {

      e1.printStackTrace();

  }

}

private static void alloc() {

  User user = new User();

}

static class User {

}

其实代码内容很简单，就是使用for循环，在代码中创建100万个User对象。

我们在alloc方法中定义了User对象，但是并没有在方法外部引用他。也就是说，这个对象并不会逃逸到alloc外部。经过JIT的逃逸分析之后，就可以对其内存分配进行优化。

我们指定以下JVM参数并运行：

-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

在程序打印出 cost XX ms 后，代码运行结束之前，我们使用[jmap][1]命令，来查看下当前堆内存中有多少个User对象：

➜  ~ jps

2809 StackAllocTest

2810 Jps

➜  ~ jmap -histo 2809

num    #instances        #bytes  class name

----------------------------------------------

  1:          524      87282184  [I

  2:      1000000      16000000  StackAllocTest$User

  3:          6806        2093136  [B

  4:          8006        1320872  [C

  5:          4188        100512  java.lang.String

  6:          581          66304  java.lang.Class

从上面的jmap执行结果中我们可以看到，堆中共创建了100万个StackAllocTest$User实例。

在关闭逃避分析的情况下（-XX:-DoEscapeAnalysis），虽然在alloc方法中创建的User对象并没有逃逸到方法外部，但是还是被分配在堆内存中。也就说，如果没有JIT编译器优化，没有逃逸分析技术，正常情况下就应该是这样的。即所有对象都分配到堆内存中。

接下来，我们开启逃逸分析，再来执行下以上代码。

-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError

在程序打印出 cost XX ms 后，代码运行结束之前，我们使用jmap命令，来查看下当前堆内存中有多少个User对象：

➜  ~ jps

709

2858 Launcher

2859 StackAllocTest

2860 Jps

➜  ~ jmap -histo 2859

num    #instances        #bytes  class name

----------------------------------------------

  1:          524      101944280  [I

  2:          6806        2093136  [B

  3:        83619        1337904  StackAllocTest$User

  4:          8006        1320872  [C

  5:          4188        100512  java.lang.String

  6:          581          66304  java.lang.Class

从以上打印结果中可以发现，开启了逃逸分析之后（-XX:+DoEscapeAnalysis），在堆内存中只有8万多个StackAllocTest$User对象。也就是说在经过JIT优化之后，堆内存中分配的对象数量，从100万降到了8万。

————————————————

版权声明：本文为CSDN博主「朽木1」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/qq_36685916/article/details/91161137

Java堆是垃圾收集器管理的主要区域，因此很多时候也被称做“GC堆”。如果从内存回收的角度看，由于现在收集器基本都是采用的分代收集算法，所以Java堆中还可以细分为：新生代和老年代；再细致一点的有Eden空间、From Survivor空间、To Survivor空间等。

根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。

如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。

2. 方法区（Method Area）

方法区

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，在 Java 虚拟机规范中是这样定义方法区的：它存储了每个类的结构信息，例如运行时常量池、字段、方法数据、构造函数和普通方法的字节码内容，还包括一些在类、实例、接口初始化时用到的特殊方法。

HotSpot虚拟机上把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。

Java虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。

根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

3.  程序计数器（Program Counter Register）

程序计数器

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

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

如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie方法，这个计数器值则为空（Undefined）。

此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

4.  JVM栈（JVM Stacks）

JVM线程栈帧

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

局部变量表存放了编译期可知的各种基本数据类型（boolean、byte、char、short、int、float、long、double）、对象引用（reference类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

操作数栈，和局部变量区一样，也被组织成一个以字长为单位的数组，但和前者不同的是，它不是通过索引来访问的，而是通过入栈和出栈来访问的，可把操作数栈理解为存储计算时，临时数据的存储区域。

除了局部变量区和操作数栈外，java栈帧还需要一些数据来支持常量池解析、正常方法返回以及异常派发机制。这些数据都保存在java栈帧的帧数据区中。

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

5.  本地方法栈（Native Method Stacks）

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

JVM 调参

image.png

jvm常用参数含义

-XX:+PrintGC/-verbose:gc打印GC的简要信息

-XX:+PrintGCDetails打印GC的详细信息

-XX:+PrintGCDateStamps打印GC发生的时间

-Xloggc:log/gc.log指定GC的log位置，以文件输出

-XX:+PrintHeapAtGC每一次GC后都打印堆信息

-XX:+HeapDumpOnOutOfMemoryError当JVM发生OOM时，自动生成DUMP文件

-XX:HeapDumpPath=${目录}生成的DUMP文件的存放位置

-Xms初始堆大小，默认是物理内存的1/64

-Xmx最大堆大小 默认是物理内存的1/4

-Xmn年轻代的大小，默认整个堆的3/8

-Xss设置每个线程的堆栈大小

-XX:MetaspaceSize初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值

-XX:MaxMetaspaceSize空间最大内存，默认是没有限制的

-XX:MaxDirectMemorySize限制堆外内存的使用

-XX:+DisableExplicitGC禁用 System.gc 显式FullGC

-XX:ReservedCodeCacheSize调整JIT编译代码缓存

-XX:PretenureSizeThreshold大于这个值的对象直接在老年代分配

-XX:+PrintGCApplicationConcurrentTime打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用。输出形式：Application time: 0.5291524 seconds

-XX:+PrintGCApplicationStoppedTime打印垃圾回收期间程序暂停的时间

JVM堆外内存

堆外内存就是把内存对象分配在Java虚拟机的堆以外的内存，这些内存直接受操作系统管理（而不是虚拟机），这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。

堆外内存主要包含：

Meta Space 元空间

Code Cache JIT编译代码缓存

JVM线程栈

Native方法栈

程序计数器

Class Compress Space 类压缩空间

作为JAVA开发者我们经常用java.nio.DirectByteBuffer对象进行堆外内存的管理和使用，它会在对象创建的时候就分配堆外内存。

java.nio.DirectByteBuffer对象在创建过程中会先通过Unsafe接口直接通过os::malloc来分配内存，然后将内存的起始地址和大小存到java.nio.DirectByteBuffer对象里，这样就可以直接操作这些内存。这些内存只有在DirectByteBuffer回收掉之后才有机会被回收，因此如果这些对象大部分都移到了old，但是一直没有触发CMS GC或者Full GC，那么悲剧将会发生，因为你的物理内存被他们耗尽了，因此为了避免这种悲剧的发生，通过-XX:MaxDirectMemorySize来指定最大的堆外内存大小，当使用达到了阈值的时候将调用System.gc来做一次full gc，以此来回收掉没有被使用的堆外内存

堆外内存的好处：

1、减少了垃圾回收，因为堆内存垃圾回收会Stop The World。

2、加快了复制的速度，堆内数据在flush到远程时，会先复制到直接内存（非堆内存），然后在发送，而堆外内存相当于省略掉了这个工作。

堆外内存的缺点：

1、堆外内存的缺点就是内存难以控制，使用了堆外内存就间接失去了JVM管理内存的可行性，改由自己来管理，当发生内存溢出时排查起来非常困难。

有许多单机缓存框架是用的堆外内存，比如EHCache。

Java内存模型(JMM)

Java的共享内存

线程内存模型

由上述对JVM内存结构的描述中，我们知道了堆和方法区是线程共享的。方法调用的局部变量就不会在线程之间共享，它们不会有内存可见性问题，也不受内存模型的影响。

CPU的处理速度和主存的读写速度不是一个量级的，为了平衡这种巨大的差距，每个CPU都会有缓存。共享变量会先放在主存中，每个线程都有属于自己的工作内存，并且会把位于主存中的共享变量拷贝到自己的工作内存，之后的读写操作均使用位于工作内存的变量副本，并在某个时刻将工作内存的变量副本写回到主存中去。

Java线程之间的通信由Java内存模型控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。

从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，它涵盖了各种CPU缓存、寄存器以及其他的硬件和编译器优化。

Java的重排序

ClassReordering{intx=0,y=0;publicvoidwriter(){x=1;y=2;}publicvoidreader(){intr1=y;intr2=x;}}

在执行程序时为了提高性能，编译器和处理器常常会对指令做重排序。

这里说的重排序可以发生在好几个地方：编译器、运行时、JIT等，比如编译器会觉得把一个变量的写操作放在最后会更有效率，编译后，这个指令就在最后了（前提是只要不改变程序的语义，编译器、执行器就可以这样自由的随意优化），一旦编译器对某个变量的写操作进行优化（放到最后），那么在执行之前，另一个线程将不会看到这个执行结果。

JMM 语义

由于Java共享内存以及Java重排序的存在，会导致多线程环境下存在操作可见性的问题。

为了方便程序员进行并发编程，Java定义了一些规则，这规则称为happens-before规则，从JDK 5 开始，JMM就使用happens-before的概念来阐述多线程编程时的操作可见性。

happends-before含义：cpu在某个时间片执行一个操作后，cpu按时间轮片到后续任意线程执行时，都能观察到这个操作的效果；

在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。

happens-before原则定义如下：

1、程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；

2、锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作；

3、volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；

4、传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C；

5、线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；

6、线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；

7、线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；

8、对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始；

JMM的底层实现

从java编程的角度来看，JMM是通过synchronize、volatile以及并发包里的锁来实现JMM语义；

volatile 实现原理

volatile通过插入内存屏障保证线程可见性和禁止重排序。

volatile可见性实现原理

从JVM编译器的字节码角度来看：

volatile在JVM编译时是采用“内存屏障”来实现的。观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令。lock前缀指令其实就相当于一个内存屏障。内存屏障是一组处理指令，用来实现对内存操作的顺序限制。

从操作系统角度看：

加了内存屏障的字节码在执行时，操作系统解决了缓存一致性；

操作系统解决缓存一致性方案有两种：

1、 通过在总线加LOCK的方式

2、通过缓存一致性协议

但是方案1存在一个问题，它是采用一种独占的方式来实现的，即总线加LOCK#锁的话，只能有一个CPU能够运行，其他CPU都得阻塞，效率较为低下。 第二种方案，缓存一致性协议（MESI协议）它确保每个缓存中使用的共享变量的副本是一致的。其核心思想如下：当某个CPU在写数据时，如果发现操作的变量是共享变量，则会通知其他CPU告知该变量的缓存行是无效的，因此其他CPU在读取该变量时，发现其无效会重新从主存中加载数据。

volatile 禁止重排序实现原理

从JVM编译器的字节码角度来看：

首先是插入内存屏障；其次会禁止一些特定类型的编译器重排序；

从操作系统的角度看：

处理器重排序，是指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序；

针对处理器重排序，编译器在生成指令序列的时候会通过插入内存屏障指令来禁止某些特殊的处理器重排序。

synchronize 实现原理

synchronize 比 volatile更重一些，映射到操作系统的底层原理基本一致，在JVM层级的实现会更复杂，synchronize的JVM实现做过很多优化，不仅保证可见性、有序性，还能保证代码块的原子性；

synchronize是通过java对象头的Mark区来辅助实现，分为无锁、偏向锁、轻量级锁（自旋）、重量级锁（系统调用）等状态；

image.png

ObjectMonitor(){_count=0;//用来记录该对象被线程获取锁的次数_waiters=0;_recursions=0;//锁的重入次数_owner=NULL;//指向持有ObjectMonitor对象的线程 _WaitSet=NULL;//处于wait状态的线程，会被加入到_WaitSet_WaitSetLock=0;_EntryList=NULL;//处于等待锁block状态的线程，会被加入到该列表}

JMM实现了更友好的并发编程

总的来说，在多线程开发时需要从原子性，有序性，可见性三个方面进行考虑；

as-if-serial与happens-before

as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结果不被改变。

as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。

happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按happens-before指定的顺序来执行的。

as-if-serial语义和happens-before这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

站在JMM设计者的角度，在设计JMM时需要考虑两个关键因素:

1、程序员对内存模型的使用

程序员希望内存模型易于理解、易于编程。

程序员希望基于一个强内存模型来编写代码。

2、编译器和处理器对内存模型的实现

编译器和处理器希望内存模型对它们的束缚越少越好，这样它们就可以做尽可能多的优化来提高性能。

编译器和处理器希望实现一个弱内存模型。

JMM其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。

例如，如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。再如，如果编译器经过细致的分析后，认定一个volatile变量只会被单个线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待。这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

image.png

一个happens-before规则对应于一个或多个编译器和处理器重排序规则。对于Java程序员来说，happens-before规则简单易懂，它避免Java程序员为了理解JMM提供的可见性保证而去学习复杂的重排序规则以及这些规则的具体实现方法。