JVM阅读笔记-初学

深入理解JVM

第一章 走近JAVA

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

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

第六章 类文件结构

第七章 虚拟机类加载机制

Matrix 相关

---

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

一、运行时的数据区域

图片1.png

---

http://androidxref.com/9.0.0_r3/s?defs=BaseDexClassLoader&project=libcore

程序计数器

Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个具体确定的时刻，一个处理器内核只会执行一条线程中的指令，因此，为了不同线程切换之后可以恢复原先的状态，每个线程都需要一个程序计数器，各个线程的程序计数器之间不会相互影响，独立存储，这类内存是线程私有的内存。

如果执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节指令的地址，如果是Native方法， 则值为空（undefined），且程序计数器是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

Java虚拟机栈

Java虚拟机栈所占有的内存空间也就是我们平时所说的“栈内存”，并且也是线程私有的，生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时，都会创建一个栈帧，用于存储局部变量表（基本数据类型，对象的引用和returnAddress类型）、操作数栈、动态链接、方法出口等信息。

局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在栈帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。对于Java虚拟机栈，有两种异常情况：

1）如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；

2）如果虚拟机栈在动态扩展时，无法申请到足够的内存，就会抛出OutOfMemoryError；（动态扩展的方法有Segmented stack双向链表，可以简单理解成一个双向链表把多个栈连接起来，一开始只分配一个栈，这个栈的空间不够时，就再分配一个，用链表一个一个连起来。Stack copying就是在栈不够的时候，分配一个更大的栈，然后把原来的栈复制过去）

本地方法栈和Java堆

本地方法栈和虚拟机栈所发挥的作用非常相似，它们之间的区别主要是【虚拟机栈是为虚拟机执行Java方法（也就是字节码）服务的，而本地方法栈则为虚拟机使用到的Native方法服务】。与虚拟机栈类似，本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。

Java堆是Java虚拟机所管理的内存中最大的一块。Java堆在主内存中，是被所有线程共享的一块内存区域，其随着JVM的创建而创建，【堆内存的唯一目的是存放对象实例和数组。同时Java堆也是GC管理的主要区域】。

Java堆物理上不需要连续的内存，只要逻辑上连续即可。如果堆中没有内存完成实例分配，并且也无法再扩展时，将会抛出OutOfMemoryError异常。《？》

运行时常量池

【图中没有运行时常量池了】
还有一项信息是常量表，用于存放编译期生成的各种字面常量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放（JDK1.7开始，常量池已经被移到了堆内存中了）。也就是说，这部分内容，在编译时只是放入到了常量池信息中，到了加载时，才会放到运行时常量池中去。运行时常量池县归于Class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区的运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用的比较多的是String类的intern()方法。

方法区

也是线程公有的一个部分，用来存储已经被加载过的类信息，常量，静态变量

---

二、新建对象

Java的语言层面上，创建对象（克隆，反序列化）都是一个new关键字，在虚拟机中是怎样工作的呢?

首先虚拟机在解析到new指令的时候，会去检查参数是否可以定位到一个类的符号引用，并且检查这个类是否已经被加载、解析、初始化过，如果没有的话会先进行类加载的操作。

在此之后会为新生的对象进行内存的分配工作，分配的方式根据不同JVM的堆中内存存储方式不同也会不一样（空闲列表/指针碰撞）。

指针碰撞：假设Java堆中的内存是绝对规整的，所有用过的内存放在一边，没有用过的内存放在另一边，中间放着一个指针作为分界点的指示器，那么分配内存就是移动这个指针一个对象大小的距离（在给新建对象分配内存的时候，会占用多少内存是一个已知信息）

空闲列表：如果Java堆中的内存是并不规整的，虚拟机就需要维护一个列表，哪些内存块是可用的，在分配的时候哦找到一块足够大的空间划分给对象，并更新列表上的记录。

JAVA堆是线程公有的，所以在多线程分配内存时也会遇到并发的问题，那么这个问题的解决方案也有两种，一种是CAS配上失败重试，另一个就是TLAB，Java堆首先给每个线程分配一块内存，之后每个线程会优先在Tlab上进行对象的内存分配。（-XX:+UseTLAB）

CAS: Compare and Swap, 比较并交换，整个Cucurenct包中，CAS理论是它实现的基石。

CAS操作包括3个操作数------内存位置（V），预期原值（A）， 新值（B），如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置更换为新值（原子操作），否则，处理器不做任何操作，不论任何情况，它都会在CAS指令返回该内存位置的值【底层使用总线锁实现，】（CAS只保证操作无错误，不代表一定会成功，比如ABA问题）

