JVM总结_java edon-CSDN博客

本文链接：https://blog.csdn.net/HC199854/article/details/114602085

JVM体系结构概览

在这里插入图片描述

灰色部分的区域都是线程私有，而且占的内存都很小；几乎不存在垃圾回收机制。
亮色部分的区域是所有线程共享的，而且存在垃圾回收。

类加载器ClassLoader

负责加载class文件，class文件在文件开头有特定的文件标示（用于识别是否是class文件），将class文件字节码内容加载到内存中，并将这些内容转换成方法区中的运行时数据结构并且ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。（简单说方法区就是存放模板的地方）

在这里插入图片描述

类的加载过程

当Java程序需要使用某个类时，如果该类还未被加载到内存中，JVM会通过加载、连接(验证、准备和解析)、初始化三个步骤来对该类进行初始化。

类的加载是指把类的.class文件中的数据读入到内存中，通常是创建一个字节数组读入.class文件，然后产生与所加载类对应的Class对象。加载完成后，Class对象还不完整，所以此时的类还不可用。当类被加载后就进入连接阶段，这一阶段包括验证、准备(为静态变量分配内存并设置默认的初始值)和解析(将符号引用替换为直接引用)三个步骤。最后JVM对类进行初始化，包括：

如果类存在直接的父类并且这个类还没有被初始化，那么就先初始化父类;
如果类中存在初始化语句，就依次执行这些初始化语句。

类加载器的分类：

类加载可以分为两大类，分别是虚拟机自带的加载器和用户自定义加载器

虚拟机自带的加载器

