目录
我的GitHub：Powerveil · GitHub
我的Gitee：Powercs12 (powercs12) - Gitee.com
皮卡丘每天学Java
内存区域划分
JVM内存区域大致分为四块：堆、栈(虚拟机栈，本地方法栈)、程序计数器、方法区。
public class Test {
// 成员变量
public int c = 11;
public Test d = new Test();
// 静态变量
public static int e = 12;
public static Test f = new Test();
public static void main(String[] args) {
// 局部变量
int a = 10;
Test b = new Test();
}
}
a，b为局部变量，在栈中存储；c，d为成员变量，在堆中存储；e，f为静态变量，在方法区中存储。
| 变量位置 | JVM位置 |
|---|---|
| 局部变量 | 栈上 |
| 成员变量 | 堆上 |
| 静态变量 | 方法区上 |
类加载
类加载大致分为五个过程：加载、连接、初始化，其中连接又分为：验证、准备、解析三个过程。
以字符串为例
1.加载：找到.class文件，读取文件内容，并且按照.class规范的格式来解析
2.验证：检查当前的.class里的内容格式是否符合要求
下图为.class文件的定义，类似C语言的结构体，左侧是类型，右侧是变量名。
u2代表两个字节的无符号整数，u4代表四个字节的无符号整数，cp_info，field_info，method_info，attribute_info为类似.class文件类型的其他类型。
| 属性 | 含义 |
|---|---|
| magic | 魔数 |
| minor_version | 最小版本号 |
| major_version | 最大版本号 |
| constant_pool_count | 常量池个数 |
| constant_pool[constant_pool_count-1] | 常量池 |
| access_flags | 类的访问权限和属性 |
| this_class | 表示此文件定义的类 |
| super_class | 表示其父类 |
| interfaces_count | 当前类实现的接口数量 |
| interfaces[interfaces_count] | 当前类具体实现哪些接口 |
| fields_count | 当前类拥有的属性个数 |
| fields[fields_count] | 当前类具体拥有的属性 |
| methods_count | 当前类拥有的方法个数 |
| methods[methods_count] | 当前类具体拥有的方法 |
| attributes_count | 当前类的其他属性个数 |
| attributes[attributes_count] | 当前类的其他其他属性 |
这里着重说一下魔数
在计算机领域，魔数有两个含义，一指用来判断文件类型的魔数；二指程序代码中的魔数，也称魔法值。
这里主要说第一种含义，不仅Java的.class文件有魔数，其他文件也有魔数，一个文件的类型不是取决于文件后缀名，本质上却决于该文件的魔数值。
3.准备：给类里的静态变量分配空间(并设置默认值)
4.解析，初始化字符串常量，把符号引用替换成直接引用。
5.初始化，针对类进行初始化，初始化静态成员，执行静态代码块，并且加载父类...
何时触发类加载？
第一次使用到一个类的时候就会触发加载(类似懒汉模式)。
1.创建这个类的实例
2.使用了类的静态方法/静态属性
3.使用类的子类(加载子类会触发加载父类)
注意第二条
访问类中的static final 成员时,JVM会在编译阶段对类执行编译优化,当类中有static final修饰的基本数据类型和字符串类型时,就会在编译阶段执行初始化.
双亲委派模型
JVM加载类，是由类加载器(class loader)这样的模块来负责的
JVM自带了多个类加载器(程序员也可以自己实现)
主要分为三类加载器
1.Bootstrap ClassLoader(负责加载标准库中的类)
2.Extension ClassLoader(负责加载JVM扩展的库的类，Java规范里没有写的，但是JVM实现出来了)
3.Application ClassLoader(负责加载自己的项目里的自定义类)
这三类加载器各自负责各自的片区(负责各自的一组目录)
1.上述三个类加载器存在父子关系
2.进行类加载的时候，输入的内容 全限定类名 java.util.Arrays
3.加载的时候，从Application ClassLoader开始
4.某个类加载器开始加载的时候，不会立即扫描自己负责的路径，而是先把任务委托给 父 “类加载器” 先来进行处理
5.找到最上面的Bootstrap ClassLoader 在往上，没有父 类加载器了，自己加载
6.如果自己没找到类，就交给自己的儿子，继续加载。
7.如果一直找到最下面Application ClassLoader也没有找到类，就会抛出一个"类没找到"异常，类加载就失败了，类似下图
按照这个顺序加载，最大的好处在于：如果开发者写了一个类，这这个类的全限定类名和标准库里的类冲突了，(比如自己写一个全限定类名为java.util.Arrays的类)，此时仍然保证类加载可以加载到标准库的类，防止代码加载错了带来问题。
演示一下
idea非常智能，没有找到我自己写的Arrays，演示失败
我尝试先让类导入再改包名
idea还是检测出来了
GC
垃圾回收(Garbage Collection)
写C语言代码的时候，使用malloc申请内存(动态内存申请)，务必需要通过free来进行释放，如果不手动free，这个内存会一直持续到程序结束。造成空间上的浪费，而这些只用几次就不使用，直到程序结束还释放的空间就称为垃圾。
手动释放，最大的问题在于容易忘记，造成内存泄漏。内存泄漏短时间内不会出现问题，就像一颗定时炸弹，不确定那个时候会造成程序崩溃。
于是程序员大佬就想出各种方案，其中GC(垃圾回收)就是一种主流的方案。许多语言使用了GC如，Java、Python、JavaScript、Golang、PHP等等。
Java程序员只需要负责申请内存，释放内存的工作交给JVM来完成，JVM会自动判定当前的内存什么时候需要释放，认为这个内存不再使用了，就自动释放了。
GC回收那部分内存？
堆(GC主要就是针对堆来回收)、方法区(类对象，加载之后也不太会卸载)、栈(释放时机确定，不必回收)、程序计数器(固定内存空间，不必回收)。
GC中回收内存，不是以"字节"为单位，而是以“对象”为单位
怎么回收？
1.先找出垃圾(找出是谁垃圾，没错，是我了)
2.再回收垃圾(释放内存)
怎么找垃圾(判定某个对象是否是垃圾)
如果一个对象再也不用了，就说明就是垃圾了。再Java中，对象的使用需要凭借引用，假设有一个对象已经没有任何引用能够指向它了，这个对象自然就无法再被使用了，
最关键的要点，通过引用来判定当前对象是否还能被使用了，没有引用指向就是为是无法被使用。
两种典型的判断对象是否存在引用的方法：引用计数[不是JVM采取的方法]，可达性分析[是JVM采取的办法]
引用计数
给每个对象都加上一个计数器，这个计数器就表示“当前的对象有几个引用”
每次多一个引用指向该对象，计数器就+1
每次少一个引用指向该对象，计数器就-1
(比如引用是一个局部变量，除了作用域。或者引用是个成员变量，所在的对象被销毁了)
当引用计数器数值为0的时候，就说明当前这个对象已经无人能够使用了，此时就可以进行释放了
引用计数的优点：简单，容易实现，执行效率也比较高
缺点
1.空间利用率比较低，尤其是小对象 比如计数器是个int，如果你的对象本身里面只有一个int成员
2.可能会出现循环引用的情况
虽然当前这两个对象引用计数为1，但实际上是两个对象再互相引用，此时外界的代码仍然是无法访问和使用对象的，但是由于引用计数没有成为0，这俩对象是无法进行释放的。
可达性分析
约定一些特定的变量，成为“GC roots”，每个一段时间，从GC roots出发，进行遍历，看看当前哪些变量是能够被访问到的，能被访问到的变量就称为“可达”，否则就是“不可达”
GC roots
-
栈上的变量
-
常量值应用的对象
-
方法区，引用类型的静态变量
每一组都有一些变量
每个变量都可以视为起点
从这些起点出发，尽可能遍历，能够找到所有访问到的对象
只要是通过上述root的方式访问到的对象，对象都是可达的。
具体怎么回收？
标记-清除法
先从堆首地址开始遍历，判断该对象是垃圾后标记为垃圾，第二次遍历清除被标记为垃圾标志的垃圾
然后把对象对应的内存空间进行释放。
缺点
这种方式有一个最大的问题：内存碎片。导致整个内存“支离破碎”，比如上述每个黑色区域是1Kb，此时整个有4K的空闲空间，但是由于内存是离散的，导致想申请2Kb的内存空间(连续的)都申请不成功
复制算法
针对刚才所说的内存碎片问题来进行引入的方法
使用左侧空间时，右侧不用；使用右侧空间时，左侧不用。
不再是原地释放了，而是把“非垃圾”(可以继续使用的对象)拷贝到另外一侧，然后再把之前这一半整个释放掉，内存碎片就得到了妥善处理。
缺点
1.空间利用率更低了(用一半，丢一半)
2.如果一轮GC下来，大部分对象要保留，只有少数对象要回收，这个时候复制开销就很大了。
标记整理法
类似于顺序表删除元素搬运操作，将后面元素依次搬运到前面垃圾位置。
这种方式相对于上述发复制算法来说，空间利用率上来了，同时也还是能够解决内存碎片问题，但是搬运操作也是比较耗时的。
分代回收策略
上述三个方式，都不是十全十美，所以需要根据实际的场景，因地制宜的解决问题。
根据对象不同的特点，采取不同的回收方式
对象不同的特点：根据对象年龄划分
对象年龄：更具GC的轮次来算，有一组线程，周期性的扫描代码里所有的对象，如果一个对象经历了一次GC而没有被回收，就认为年龄+1.
一个基本的经验规律：如果一个对象寿命比较长了，大概率还会活的更久(要被回收，早就被回收了)
例如许多东西都是短暂美好的，经过时间的洗礼，少数经典的东西才会被留下，哪些短暂的东西很短的时间就消逝了。
基于上述策略，就针对对象的年龄进行了分类，把堆里的对象分成了：新生代(年龄小的对象，GC扫描的频率较高)和老年代(年龄大的对象，GC扫描的频率较低)
刚创建出来的对象进入伊甸区
如果新对象熬过一轮GC，就通过复制算法，复制到生存区中，
生存区的对象也要经历GC的考研，每次熬过一轮GC，就通过复制算法拷贝到另一个生存区中，只要这个对象不消亡，就会在两个生存区中间来回拷贝，每一轮拷贝，每一轮GC都会少选掉一大波对象。即同一时间只用一个生存区。
如果一个对象在生存区中反复坚持了很多轮，还没事，就会进入老年代了。
如果对象来到了老年代，也不是完全的稳定，也会定期进行GC，只是频率更低了，这里采取标记整理的方式来处理老年代对象
上述规则还有个特殊情况!!!
如果对象是一个非常大的对象，则直接进入老年代!!!
解释：大对象进行复制算法开销太大，既然一个很大的对象，好不容易创造出来，看肯定不是立即就销毁的。
813
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
