JVM内存管理笔记

淡淡的烟草味﹌ 2022-09-05 01:52 191阅读 0赞

郑重声明：  
本文属于个人学习笔记，严重参考姜新星大佬在拉勾教育平台的《Android工程师进阶34讲》。严重参考警告，侵删。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 1]  
JVM 的运行时内存结构中一共有两个“栈”和一个“堆”，分别是：Java 虚拟机栈和本地方法栈，以及“GC堆”和方法区（*两栈一器，一堆一区*）。除此之外还有一个程序计数器，但是我们开发者几乎不会用到这一部分。  
JVM 内存中只有堆和方法区是线程共享的数据区域，其它区域都是线程私有的。并且程序计数器是唯一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 情况的区域。

**JVM 是基于栈的解释器执行的，DVM 是基于寄存器解释器执行的。**  
上面这句话里的“基于栈”指的就是虚拟机栈。虚拟机栈的初衷是用来描述 Java 方法执行的内存模型，每个方法被执行的时候，JVM 都会在虚拟机栈中创建一个栈帧。  
其中程序计数器、虚拟机栈、本地方法栈 3 个区域随线程而生，随线程而灭；不存在垃圾回收问题。

可达性分析算法是从离散数学中的图论引入的。

在 Java 中，有以下几种对象可以作为 GC Root：

*  Java 虚拟机栈（局部变量表）中的引用的对象。
 *  方法区中静态引用指向的对象。
 *  仍处于存活状态中的线程对象。
 *  Native 方法中 JNI 引用的对象。

何时回收：

*  Allocation Failure：在堆内存中分配时，如果因为可用剩余空间不足导致对象内存分配失败，这时系统会触发一次 GC。
 *  System.gc()：在应用层，Java 开发工程师可以主动调用此 API 来请求一次 GC。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 2]  
Java 能够实现"一次编译，到处运行”，原因是，.class文件（字节码文件），有了字节码，无论是哪种平台（如：Mac、Windows、Linux 等），只要安装了虚拟机都可以直接运行字节码。  
这种字节码可以不来自Java，还可以是Groovy、JRuby、Jython、Scala 等，因为这些语言经过编译之后也可以生成能够被 JVM 解析并执行的字节码文件。而虚拟机并不关心字节码是由哪种语言编译而来的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 3]  
编译插桩：  
需求背景：记录每一个页面的打开和关闭事件，并通过各种 DataTracking 的框架上传到服务器，用来日后做数据分析。  
方案①**BaseActivity生命周期里处理**，缺点是对第三方依赖库中的界面则无能为力，因为我们没有第三方依赖库的源码。  
方案②**Application.ActivityLifecycleCallbacks**，在其回调生命周期里处理。  
第三种方案：**编译插桩**——就是在代码编译期间修改已有的代码或者生成新代码。实际上，Dagger、ButterKnife 甚至是 Kotlin 语言，它们都用到了编译插桩的技术。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 4]  
从上图可以看出，我们可以在 1、2 两处对代码进行改造。

1.在 .java 文件编译成 .class 文件时，APT、AndroidAnnotation 等就是在此处触发代码生成。（如Butterknife就是APT时期生成代码）

2.在 .class 文件进一步优化成 .dex 文件时，也就是直接操作字节码文件。

重点介绍第二种：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 5]  
使用场景：①日志埋点；②性能监控；③动态权限控制；④业务逻辑跳转时，校验是否已经登录；⑤甚至是代码调试等。

目前市面上主要流行两种实现编译插桩的方式：  
①AspectJ 是老牌 AOP（Aspect-Oriented Programming）框架。J2EE 中最常用，成熟稳定，使用者也不需要对字节码文件有深入的理解。  
②通过 ASM 可以修改现有的字节码文件，也可以动态生成字节码文件，并且它是一款完全以字节码层面来操纵字节码并分析字节码的框架。汇编？

ASM 实现思路：  
①遍历项目中所有的 .class 文件（要创建一个单独的 Gradle Plugin，并在 Gradle Plugin 中使用自定义 Transform 找出所有的 .class 文件。）  
②遍历到目标 .class 文件 （Activity）之后，通过 ASM 动态注入需要被插入的字节码。

Transform 可以被看作是 Gradle 在编译项目时的一个 task，在 .class 文件转换成 .dex 的流程中会执行这些 task，对所有的 .class 文件（可包括第三方库的 .class）进行转换，转换的逻辑定义在 Transform 的 transform 方法中。实际上平时我们在 build.gradle 中常用的功能都是通过 Transform 实现的，比如混淆（proguard）、分包（multi-dex）、jar 包合并（jarMerge）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 6]

ASM 是一套开源框架，添加依赖即可，

// ASM 相关依赖
        implementation 'org.ow2.asm:asm:7.1'
        implementation 'org.ow2.asm:asm-commons:7.1'

参考文章：https://www.jianshu.com/p/16ed4d233fd1

**ClassLoader：负责将 .class 文件加载到 JVM 中。**

在 Java 程序启动的时候，并非一次性加载程序中所有的 .class 文件，而是在程序的运行过程中，动态地加载相应的类到内存中。

通常情况下,Java 程序中的 .class 文件会在以下 2 种情况下被 ClassLoader 主动加载到内存中：①调用类构造器；②调用类中的静态（static）变量或者静态方法。