启动类加载器(Bootstrap）C++
负责加载JDK中的核心类库
扩展类加载器（Extension）Java
负责加载Java的扩展类库,默认加载JAVA_HOME/jre/lib/ext/目录下的所有jar包或者由java.ext.dirs系统属性指定的jar包
应用程序类加载器（AppClassLoader）Java也叫系统类加载器，加载当前应用的classpath的所有类

用户自定义加载器

Java.lang.ClassLoader的子类，用户可以定制类的加载方式。

在这里插入图片描述

双亲委派机制：

当一个类加载器收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中，只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的Class），子类加载器才会尝试自己加载。
采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。

Native lnterface（本地接口）

本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C+t程序，Java诞生的时候是C/C++横行的时候，要想立足，必须有调用C/C++程序，于是就在内存中专门开辟了一块区域处理标记为native的代码，它的具体做法是Native Method Stack中登记native方法，在Execution Engine执行时加载native libraies.
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间的通信很发达，比如可以使用Socket通信，也可以使用Web Service等等，不多做介绍。

PC寄存器

每个线程都有一个程序计数器，是线程私有的，就是一个指针，指向方法区中的方法字节码（用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
这块内存区域很小，它是当前线程所执行的字节码的行号指示器，字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令。
如果执行的是一个Native方法，那这个计数器是空的。
用以完成分支、循环、跳转、异常处理、线程恢复等基础功能。不会发生内存溢出(OutOfMemory=OOM)错误。

Method Area（方法区）

供各线程共享的运行时内存区域。它存储了每一个类的结构信息（模板），例如运行时常量池（Runtime Constant Pool）、字段和方法数据、构造函数和普通方法的字节码内容。上面讲的是规范，在不同虚拟机里头实现是不一样的，最典型的就是永久代(PermGen space)和元空间(Metaspace)。
但是 实例变量存在堆内存中,和方法区无关。

Stack（栈）

栈管运行，堆管存储。

栈也叫栈内存，主管Java程序的运行，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束该栈就Over，生命周期和线程一致，是线程私有的。8种基本类型的变量+对象的引用变量+实例方法都是在函数的栈内存中分配。

栈帧（方法）中主要保存3类数据:

本地变量(Local Variables）:输入参数和输出参数（返回值）以及方法内的变量；
栈操作（Operand Stack）:记录出栈、入栈的操作；
栈帧数据（Frame Data）:包括类文件、方法等等。

栈运行原理:

栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧F1，并被压入到栈中，A方法又调用了B方法，于是产生栈帧F2也被压入栈，B方法又调用了C方法，于是产生栈帧F3也被压入栈，执行完毕后，先弹出F3栈帧，再弹出F2栈帧，再弹出F1栈帧……
遵循“先进后出”，“后进先出”原则。

每个方法执行的同时都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接、方法出口等信息，每一个方法从调用直至执行完毕的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。栈的大小和具体JVM的实现有关，通常在256K~756K之间，约等于1Mb左右。

在这里插入图片描述
图示在一个栈中有两个栈帧:

栈帧2是最先被调用的方法，先入栈，

然后方法2又调用了方法1，栈帧1处于栈顶的位置，

栈帧2处于栈底，执行完毕后，依次弹出栈帧1和栈帧2，

线程结束，栈释放。

每执行一个方法都会产生一个栈帧，保存到栈(后进先出)的顶部，顶部栈就是当前的方法，该方法执行完毕后会自动将此栈帧出栈。

Heap（堆）

java7之前：
一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。

堆内存逻辑上分为三部分：新生+养老+永久
堆内存物理上分为三部分：新生+养老

在这里插入图片描述
Java8：永久区变成元空间

新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分：伊甸区(Eden space）和幸存者区(Survivor pace），所有的类都是在伊甸区被new出来的。幸存区有两个:0区（Survivor 0 space）和1区(Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存0区。若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢?再移动到养老区。若养老区也满了，那么这个时候将产生MaiorGC(Full GC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常”OutOfMemoryErroro“。Full GC不成功就会产生OOM。

伊甸区满了，开启轻GC（Minor GC）
养老区满了，开启Full GC

如果出现java.lang.QutOfMemoryError:Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：

Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在引用）

各区的内存占比情况：
在这里插入图片描述

幸存0区和幸存1区，他们的位置和名分，不是固定的，每次GC后会交换
GC之后有交换，谁空谁是幸存1区
每次MinorGC都会把Eden区清空

MinorGC的过程（复制->清空->互换）

eden、SurvixorFrom复制到Survivorlo，年龄+1
首先，当Eden区满的时候会触发第一次GC,把还活着的对象拷贝到SurviorFrom区，当Eden区再次触发GC的时候会扫描Eden区和From区域,对这两个区域进行垃圾回收，经过这次回收后还存活的对象,则直接复制到To区域（如果有对象的年龄已经达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1
清空eden、SurvivorFrom
然后，清空Eden和SurvivdFrom中的对象，也即复制之后有交换，谁空谁是to
SurvivorTo和SurvivorFrom互换
最后，SurvivorTo和SurvivorFrom互换，原SurvivorTo成为下一次GC时的SurvivorFrom区。部分对象会在From和To区域中复制来复制去,如此交换15次(由JVM参数MaxTenuringThreshold决定,这个参数默认是15),最终如果还是存活,就存入到老年代

永久区(java7之前有)

永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class,Interface的元数据，也就是说它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存。

实际而言，方法区(Method Area）和堆一样，是各个线程共享的内存区域，它用于存储虚拟机加载的:类信息+普通常量+静态常量+编译器编译后的代码等等，虽然JVM规范将方法区描述为堆的一个逻辑部分，但它却还有一个别名叫做Non-Heap(非堆)，目的就是要和堆分开。
对于HotSpot虚拟机，很多开发者习惯将方法区称之为“永久代(Parmanent Gen)”，但严格本质上说两者不同，或者说使用永久代来实现方法区而已，永久代是方法区(相当于是一个接口interface)的一个实现，jdk1.7的版本中，已经将原本放在永久代的字符串常量池移走。
也就是说永久代（包括元空间）也是方法区，只是这个方法区只存储JDK自身所携带的Class,Interface的元数据。
永久代和元空间是同一种东西的不同实现而已。

堆、栈、方法区的相互关系

在这里插入图片描述
HotSpot（默认的JDK）是使用指针的方式来访问对象；Java堆中会存放访问类元数据（模板）的地址，reference存储的就直接是对象的地址。

堆参数调整

Java7
在这里插入图片描述

Java8

在这里插入图片描述

在Java8中，永久代已经被移除，被一个称为元空间的区域所取代；元空间的本质和永久代类似。
元空间与永久代之间最大的区别在于：
永久带使用的JVM的堆内存，但是java8以后的元空间并不在虚拟机中而是使用本机物理内存。
因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入native memory,字符串池和类的静态变量放入java堆中，这样可以加载多少类的元数据就不再由MaxPermSize控制,而由系统的实际可用空间来控制。

参数介绍：
在这里插入图片描述
在工作中，-Xms和-Xmx都设置成一样，防止内存峰值忽高忽低。

GC日志参数解析：
在这里插入图片描述
Full GC日志参数解析：

GC四大算法

GC是什么（分代收集算法）：

次数上频繁收集Young区
次数上较少收集Old区
基本不动元空间

GC算法的总体概述

在这里插入图片描述

JVM在进行GC时，并非每次都对上面三个内存区域一起回收的，大部分时候回收的都是指新生代。
因此GC按照回收的区域又分了两种类型，一种是普通GC(minor GC)，一种是全局GC(major GC or Full GC)

Minor GC和Full GC的区别：

普通GC (minor GC)：只针对新生代区域的GC,指发生在新生代的垃圾收集动作，因为大多数Java对象存活率都不高，所以Minor GC非常频繁，一般回收速度也比较快。
全局GC(major GC or Full GC)：指发生在老年代的垃圾收集动作，出现了Major GC，经常会伴随至少一次的Minor GC(但并不是绝对的）。Full GC的速度一般要比普通GC慢上10倍以上。（老年区占的内存比新生区大是原因之一）

1.引用计数法

在这里插入图片描述
缺点：

每次对对象赋值时均要维护引用计数器，且计数器本身也有一定的消耗；
较难处理循环引用

JVM的实现一般不采用这种方式

2.复制算法(Copying)

年轻代中使用的是Minor Gc，这种Gc算法采用的是复制算法。

算法过程：

Minor GC会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移到Oldgeneration中，也即一旦收集后，Eden是就变成空的了。

当对象在 Eden (包括一个 Survivor区域，这里假设是 from区域）出生后，在经过一次Minor GC后，如果对象还存活，并且能够被另外一块 Survivor区域所容纳(上面已经假设为 from区域，这里应为to区域，即 to区域有足够的内存空间来存储Eden和from区域中存活的对象)，则使用复制算法将这些仍然还存活的对象复制到另外一块Survivor区域(即to区域）中，然后清理所使用过的Eden 以及Survivor区域(即 from区域)，并且将这些对象的年龄设置为1，以后对象在Survivor区每熬过一次MinorGC，就将对象的年龄＋1，当对象的年龄达到某个值时（默认是15岁，通过-XX:MaxTenuringThreshold来设定参数)，这些对象就会成为老年代。

HotSpot JVM把年轻代分为了三部分:1个Eden区和2个Survivor区（分别叫from和to)。默认比例为8:1:1,一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(90%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。

在这里插入图片描述

在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
在这里插入图片描述
因为Eden区对象一般存活率较低，一般的，使用两块10%的内存作为空闲和活动区间，而另外80%的内存，则是用来给新建对象分配内存的。一旦发生GC，将10%的from活动区间与另外80%中存活的eden对象转移到10%的to空闲区间，接下来，将之前90%的内存全部释放，以此类推。

优点：

复制算法不会产生内存碎片。

缺点：

它浪费了一半的内存，这太要命了。
如果对象的存活率很高，我们可以极端一点，假设是100%存活，那么我们需要将所有对象都复制一遍，并将所有引用地址重置一遍。复制这一工作所花费的时间，在对象存活率达到一定程度时，将会变的不可忽视。所以从以上描述不难看出，复制算法要想使用，最起码对象的存活率要非常低才行，而且最重要的是，我们必须要克服50%内存的浪费。)

3.标记清除(Mark-Sweep)

老年代一般是由标记清除或者是标记清除与标记整理的混合实现。

算法分成标记和清除两个阶段，先标记出要回收的对象，然后统一回收这些对象。形如：

在这里插入图片描述
用通俗的话解释一下标记清除算法，就是当程序运行期间，若可以使用的内存被耗尽的时候，GC线程就会被触发并将程序暂停，随后将要回收的对象标记一遍，最终统一回收这些对象，完成标记清理工作接下来便让应用程序恢复运行。

优点：

不需要额外的空间

缺点：

两次扫描，耗时严重
会产生内存碎片

首先，它的缺点就是效率比较低（递归与全堆对象遍历)，而且在进行GC的时候，需要停止应用程序，这会导致用户体验非常差劲。
其次，主要的缺点则是这种方式清理出来的空闲内存是不连续的，这点不难理解，我们的死亡对象都是随即的出现在内存的各个角落的，现在把它们清除之后，内存的布局自然会乱七八糟。而为了应付这一点，JVM就不得不维持一个内存的空闲列表，这又是一种开销。而且在分配数组对象的时候，寻找连续的内存空间会不太好找。

4.标记压缩(Mark-Compact)

原理：
在这里插入图片描述

在整理压缩阶段，不再对标记的对像做回收，而是通过所有存活对像都向一端移动，然后直接清除边界以外的内存。可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

优点：
标记压缩算法不仅可以弥补标记清除算法当中，内存区域分散的缺点，也消除了复制算法当中，内存减半的高额代价。

缺点：
从效率上来说，标记/整理算法要低于复制算法。标记/整理算法唯一的缺点就是效率也不高，不仅要标记所有存活对象，还要整理所有存活对象的引用地址。

标记-清除-压缩(Mark-Sweep-Compact)算法

标记-清除-压缩算法是不属于四大算法，但在工作中常见。

原理∶

标记清除算法和标记压缩算法的结合。
和标记清除算法一致，当进行多次GC后才压缩。

GC算法总结

内存效率：

复制算法>标记清除算法>标记整理算法（此处的效率只是简单的对比时间复杂度，实际情况不一定如此)。

内存整齐度：

复制算法=标记整理算法>标记清除算法。

内存利用率：

标记整理算法=标记清除算法>复制算法。

可以看出，效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存，而为了尽量兼顾上面所提到的三个指标，标记整理（压缩）算法相对来说更平滑一些，但效率上依然不尽如人意，它比复制算法多了一个标记的阶段，又比标记清除多了一个整理内存的过程。

没有最好的算法，只有最合适的算法。==========>分代收集算法。

根据不同区域的情况进行选择算法

年轻代(Young Gen)：

年轻代特点是区域相对老年代较小，对像存活率低。
这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对像大小有关，因而很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。

老年代(Tenure Gen)：

老年代的特点是区域较大，对像存活率高。
这种情况，存在大量存活率高的对像，复制算法明显变得不合适。一般是由标记清除或者是标记清除与标记整理的混合实现。

怎样判断对象可以回收

垃圾收集器对堆进行回收前，首先需要确定哪些对象还"活着"，哪些对象已经"死去"。

常用两种算法分析对象是否存活: 引用计数算法和可达性分析算法。

1、引用计数算法

算法思路:
1）给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值加1；

2）当引用失效时，计数器值就减1；

3）任何时刻计数器为0的对象就是不可能再被使用的；

算法优点：
实现简单，判定效率高；

算法缺点：
很难解决对象之间相互循环引用的问题。所以主流的虚拟机里没有选用引用计数算法来管理内存的。
关于循环引用的例子，比如对象objA和objB都有字段instance，赋值令objA.instance = objB，
objB.instance = objA，除此之外对象再无任何引用，实际上两个对象已经不可能再被访问，
但是他们因为相互引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收它们。

2、可达性分析算法

算法思路：
通过一系列的称为"GC Roots"的对象作为起始点，从这些节点开始往下搜索，搜索所有走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
在这里插入图片描述

蓝色部分为仍然存活的对象，白色部分判定可回收的对象。

在Java语言中，可作为GC Roots的对象包含以下几种：

虚拟机栈(栈帧中的本地变量表)中引用的对象。(可以理解为：引用栈帧中的本地变量表的所有对象)
方法区中静态属性引用的对象(可以理解为：引用方法区该静态属性的所有对象)
方法区中常量引用的对象(可以理解为：引用方法区中常量的所有对象)
本地方法栈中(Native方法)引用的对象(可以理解为：引用Native方法的所有对象)

垃圾回收器有哪些

四种主要收集器：

串行垃圾回收器(Serial)
它为单线程环境设计并且只使用一个线程进行垃圾回收，会暂停所有的用户线程。所以不适合服务器环境
并行垃圾回收器(Parallel)
多个垃圾回收线程并行工作，此时用户线程是暂停的，适用于科学计算/大数据处理等弱交互场景
并发垃圾回收器(CMS)
用户线程和垃圾收集线程同时执行(不一定是并行，可能交替执行），不需要停顿用户线程
G1垃圾回收器
G1垃圾回收器将堆内存分割成不同的区域然后并发的对其进行垃圾回收

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。它而非常符合在注重用户体验的应用上使用。

CMS(Concurrent Mark Sweep)收集器是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程(基本上)同时工作。

从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

初始标记：暂停所有的其他线程，并记录下直接与root相连的对象，速度很快；
并发标记：同时开启GC和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
并发清除：开启用户线程，同时GC线程开始对为标记的区域做清扫。

G1收集器

G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征.

被视为JDK1.7中HotSpot虚拟机的一个重要进化特征。它具备一下特点：

并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU(CPU或者CPU核心)来缩短Stop-The-World停顿时间。部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。

分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。

空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器；从局部上来看是基于“复制”算法实现的。

可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内。

G1收集器的运作大致分为以下几个步骤：

初始标记
并发标记
最终标记
筛选回收

G1收集器的特点：
在这里插入图片描述

JMM（Java内存模型）

JMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。

由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间，最大的工作内存就是main线程的)，工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程如下图：
在这里插入图片描述

JMM关于同步的规定：

线程解锁前，必须把共享变量的值刷新回主内存。
线程加锁前，必须读取主内存的最新值到自己的工作内存。
加锁解锁是同一把锁。

JMM的特性：

原子性：指一个操作是不可中断的，即使是多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰；比如，对于一个静态全局变量int i，两个线程同时对它赋值，线程A 给他赋值 1，线程 B 给它赋值为 -1,。那么不管这两个线程以何种方式，何种步调工作，i的值要么是1，要么是-1，线程A和线程B之间是没有干扰的。这就是原子性的一个特点，不可被中断
可见性：指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道这个修改。显然，对于串行程序来说，可见性问题是不存在。因为你在任何一个操作步骤中修改某个变量，那么在后续的步骤中，读取这个变量的值，一定是修改后的新值。但是这个问题在并行程序中就不见得了。如果一个线程修改了某一个全局变量，那么其他线程未必可以马上知道这个改动。
有序性：对于一个线程的执行代码而言，我们总是习惯地认为代码的执行时从先往后，依次执行的。这样的理解也不能说完全错误，因为就一个线程而言，确实会这样。但是在并发时，程序的执行可能就会出现乱序。给人直观的感觉就是：写在前面的代码，会先执行。有序性问题的原因是因为程序在执行时，可能会进行指令重排，重排后的指令与原指令的顺序未必一致。

指令重排：
指令重排是指在程序执行过程中, 为了性能考虑, 编译器和CPU可能会对指令重新排序。

强引用、软引用、弱引用、虚引用分别是什么?

整体结构：
在这里插入图片描述

强引用：
当内存不足,JVM开始垃圾回收,对于强引用的对象，就算是岀现了OOM也不会对该对象进行回收，死都不收。

强引用是我们最常见的普通对象引用,只要还有强引用指向一个对象,就能表明对象还“活着”,垃圾收集器不会碰这种对象。在Java中最常见的就是强引用,把一个对象赋给一个引用变量,这个引用变量就是一个强引用。当一个对象被强引用变量引用时,它处于可达状态,它是不可能被垃圾回收机制回收的，即使该对象以后永远都不会被用到JVM也不会回收。因此强引用是造成Java内存泄漏的主要原因之一。

对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为nul，一般认为就是可以被垃圾收集的了(当然具体回收时机还是要看垃圾收集策略)

软引用：
在这里插入图片描述