《深入理解Java虚拟机》学习笔记

怼烎@ 2022-04-06 07:22 259阅读 0赞

## 第二章 Java 内存区域与内存溢出异常 ##

### 内存区域 ###

[![java-memory-area][]][java-memory-area 1]

[![E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E6_A8_A1_E5_9E_8B.png][]][E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E6_A8_A1_E5_9E_8B.png 1]\-- from 姜志明

对象创建

1.  加载类
    
     *  若已经在内存中则跳过。
     *  **类加载完以后就可以确定对象所需的空间大小** // TODO why?
2.  分配内存
    
     *  根据 GC 回收算法的不同，分配方式略有区别。
        
         *  标记整理算法，使用空闲列表
         *  带压缩的算法，使用指针碰撞（已分配和未分配内存间由指针分隔）
3.  内存清零
4.  对象初始化

对象的内存布局

[![对象内存布局][E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E5_B8_83_E5_B1_80.png]][E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E5_B8_83_E5_B1_80.png 1]

*  MarkWord 占用一个 **字** 的大小，其中分为两部分：
    
    1.  对象自身运行时元数据。例如，哈希码、GC 分代年龄、锁状态标志等等
    2.  类型指针。指向其类的元数据。
    3.  若对象是数组则还需要保存数组的长度。
 *  域的存储顺序：
    
    1.  基本类型优先，长度长的优先。
    2.  父类域优先。子类较短域可插入父类域空隙。
    3.  受虚拟机分配策略参数和域定义顺序的影响。

对象访问

两种方式：

1.  直接引用
2.  引用句柄（句柄池）

### 内存溢出异常 ###

常用 JVM 参数 （Java HotSpot VM）

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>含义</th> 
   <th>实例</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>-verbose:class</td> 
   <td>显示每一个被加载的类的信息</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>-verbose:gc</td> 
   <td>显示每一个 GC 事件的信息</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>-Xmnsize</td> 
   <td>年轻代最大容量</td> 
   <td>-Xmn256m</td> 
  </tr> 
  <tr> 
   <td>-Xmssize</td> 
   <td>堆的初始大小。1024 的整数倍并且要大于 1MB</td> 
   <td>-Xms6m</td> 
  </tr> 
  <tr> 
   <td>-Xmxsize</td> 
   <td>堆的最大容量。1024 的整数倍并且要大于 2MB</td> 
   <td>-Xmx80m</td> 
  </tr> 
  <tr> 
   <td>-Xsssize</td> 
   <td>线程栈容量。平台不同默认值不同，详情参考文档。Linux/x64 (64-bit): 1024 KB</td> 
   <td>-Xss1m</td> 
  </tr> 
  <tr> 
   <td>-XX:MaxDirectMemorySize=size</td> 
   <td>直接内存的最大容量，默认与堆容量相同</td> 
   <td>-XX:MaxDirectMemorySize=1m</td> 
  </tr> 
  <tr> 
   <td>-XX:+HeapDumpOnOutOfMemory</td> 
   <td>当抛出 OOM 时，使用 HPROF 将堆的快照保存到当前目录</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>-XX:HeapDumpPath=path</td> 
   <td>设置快照输出路径</td> 
   <td>-XX:HeapDumpPath=/var/log/java/java_heapdump.hprof</td> 
  </tr> 
  <tr> 
   <td>-XX:+PrintGCDetails</td> 
   <td>开启在 GC 时打印详细信息</td> 
   <td>&nbsp;</td> 
  </tr> 
  <tr> 
   <td>-XX:SurvivorRatio=ratio</td> 
   <td>新生代中 eden 与 survivor 的大小比例，默认为 8</td> 
   <td>-XX:SurvivorRatio=4</td> 
  </tr> 
 </tbody> 
</table>

参考： [Java HotSpot VM 参数][Java HotSpot VM]

常见异常及可能原因

*  堆区
    
     *  `OutOfMemoryException`。使用工具对快照进行分析，看是否发生了内存泄露（内存中有不再使用的但无法回收的对象或资源）。若是，则通过分析引用链找到根源，解决问题；若不是检查虚拟机堆参数，看是否能够调大。再检查代码中是否有生命周期很长的大对象。
 *  虚拟机栈和本地方法栈
    
     *  `OutOfMemoryException`。栈容量 \* 线程数量 = 固定值。当线程数量过多时会引发，可以适当减小栈容量。
     *  `StackOverflowException`。按异常查根源。
 *  方法区和运行时常量池
 *  直接内存溢出
    
     *  不正确的使用 NIO。

String 与字符串常量

public class StringTest {
    	public static void main(String[] args) {
    		String m = "hello";
    		String n = "hello";
    		String u = new String(m);
    		String v = new String("hello");
    		
    		System.out.println("m == n: " + (m == n));
    		System.out.println("m == u: " + (m == u));
    		System.out.println("m == v: " + (m == v));
    		System.out.println("u == v: " + (u == v));
    	}
    }
    
    output:
    m == n: true
    m == u: false
    m == v: false
    u == v: false

