栈、本地方法栈、程序计数器这三个部分都是线程独占的。
详解 JMM 内存可见性
JMM 是 Java 内存模型，与刚才讲到的 JVM 内存模型是两回事，JMM 的主要目标是定义程序中变量的访问规则，如下图所示，所有的共享变量都存储在主内存中共享。每个线程有自己的工作内存，工作内存中保存的是主内存中变量的副本，线程对变量的读写等操作必须在自己的工作内存中进行，而不能直接读写主内存中的变量。
在多线程进行数据交互时，例如线程 A 给一个共享变量赋值后，由线程 B 来读取这个值，A 修改完变量是修改在自己的工作区内存中，B 是不可见的，只有从 A 的工作区写回主内存，B 再从主内存读取自己的工作区才能进行进一步的操作。由于指令重排序的存在，这个写—读的顺序有可能被打乱。因此 JMM 需要提供原子性、可见性、有序性的保证。
详解 JMM 保证
如下图所示，来看 JMM 如何保证原子性、可见性，有序性。
原子性
JMM 保证对除 long 和 double 外的基础数据类型的读写操作是原子性的。另外关键字 synchronized 也可以提供原子性保证。synchronized 的原子性是通过 Java 的两个高级的字节码指令 monitorenter 和 monitorexit 来保证的。
可见性
JMM 可见性的保证，一个是通过 synchronized，另外一个就是 volatile。volatile 强制变量的赋值会同步刷新回主内存，强制变量的读取会从主内存重新加载，保证不同的线程总是能够看到该变量的最新值。
有序性
对有序性的保证，主要通过 volatile 和一系列 happens-before 原则。volatile 的另一个作用就是阻止指令重排序，这样就可以保证变量读写的有序性。
happens-before 原则包括一系列规则，如：
详解类加载机制
类的加载指将编译好的 Class 类文件中的字节码读入内存中，将其放在方法区内并创建对应的 Class 对象。类的加载分为加载、链接、初始化，其中链接又包括验证、准备、解析三步。如下图所示。
只有对类主动使用时，才会进行初始化，初始化的触发条件包括在创建类的实例时、访问类的静态方法或者静态变量时、Class.forName() 反射类时、或者某个子类被初始化时。
如上图所示，浅绿的两个部分表示类的生命周期，就是从类的加载到类实例的创建与使用，再到类对象不再被使用时可以被 GC 卸载回收。这里要注意一点，由 Java 虚拟机自带的三种类加载器加载的类在虚拟机的整个生命周期中是不会被卸载的，只有用户自定义的类加载器所加载的类才可以被卸载。
详解类加载器
如上图所示，Java 自带的三种类加载器分别是：BootStrap 启动类加载器、扩展类加载器和应用加载器（也叫系统加载器）。图右边的桔黄色文字表示各类加载器对应的加载目录。启动类加载器加载 java home 中 lib 目录下的类，扩展加载器负责加载 ext 目录下的类，应用加载器加载 classpath 指定目录下的类。除此之外，可以自定义类加载器。
Java 的类加载使用双亲委派模式，即一个类加载器在加载类时，先把这个请求委托给自己的父类加载器去执行，如果父类加载器还存在父类加载器，就继续向上委托，直到顶层的启动类加载器，如上图中蓝色向上的箭头。如果父类加载器能够完成类加载，就成功返回，如果父类加载器无法完成加载，那么子加载器才会尝试自己去加载。如图中的桔黄色向下的箭头。
这种双亲委派模式的好处，可以避免类的重复加载，另外也避免了 Java 的核心 API 被篡改。
详解分代回收
Java 的堆内存被分代管理，为什么要分代管理呢？分代管理主要是为了方便垃圾回收，这样做基于2个事实，第一，大部分对象很快就不再使用；第二，还有一部分不会立即无用，但也不会持续很长时间。
虚拟机划分为年轻代、老年代、和永久代，如下图所示。
根据年轻代与老年代的特点，JVM 提供了不同的垃圾回收算法。垃圾回收算法按类型可以分为引用计数法、复制法和标记清除法。
JVM 中提供的年轻代回收算法 Serial、ParNew、Parallel Scavenge 都是复制算法，而 CMS、G1、ZGC 都属于标记清除算法。
详解 CMS 算法
基于分代回收理论，详细介绍几个典型的垃圾回收算法，先来看 CMS 回收算法。CMS 在 JDK1.7 之前可以说是最主流的垃圾回收算法。CMS 使用标记清除算法，优点是并发收集，停顿小。
CMS 算法如下图所示。
详解 G1 算法
G1 在 1.9 版本后成为 JVM 的默认垃圾回收算法，G1 的特点是保持高回收率的同时，减少停顿。
G1 算法取消了堆中年轻代与老年代的物理划分，但它仍然属于分代收集器。G1 算法将堆划分为若干个区域，称作 Region，如下图中的小方格所示。一部分区域用作年轻代，一部分用作老年代，另外还有一种专门用来存储巨型对象的分区。
G1 也和 CMS 一样会遍历全部的对象，然后标记对象引用情况，在清除对象后会对区域进行复制移动整合碎片空间。
G1 回收过程如下。
G1 采用每次只清理一部分而不是全部的 Region 的增量式清理，由此来保证每次 GC 停顿时间不会过长。
总结如下，G1 是逻辑分代不是物理划分，需要知道回收的过程和停顿的阶段。此外还需要知道，G1 算法允许通过 JVM 参数设置 Region 的大小，范围是 1～32MB，可以设置期望的最大 GC 停顿时间等。有兴趣读者也可以对 CMS 和 G1 使用的三色标记算法做简单了解。
详解 ZGC
ZGC 特点
ZGC 是最新的 JDK1.11 版本中提供的高效垃圾回收算法，ZGC 针对大堆内存设计可以支持 TB 级别的堆，ZGC 非常高效，能够做到 10ms 以下的回收停顿时间。
这么快的响应，ZGC 是如何做到的呢？这是由于 ZGC 具有以下特点。
虽然 ZGC 的大部分时间是并发进行的，但是还会有短暂的停顿。来看一下 ZGC 的回收过程。
ZGC 回收过程
如下图所示，使用 ZGC 算法进行回收，从上往下看。初始状态时，整个堆空间被划分为大小不等的许多 Region，即图中绿色的方块。
开始进行回收时，ZGC 首先会进行一个短暂的 STW，来进行 roots 标记。这个步骤非常短，因为 roots 的总数通常比较小。
然后就开始进行并发标记，如上图所示，通过对对象指针进行着色来进行标记，结合读屏障解决单个对象的并发问题。其实，这个阶段在最后还是会有一个非常短的 STW 停顿，用来处理一些边缘情况，这个阶段绝大部分时间是并发进行的，所以没有明显标出这个停顿。
下一个是清理阶段，这个阶段会把标记为不在使用的对象进行回收，如上图所示，把橘色的不在使用的对象进行了回收。
最后一个阶段是重定位，重定位就是对 GC 后存活的对象进行移动，来释放大块的内存空间，解决碎片问题。
重定位最开始会有一个短暂的 STW，用来重定位集合中的 root 对象。暂停时间取决于 root 的数量、重定位集与对象的总活动集的比率。
最后是并发重定位，这个过程也是通过读屏障，与应用线程并发进行的。
收藏 等于白嫖，点赞 才是真情！
本文分享自微信公众号 - JAVA日知录（javadaily）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。