内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零值（不包括对象头）如果使用TLAB,这个操作可以提前到TLAB分配的时候，再之后，对于虚拟机来说，一个新建对象已经完成了，对于语言层面来说，class的方法还没有执行到，（在这里可以先暂时将 理解为Java的构造函数），在这之后一个可用的对象才真正的生成。

栈上分配和逃逸分析

上面所谈到的内存分配都只设计Java堆的内存分配，书本也因为JDK版本原因没有涉及到逃逸分析的相关内容，这里自己搜资料总结了一下。在JDK8之后的版本默认开启逃逸分析（栈上分配的前提），8以下（-XX:+DoEscapeAnalysis）可以进行逃逸分析。

栈上分配：我们都知道Java中的对象都是在堆上分配的，而垃圾回收机制会回收堆中不再使用的对象，但是筛选可回收对象，回收对象还有整理内存都需要消耗时间。如果能够通过逃逸分析确定某些对象不会逃出方法之外，那就可以让这个对象在栈上分配内存，这样该对象所占用的内存空间就可以随栈帧出栈而销毁，就减轻了垃圾回收的压力。

在一般应用中，如果不会逃逸的局部对象所占的比例很大，如果能使用栈上分配，那大量的对象就会随着方法的结束而自动销毁了。
对象逃逸有以下几种情况：
···
public class EscapeAnalysis {

 public static Object object;
 
 public void globalVariableEscape(){//全局变量赋值逃逸  
     object =new Object();  
  }  
 
 public Object methodEscape(){  //方法返回值逃逸
     return new Object();
 }
 
 public void instancePassEscape(){ //实例引用发生逃逸
    this.speak(this);
 }
 
 public void speak(EscapeAnalysis escapeAnalysis){
     System.out.println("Escape Hello");
 }

}
···
全局变量赋值逃逸

方法返回值逃逸

实例引用发生逃逸

线程逃逸:赋值给类变量或可以在其他线程中访问的实例变量

JVM配置[关闭逃逸分析]:

-server -Xmx10m -Xms10m -XX:-DoEscapeAnalysis -XX:+PrintGC

/**
 * Created by huangwt on 2019/3/8.
 */
public class StackAlloc {
    private static void alloc() {
        byte[] tmpAlloc = new byte[20];
    }
    public static void main(String[] args) {
        for (int i = 0; i < 1000000; i ++) {
            alloc();
        }
    }
}

在上面这段Code中，我们生成的长度为20的tmpAlloc数组并没有被外界引用,但是查看GC 日志可以发现
【这里的GC均是Mijor GC】

[GC 2560K->568K(10240K), 0.0057678 secs]
[GC 3128K->576K(10240K), 0.0006989 secs]
[GC 3136K->584K(10240K), 0.0006238 secs]
[GC 3144K->584K(10240K), 0.0019912 secs]
[GC 3144K->584K(10240K), 0.0012139 secs]
[GC 3144K->584K(9216K), 0.0010486 secs]
[GC 2120K->656K(9728K), 0.0007815 secs]
[GC 2192K->648K(9728K), 0.0002554 secs]
[GC 2184K->696K(9728K), 0.0001980 secs]
...

发生了频繁的GC，说明内存分配在Java堆上而非栈上，这里的tmpAlloc生命周期应该是跟随alloc任务出栈而结束，但是却没有结束，是因为我们关闭了逃逸分析，再次打开发现GC一次都没有触发，说明内存分配在栈上跟随方法一同被出栈了。

这里举的方法都是这里举得例子是虚拟机栈的栈上分配，有关本地方法栈可以查看这个回答https://stackoverflow.com/questions/161053/which-is-faster-stack-allocation-or-heap-allocation

code optimization：虽然不清楚DVM/ART的工作机制，但是有关对象的生命周期我们一般希望在不影响频繁GC的情况下越短越好，我们的code有很多可以优化为local variable，而不需要被整个对象所持有的对象，Lint可以检查出来。

对象的内存布局

在HotSpot虚拟机中，对象在内存中存储的布局分为3个区域：对象头，实例数据和对齐填充。
对象头包括两个部分的数据，第一部分是“mark word”包含 hashcode，GC分代年龄（之后会说到），锁状态标志，线程持有的锁（对象头的锁相关在书的第十三章会详细讲解，所以我没有去查资料），偏向线程ID，偏向时间戳等等。
第二部分是类型指针，即指向对象指向类元数据的指针，虚拟机来确定这个对象是哪个类的实例。 另外，如果对象是一个Array类型，还需要一个int类型的长度来表示数组的长度
实例数据就是字面意思
对齐填充，不一定存在，例如HotSpot VM的内存管理系统要求对象起始地址必须是8字节的整数倍，有点类似Android的ZipAlign机制，总之作用就是用来方便寻址。