JVM 中自带 3 个类加载器：  
①启动类加载器 BootstrapClassLoader  
②扩展类加载器 ExtClassLoader （JDK 1.9 之后，改名为 PlatformClassLoader）  
③系统加载器 APPClassLoader

以上 3 者在 JVM 中有各自分工，但是又互相有依赖。  
①AppClassLoader 主要加载系统属性“java.class.path”配置下类文件，也就是环境变量 CLASS\_PATH 配置的路径。因此 AppClassLoader 是面向用户的类加载器，我们自己编写的代码以及使用的第三方 jar 包通常都是由它来加载的。  
②ExtClassLoader 加载系统属性“java.ext.dirs”配置下类文件；  
③BootstrapClassLoader 同上面的两种 ClassLoader 不太一样。它并不是使用 Java 代码实现的，而是由 C/C++ 语言编写的，它本身属于虚拟机的一部分。因此我们无法在 Java 代码中直接获取它的引用。如果尝试在 Java 层获取 BootstrapClassLoader 的引用，系统会返回 null。

**双亲委派模式（Parents Delegation Model）**  
既然 JVM 中已经有了这 3 种 ClassLoader，那么 JVM 又是如何知道该使用哪一个类加载器去加载相应的类呢？答案就是：双亲委派模式。  
**当类加载器收到加载类或资源的请求时，通常都是先委托给父类加载器加载，也就是说，只有当父类加载器找不到指定类或资源时，自身才会执行实际的类加载过程。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 7]  
AppClassLoader 传入的 parent 就是 ExtClassLoader，而 ExtClassLoader 并没有传入任何 parent，也就是 null。

“双亲委派”机制只是 Java 推荐的机制，并不是强制的机制。我们可以继承 java.lang.ClassLoader 类，实现自己的类加载器。如果想保持双亲委派模型，就应该重写 findClass(name) 方法；如果想破坏双亲委派模型，可以重写 loadClass(name) 方法。

自定义ClassLoader  
如果我们想加载其他特殊位置下的 jar 包或类时（比如，我要加载网络或者磁盘上的一个 .class 文件）自带classLoader无法满足，需要自定义。

自定义 ClassLoader 步骤

①自定义一个类继承抽象类 ClassLoader。  
②重写 findClass 方法。  
③在 findClass 中，调用 defineClass 方法将字节码转换成 Class 对象，并返回。  
如本地电脑磁盘写一个类：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 8]

@Override
        protected Class<?> findClass(String name) { 
            //寻找字节码
            byte[] classBytes = findCodeClassFromSomePath(name);
            //根据字节码组装Class对象，并返回
            return this.defineClass(name, classBytes, 0, classBytes.length);
        }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 9]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 10]

> 上述动态加载 .class 文件的思路，经常被用作热修复和插件化开发的框架中，包括 QQ 空间热修复方案、微信 Tink 等原理都是由此而来。客户端只要从服务端下载一个加密的 .class 文件，然后在本地通过事先定义好的加密方式进行解密，最后再使用自定义ClassLoader 动态加载解密后的 .class 文件，并动态调用相应的方法。

Android虚拟机不认识.class需要把.class转成.dex 。加载是在BaseDexClassLoader 中，而我们一般只使用它的两个子类：PathClassLoader 和 DexClassLoader。

一个 class 文件被加载到内存中需要经过 3 大步：装载、链接、初始化。  
![在这里插入图片描述][3743bea2c66b44b599521974c3d8e23e.png]  
①装载：指查找字节流，并根据此字节流创建类的过程。装载过程成功的标志就是在方法区中成功创建了类所对应的 Class 对象。  
②链接：指验证创建的类，并将其解析到 JVM 中使之能够被 JVM 执行。  
③初始化：则是将标记为 static 的字段进行赋值，并且执行 static 标记的代码语句 。

**对象的初始化顺序如下：**

静态变量/静态代码块 -> 普通代码块 -> 构造函数

1.  父类静态变量和静态代码块；
2.  子类静态变量和静态代码块；
3.  父类普通成员变量和普通代码块；
4.  父类的构造函数；
5.  子类普通成员变量和普通代码块；
6.  子类的构造函数。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70]: /images/20220829/1054ba072984474086b2acf339879ad3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 1]: /images/20220829/838c3b8539a7405b87469c0536f5b2bf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 2]: /images/20220829/57d6c8eec45e497ca7a25f1907f37113.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 3]: /images/20220829/bfd44689f0104ac68d30d6217cce9abd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 4]: /images/20220829/5b63f727ebd543e595f8013bbe2c1065.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 5]: /images/20220829/42c034ad2ae445ffa69eed7344c5f203.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 6]: /images/20220829/f6caedc8b3af4f8e865996b5d898af5d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 7]: /images/20220829/e13c81b3f9bb42da9c53fe526f4712cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 8]: /images/20220829/c1bba6afcaee4c16baeea4e30ab1e7f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 9]: /images/20220829/3137f9987ce943fca919252b224af62c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2libGFkZQ_size_16_color_FFFFFF_t_70 10]: /images/20220829/444f8ba7d31e41a89e836d7b4e88f618.png
[3743bea2c66b44b599521974c3d8e23e.png]: /images/20220829/6b29d5308f80448ca95024a79ecfaf2a.png