[![内存模型][string-const.png]][string-const.png 1]

## 第三章 垃圾收集器与内存分配策略 ##

### 判断对象是否存活 ###

1.  引用计数器算法。给对象添加一个引用计数器，增加/删除引用时对计数器进行修订。但是该方法因为无法解决循环引用（例如两个对象互相引用）的问题，所以一般不使用该方法
2.  可达性分析算法。从 `GC root` 开始递归查询并标记，结束后未被标记的（不可达的）即为可回收的对象。`GC root` 共有四种：
    
     *  栈中引用的对象
     *  方法区常量引用的对象
     *  方法区静态域引用的对象
     *  本地方法中 JNI 引用的对象（不太懂）
3.  回收方法区
    
     *  新生代的回收效率可达到 70% - 95%，而永久代则低的多（性价比太低）
     *  在大量使用反射、动态代理、CGLib 等 ByteCode 框架、动态生成 JSP 以及 OSGi 这类频繁自定义 ClassLoader 的场景都需要虚拟机有卸载类的能力。

### 垃圾收集算法 ###

1.  标记-清除算法
    
     *  扫描一遍，标记出需要回收的对象，再扫描将其清除
     *  标记/清除两阶段时间效率都不高，且回收后空间较零碎。
2.  复制算法
    
     *  将内存分为两块，当一块中内存不足时，将其中所有存活对象复制到另一块中，回收当前一整块。
     *  目前商用虚拟机大都使用这一算法回收新生代。将内存划分为一个较大的 Eden 区和两块较小的 Survivor. Eden：Survivor = 8：1
3.  标记整理算法
    
     *  标记出须清理的对象，然后其余对象移动到一端
4.  分代收集算法
    
     *  新生代使用复制算法
     *  永久代使用其他两种算法

### HotSpot 算法实现 ###

1.  当程序执行到安全点（safepoint）时进行 GC，通过在安全点（safepoint）生成的 OopMaps 快速遍历 GC root 进行回收。
    
     *  安全点（safepoint）：指令序列复用的位置。例如方法调用、循环结构、异常跳转等位置。
     *  OopMaps：一种特殊的数据结构，用于枚举 GC root
2.  但是如果线程处于不执行的状态时，如 sleep 或 blocked 无法执行到安全点，即需要提前标记为安全区域(safe region)。GC 时不考虑处于安全区域的线程，若安全区域代码执行结束但 GC 未结束时该线程等待 GC 结束信号。
    
     *  安全区域（safe region）：引用不发生改变的代码片段

### 垃圾收集器 ###

[![gc collectors][]][gc collectors 1]

*  并发(concurrent) vs 并行(parallel)
    
    1.  并行是同时进行（多 CPU）
    2.  并发可交替
 *  Minor GC vs Major GC vs Full GC
    
     *  Minor GC：只回收新生代
     *  Major GC：只回收永久代
     *  Full GC： 回收整个堆。相当于 Minor GC + Major GC

1.  serial。单线程，简单高效。复制算法
2.  PerNew。serial 的多线程版本，并行。
3.  parallel Scavenge。 与 PerNew 类似，复制算法、多线程、并行。但侧重吞吐量，拥有自适应调节的能力。适合用在后台不需要太多用户交互的地方。
    
     *  吞吐量 = 用户代码执行时间 / （用户代码执行时间 + 垃圾回收时间）
     *  自适应调节：虚拟机根据但前系统的运行情况，自动调节虚拟机各参数以确保最大吞吐量。
4.  serial old。serial 的永久代版本。采用标记整理算法。
5.  parallel old。parallel Scavenge 的老年代版本，采用标记整理算法。与 parallel scavenge 搭配可以用在注重吞吐量及 CPU 资源敏感的地方。
6.  CMS（concurrent mark sweep）。并发低停顿，使用标记清理算法。非常优秀的一款收集器，但还是有几个缺点：
    
    1.  对 CPU 资源敏感，当其小于数量小于 4 个是可能会对用户程序有较大影响。默认启动回收线程数 = （CPU 数 + 3）/ 4
    2.  无法处理浮动垃圾。浮动垃圾：在垃圾回收期间生成的垃圾
    3.  回收后会留有大量的空间碎片。
7.  G1 //TODO

### 内存分配与回收策略 ###

TLAB（Thread local allocate buffer）线程私有分配缓冲区，每个线程一个

1.  对象优先在 Eden 区分配。内存不足时触发 Minor GC。
2.  大对象直接进入老年代。例如数组或超过参数指定大小的对象。
3.  长期存活的对象进入老年代。GC 超过一定次数仍存活的对象。默认为 15 次，可通过虚拟机参数 `-XX:MaxTenuringThreshold` 来设置。
4.  动态对象年龄判定。当一个年龄的所有对象大小总和超过 Servivor 空间一半时，大于等于该年龄的所有对象都进入老年代
5.  空间分配担保。当发生 Minor GC 时，若存活的对象过多，servivor 空间无法全部容纳时，会将剩余的对象直接放入永久代；若永久代空间不足以容纳时会引发一次 Full GC