Integer = (8 + 4) + 4(int)
Long = (8 + 4) + 8(long) + 4(padding)
优化空间：可以被替换为元数据类型的不要使用包装类。

---

第三章 垃圾回收器和内存分配策略

线程私有的内存区域会随着线程的生命周期自动的被回收。
线程公有的Java堆 & 方法区，只有在运行时才知道需要具体创建多少个对象，这部分内存的分配和回收都是动态的，所以需要GC配合垃圾回收。本章分为以下几点内容分享

1、如何判断对象需要进行回收
2、垃圾收集的算法
3、JVM的具体实现（HotSpot-JVM）

4、垃圾收集器
5、内存分配&回收策略

一、如何判断对象是否死去

1、引用计数

在Fix内存泄漏之前我对此并不了解，现在大家应该都知道在Android中是与可达性分析算法相关。
那么现有的常见的有引用计数算法，故名思议，对象中添加一个引用计数器，每当有地方引用她时，计数器+1 ，反之则-1。
Python使用的主流回收方式就是引用计数，和所有面向对象的语言一样，Python的PyObject的结构体如下所示，这个ob_refcnt就是引用计数【这里选的是CPython】。
前文也介绍过JVM对象的组成结构了，其中并没有类似字段，所以Java采用的并非此算法，引用计数的优点就是简单，缺点就是浪费内存&不好解决循环引用的问题，前者倒无所谓，要解决后者肯定需要另外的对象来维护这件事或者Object添加新的字段来维护，这就得不偿失了。

 typedef struct_object {
 int ob_refcnt;
 struct_typeobject *ob_type;
} PyObject;

2、可达性算法

另一个常见的就是可达性分析算法，将某些对象称为GC-ROOT，从GC-ROOT走过的路径即是引用链，而GC不达的对象即为可回收的对象,像这种，B,C即为可以回收的对象。
那么什么是GC ROOT呢？
在Java中，可以作为GC ROOT的有以下几种：

虚拟机栈中引用的对象
方法区类静态属性引用的对象
方法区常量引用的对象
本地方法栈JNI引用的对象

image.png

java中的主流虚拟机HotSpot采用可达性分析算法来确定一个对象的状态，那么HotSpot在具体实现该算法时采用了哪些结构？

使用OopMap记录并枚举根节点

HotSpot首先需要枚举所有的GC Roots根节点，虚拟机栈的空间不大，遍历一次的时间或许可以接受，但是方法区的空间很可能就有数百兆，遍历一次需要很久。更加关键的是，当我们遍历所有GC Roots根节点时，我们需要暂停所有用户线程，因为我们需要一个此时此刻的”虚拟机快照”，如果我们不暂停用户线程，那么虚拟机仍处于运行状态，我们无法确保能够正确遍历所有的根节点。所以此时的时间开销过大更是我们不能接受的。

基于这种情况，HotSpot实现了一种叫做OopMap的数据结构，这种数据结构在类加载完成时把对象内的偏移量是什么类型计算出，并且存放下位置，当需要遍历根结点时访问所有OopMap即可。

用安全点Safepoint约束根节点

如果将每个符合GC Roots条件的对象都存放进入OopMap中，那么OopMap也会变得很大，而且其中很多对象很可能会发生一些变化，这些变化使得维护这个映射表很困难。实际上，HotSpot并没有为每一个对象都创建OopMap，只在特定的位置上创建了这些信息，这些位置称为安全点（Safepoints）。

从线程角度看，safepoint可以理解成是在代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要，可以在这个位置暂停，比如发生GC时，需要暂停暂停所以活动线程，但是线程在这个时刻，还没有执行到一个安全点，所以该线程应该继续执行，到达下一个安全点的时候暂停，等待GC结束。【？】

SafePoint.cpp 实现 http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/e1b1da173e19/src/share/vm/runtime/safepoint.cpp

引用

Java中的引用目前有以下几种

强引用（SoftReference）

强引用就是正常的使用方式，即便系统抛出OOM也不会对对象进行回收

软引用

软引用是指当内存不够时才会对软引用进行回收，只要内存还充足，就不会对其进行回收

弱引用

弱引用则是指不论内存是否足够，只要gc了就会回收

    public Reference soft;
    public Reference weak;

    soft = new SoftReference<>(new Temp());
    weak = new WeakReference<>(new Temp());

        Observable.just(new Object())
                .observeOn(Schedulers.io())
                .subscribe(new Consumer