JVM基础 + 垃圾回收算法入门

叁歲伎倆 2022-09-17 03:12 141阅读 0赞

# JVM基础 #

根据《Java 虚拟机规范(Java SE 7 版)》规定，Java 虚拟机所管理的内存如下图所示。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16]

*  局部变量表：存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)
 *  StackOverflowError：线程请求的栈深度大于虚拟机所允许的深度。
 *  OutOfMemoryError：如果虚拟机栈可以动态扩展，而扩展时无法申请到足够的内存。
 *  **java堆**  
    是java虚拟机中占用内存最大的一块，他是线程共享的一块内存，在虚拟机启动时创建，此区域唯一的目的就是放置对象的实例，几乎所有的对象实例都是在这里分配内存，java堆是**垃圾回收器**的主要区域，也被称作为**GC堆**，可处于物理内存不了连续的空间

# 引用 #

*  **强引用**（StrongReference）  
    强引用是指在代码中普遍存在的Object obj =new Object（），这类的引用有引用变量指向时，永远不会被垃圾回收，JVM宁可抛出OutofMemory也不会回收这种对象，如果想中断某个强引用和对象的之间的联系，可以将引用赋值为null。
 *  **软引用**（SoftReference）  
    用来描述一些有用但非必须的对象，对于软引用关联着的对象，在系统发生内存溢出之前，会把这些对象列入回收范围之内，进行二次回收，如果这次回收还没有足够内存，才会抛出内存溢出异常，软引用经常用于内存敏感的高速缓存，比如，网页缓存，图片缓存，防止内存泄漏，增强代码的健壮性。

Object o = new Object();
     SoftReference<Object> softReference = new SoftReference<Object>(o);
     //如果设置 o=null，如果软引用没有被回收依然可以通过获取object对象
     Object o1 = softReference.get();

*  **弱引用**（WeakReference）  
    表示非必须的对象，不管内存是否充足，都会回收该对象  
    只要JVM进行垃圾回收，被弱引用关联的对象必定会被回收掉。不过要注意的是，这里所说的被弱引用关联的对象是指只有弱引用与之关联，如果存在强引用同时与之关联，则进行垃圾回收时也不会回收该对象（软引用也是如此）。
 *  **虚引用**（PhontomReference）  
    虚引用和前面的软引用、弱引用不同，它并不影响对象的生命周期。在java中用java.lang.ref.PhantomReference类表示。在任何时候都可能被垃圾回收器回收。

# 垃圾回收算法 #

*  **标记-清除算法**  
    该算法分为标记和清除俩个阶段，首先要标记出需要回收的各个对象，在标记完成后统一回收被标记的对象，  
    缺点
    
     *  效率问题：标记清除俩个过程效率都不是很高
     *  空间问题：会产生大量的不连续空间  
        \-![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 1]
 *  **复制算法**  
    把空间分成两块，每次只对其中一块进行 GC。当这块内存使用完时，就将还存活的对象复制到另一块上面。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 2]

*  **标记整理算法**  
    根据老年代存活率特别高的特点，又提出一种 标记整理的算法，标记过程和“标记清除” 一样，但后续步骤不是对可回收对象进行清理，而是让所有存活的对象，向一端移动，然后直接清理掉端以外的内存。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 3]
 *  **分代收集算法**  
    当前虚拟机大部分采用，分代收集算法，这种算法并没有特别思想，只是根据对象的存活周期不同把内存划分为几块，一般是把java堆分为新生代和老年代，这样就可以根据年代的特点采用不同的算法，提高效率。  
    **新生代每次垃圾回收都会有大量的对象死去，少量存活，那就用复制算法；  
    老年代存活率较低，那就使用标记-清除，或标记-整理法**  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 4]
 *  新生代（Young Generation）  
    大多数对象在新生代中创建，其中很多对象的生命周期很短，每次新生代的垃圾回收（又称 Minor GC），只有少量对象存活，所以选择复制算法，因为少量的复制成本就可以完成  
    新生代又分为三个区，一个Eden区，两个Survivor区（一般而言），大部分对象在Eden区中生成，当Eden区满了之后，还存活的对象复制到Survivor区中的一个，当这个Survivor区满了之后，此区存活但不满足晋升条件的对象，复制到另一个Survivor区，对象每一次Minor GC年龄加一，达到年龄的阈值后，晋升老年区，**默认的阈值为15岁**
 *  老年代（Old Generation）  
    新生代经历n次垃圾回收，还存活的对象就会被放到老年代，此区域中对象存活率高，老年代的垃圾回收，通常用标记清理和标记整理的方法，整堆包括新生代和老年代的垃圾回收称为Full GC
 *  永久代（Perm Generation）  
    主要存放元数据，如Class何Method的元数据，与垃圾回收对象的关系不大，相对于新生代和老年代来说，该区划分对垃圾回收影响较小

参考：[Java虚拟机（JVM）你只要看这一篇就够了][Java_JVM]  
[JVM的内存区域和垃圾回收机制][JVM]

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/ab378ec6149d44d5997e3fc4b58a56ef.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/87c0fa5e1bfa436297abc63d0ddd7a42.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/a0b136412a954fe8bff4610fae9b454e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/e22e5b1e76c342a885b21276df6337cf.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiN5Yeh6ICM5aSn57Gz44CB_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/5ea289c9828a44f1991645ee04d18275.png
[Java_JVM]: https://blog.csdn.net/qq_41701956/article/details/81664921
[JVM]: https://blog.csdn.net/qq_34760508/article/details/80930508