## 第六章 类文件结构 ##

1.  类文件的结构拥有固定的格式，包含两部分的数据：
    
    1.  类的元数据。
    2.  方法代码的字节流
2.  `code` 属性表包含的属性
    
    1.  `max_stack` 存储操作数栈的最大深度值。运行时用来确定分配栈帧中所需的操作数栈深度。
    2.  `max_locals` 局部变量所需的最大空间大小
3.  符号引用
    
    1.  类与接口的全限定名
    2.  域的名称与描述符
    3.  方法名与描述符
4.  该部分内容可以通过查表获得，不再赘述。

## 第七章 虚拟机类加载机制 ##

### 类加载的过程 ###

[![class-life.jpg][]][class-life.jpg 1]

1.  加载
    
    1.  通过全类名获取该类的二进制字节流
    2.  解析字节流，将字节流所表达的静态存储结构转化为方法区的运行时数据结构 **（这是什么东西？）**
    3.  为该类创建一个 `Class` 对象，用来访问该类的类数据
2.  连接
    
    1.  验证
        
         *  为了确保加载的字节流时符合规范的，不会危害到虚拟机自身的安全。主要包括
        
        1.  文件格式验证
        2.  元数据验证
        3.  字节码验证
        4.  符号引用验证
    2.  准备
        
         *  为类变量分配内存并进行初步初始化（`0/null`） // 不应该是在类加载阶段完成的么？
    3.  解析
        
         *  将符号引用替换为直接引用
3.  初始化
    
     *  `static fields and block init`
4.  使用
5.  卸载

### 类加载器 ###

1.  一个加载器确定一个类的命名空间。同一个类由不同加载器加载后是不同的类。
2.  [![classloader.png][]][classloader.png 1]
    
     *  双亲委派：当需要加载一个类时先使用父类加载器（其实这个地方不是很准确，父子关系是通过复合来实现的），若失败了，再使用当前的加载器。如果自己写一个 `Object` 类，编译可通过但是由于双亲委派，它永远都不会被加载。

## 第十章 早期（编译器）优化 ##

// TODO: 因本章含有相当多的编译原理相关概念，所以第十、十一章学习延后（预计第 8-9 周）

### 前端编译过程（`*.java --> *.class`） ###

1.  解析与填充符号表
    
    1.  词法分析。将源代码转换为标记（`Token`） 的集合
        
         *  Token: 是编译过程中的最小元素。例如关键字、变量名、运算符等等
    2.  语法分析。通过 `Token` 序列将构造抽象语法树(Abstract syntax tree)

> 我有一个微信公众号，经常会分享一些Java技术相关的干货；如果你喜欢我的分享，可以用微信搜索“Java团长”或者“javatuanzhang”关注。

[java-memory-area]: https://github.com/c-rainstorm/blog/raw/master/res/java-memory-area.png
[java-memory-area 1]: https://github.com/c-rainstorm/blog/blob/master/res/java-memory-area.png
[E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E6_A8_A1_E5_9E_8B.png]: https://github.com/c-rainstorm/blog/raw/master/res/%E5%AF%B9%E8%B1%A1%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B.png
[E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E6_A8_A1_E5_9E_8B.png 1]: https://github.com/c-rainstorm/blog/blob/master/res/%E5%AF%B9%E8%B1%A1%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B.png
[E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E5_B8_83_E5_B1_80.png]: https://github.com/c-rainstorm/blog/raw/master/res/%E5%AF%B9%E8%B1%A1%E5%86%85%E5%AD%98%E5%B8%83%E5%B1%80.png
[E5_AF_B9_E8_B1_A1_E5_86_85_E5_AD_98_E5_B8_83_E5_B1_80.png 1]: /images/20220406/5b1ccc8362bf4f70beb6115887d6dab8.png
[Java HotSpot VM]: http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
[string-const.png]: https://github.com/c-rainstorm/blog/raw/master/res/string-const.png
[string-const.png 1]: /images/20220406/6c92bffca0da43b693a425402e3a6bd5.png
[gc collectors]: /images/20220406/191c342385ee42c2bcbe588132873587.png
[gc collectors 1]: https://github.com/c-rainstorm/blog/blob/master/res/gc-collectors.jpg
[class-life.jpg]: https://github.com/c-rainstorm/blog/raw/master/res/class-life.jpg
[class-life.jpg 1]: https://github.com/c-rainstorm/blog/blob/master/res/class-life.jpg
[classloader.png]: https://github.com/c-rainstorm/blog/raw/master/res/classloader.png
[classloader.png 1]: https://github.com/c-rainstorm/blog/blob/master/res/classloader.png