- 1.JVM概述
- 2.JVM结构-类加载
- 3.JVM运行时数据区
- 4.本地方法接口
- 5.执行引擎
- 6.垃圾回收
1.JVM概述
栈内存和堆内存的区别
程序的内存分配
栈(stack):有编译器自动分配和释放,存放函数的参数、局部变量、临时变量、函数返回地址等;
堆(heap):一般有程序员分配和释放,如果没有手动释放,在程序结束时可能由操作系统自动释放(?这个可能针对Java那样的有回收机制的语言而说的,对于c/c++,这样的必须要手动释放开辟的堆内存),稍有不慎会引起内存泄漏。
2.申请后系统的响应
栈:只要栈的剩余空间大于所申请的空间,系统将为程序提供内存,否则将报异常提示栈溢出。
堆:在记录空闲内存地址的链表中寻找一个空间大于所申请空间的堆结点,然后将该结点从空闲结点链表中删除,并将该结点的空间分配给程序。另外,对于大多数系统会在这块内存空间的首地址出记录本次分配空间的大小,这样代码中的delete 才能正确释放本内存空间。系统会将多余的那部分重新空闲链表中。
3、申请大小限制
栈:在Windows下,栈是向低地址扩展的数据结构,是一块连续的内存的区域。这句话的意思是栈顶的地址和栈的最大容量是系统预先规定好的,在 WINDOWS下,栈的大小是2M(也有的说是1M,总之是一个编译时就确定的常数),如果申请的空间超过栈的剩余空间时,将提示overflow。因此,能从栈获得的空间较小。
堆:堆是向高地址扩展的数据结构,是不连续的内存区域。这是由于系统是用链表来存储的空闲内存地址的,自然是不连续的,而链表的遍历方向是由低地址向高地址。堆的大小受限于计算机系统中有效的虚拟内存。由此可见,堆获得的空间比较灵活,也比较大。
4、分配效率
栈:由系统自动分配,速度较快。但程序员是无法控制的。
堆:由new分配的内存,一般速度比较慢,而且容易产生内存碎片,不过用起来最方便. 另外,在WINDOWS下,最好的方式是用VirtualAlloc分配内存,不是在堆,也不是在栈是直接在进程的地址空间中保留一快内存,虽然用起来最不方便。但是速度快,也最灵活
5、存储内容
栈:在栈中,第一个进栈的是主函数下一条指令的地址,然后是函数的各个参数,在大多数编译器中,参数是由右往左入栈,然后是函数中的局部变量。注意,静态变量不入栈。出栈则刚好顺序相反。
堆:一般在堆的头部用一个字节存放堆的大小,具体内容由程序员安排。
1.3JVM的作用
java虚拟就是二进制字节码的运行环境,负责装在字节码到其内部,解释/编译为对应平台的机器码指令执行,每一条java指令,java虚拟机都有详细定义.怎么处理,结果放哪都有定义
特点:
- 一次编译到处运行
- 自动内存管理
- 自动垃圾回收功能
如今的JVM不仅可执行java字节码文件.其他的语言编译的字节码文件也可以在jvm上运行,是一个跨平台语言
1.5JVM的整体组成
- 类加载器ClassLoader
- 运行时数据区(Runtime Data Area)
- 执行引擎(Execution Engine)
- 本地库接口(Native Interface)
1.6各个组成的用途
先将.java文件转换为.class文件,jvm将字节码文件---------类加载器-------->内存的运行时数据区(由于字节码不能直接交给操作系统执行)----------执行引擎---------->字节码转为底层系统指令----------->CPU(这个过程需要调用本地库接口)
运行时数据区中的是Heap模块
1.8JVM架构模型
java编译器输入的指令流给予一种给予栈的指令集架构,另一种是基于寄存器的指令集架构
基于栈式架构的特点
- 设计实现简单,适用于资源受限的系统
- 使用领地址指令方式分配,执行过程依赖于操作栈,指令集更小,编译器容易实现
- 不需要硬件支持,可移植性好,更好实现跨平台
基于寄存器式架构特点
- 指令完全依赖于硬件,可移植性差
- 性能好,效率高
- 使用的指令更少
javap -v class//将.class文件反编译为指令集
由于跨平台设计,java指令集都是根据栈设计,不同cpu架构不同,所以不能设计为基于寄存器的
优点:跨平台,指令集小,编译器容易实现
缺点:性能低,同样的操作需要更多的指令
2.JVM结构-类加载
2.1类加载子系统的作用
类加载器子系统负责从文件系统加载.class文件,class文件有特定的文件标识(CA FE BA BE 开头)
ClassLoader负责class文件的加载,能否运行有执行引擎觉得.
加载的类信息放在方法区中,还可以存放运行时常量池信息,还可以包含字符串字面量和数字常量
2.2类加载ClassLoader的角色
- class file存在硬盘上,是一个模板在执行时加载到JVM中,然后根据模板实例化一个实例
- class file加载到jvm中,称为DNA元数据模板,放在方法区中
- .class–>JVM–>元数据模板,类加载器充当运输工具
2.3类加载过程
2.3.1加载
- 通过地址获取类的二进制字节流
- 将字节流代表的静态存储结构转换为方法区的运行时结构
- 内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类各种数据的访问入口
2.3.2链接
- 验证:检验被加载的类的内部结构是否正确,并调整和其他类协调一致
- 准备:准备阶段为类的静态属性分配内存,设置默认初始值;不包含用final修饰的static实例变量,在编译时进行初始化,不会为实例变量初始化
- 解析:将类的二进制数据中的符号引用替换成直接引用
2.3.3初始化
类什么时候初始化
- 创建实例对象时候
- 访问类或接口的静态变量或对静态变量赋值
- 调用类的静态方法
- 反射(Class.forName(""))
- 初始化一个类的子类(首先初始化子类的父类)
类的初始化顺序
父类 static –> 子类 static –> 父类构造方法- -> 子类构造方法
结论:
子类的静态变量和静态初始化块的初始化是在父类的变量、初始化块和构造器初始化之前就完成了;
静态变量、静态初始化块顺序取决于它们在类中出现的先后顺序
变量、初始化块初始化顺序取决于它们在类中出现的先后顺序
2.4类加载器的分类
JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器
常见的类加载器有三个:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0i2wKCWV-1638941124878)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618304052593.png)]
2.4.1引导类加载器(启动类加载器BootStrap ClassLoader)
- 使用C/C++语言实现,嵌套在JVM内部,加载java核心类库
- 不集成于java.lang.ClassLoader没有父加载器
- 负责加载扩展类加载器和应用类加载器,并为他们制定父类加载器
- 出于安全,只加载java,javax,sun等开头的类
2.4.2扩展类加载器(Extension ClassLoader)
- java语言编写,由sun.misc.Launcher$ExtClassLoader实现
- 派生于ClassLoader类
- 上层加载器为引用类加载器
- 从java.ext.dirs系统属性所指定 的目录中加载类库,或在JDK系统目录下的jre/lib/ext下加载类库,如果用户创建的jar放在此目录下.䧥自动由扩展类加载器加载
2.4.3应用程序类加载器(系统类加载器Application ClassLoader)
- java语言编写,由sun.misc.Launcher$AppClassLoader实现
- 派生于ClassLoader类
- 上层加载器为扩展加载器
- 加载用户定义的类
- 通过类名.classgetClassLoader(),ClassLoader.getSystemClassLoader()来获得
- ClassLoader类,是一个抽象类,其后所有的类加载器都继承自CLassLoader(不包括启动类加载器)
2.5双亲委派机制
JVM对class文件采用的是按需加载的方式,即需要改类时才会将class文件加载到内存中生成class对象,加载某个类的class文件,采用双亲委派模式,将请求交给父类处理
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BYXqxfgA-1638941124879)(C:\Users\XiaoEn\AppData\Roaming\Typora\typora-user-images\1632558517836.png)]
工作原理:
收到类加载请求,不会先加载,会将委托一层一层向上委托,直到没有父类加载器,若父类加载器完成任务就成功返回,若父类没有完成,又会返回给子类,若全部加载失败,抛出ClassNotFoundException异常
双亲委派优点:
- 安全,避免用户编写的类替换java的核心类,如java.lang.String
- 避免权限定命名的类重复加载(通过findLoadClass()判断当前类是否已加载)
如何打破双亲委派机制
重写loadclass方法,因为双亲委派机制的实现都是通过这个方法实现的,先找附加在其进行加载,如果父加载器无法加载再由自己来进行加载,源码里会直接找到根加载器,重写了这个方法以后就能自己定义加载的方式了
2.6沙箱安全机制
作用:防止恶意代码污染java源代码
例如:我们定义类为String的包也命名为java.lang,因为这个类属于jdk,若没有沙箱安全机制,该类就会污染系统中的String.
因为沙箱安全机制,就委托顶层的类加载器查找这个类,没有就委托扩展类加载器,还没有就委托系统类加载器.由于STring就是jdk源代码,所以引导加载器就加载到了,找到后使用,后面的一概不使用,保证了恶意代码污染
面试题
在jvm中如何判断两个对象是属于同一个类
- 类的全类名完全一致
- 类的加载器相同
2.7类的主动使用/被动使用
主动使用:
- 初始化类的new方式,导致类的加载并初始化
- 访问类的静态变量,包括读取和更新
- 访问类的静态方法
- 对类进行反射操作,导致类的初始化
- 初始化子类会导致父类的初始化
被动使用:
-
引用类的静态常量,不会导致初始化,常量指已经知道字面量的常亮,需要经过计算得到的常量还会导致初始化
-
构造某个类的数组时不会导致类的初始化
Student[] student = new Student[10];
主动使用和被动使用的区别在于类是否会被初始化
3.JVM运行时数据区
3.1运行时数据区组成概述
java8虚拟机规范规定,java虚拟机所管理的内存将会包含以下几个运行时数据区域:
3.1.1程序计数器(Program Counter Register)
程序计数器是一块较小的内存空间,可以看做是当前线程所执行的字节码的行号指示器
3.1.2java虚拟机栈(Java Virtual Machine Stacks)
描述的是java方法执行的内存模型,每个方法在执行的同时都会创建一个线帧用于存储局部变量表,操作数栈,单台连接,方法出口等信息,每个方法调用到执行完成的过程就是一个线帧在虚拟机栈中入栈出栈的过程
3.1.3本地方法栈(Native Method Stack)
与虚拟机栈的作用是一样的,只不过虚拟机栈是服务java方法的,而本地方法栈是虚拟机调用Native方法服务的
3.1.4java堆(Java Heap)
java虚拟机中内存最大的一块,被所有线程共享,在虚拟机启动时创建,java堆唯一的目的就是存放对象实例.
3.1.5方法区(Methed Area)
用于存储被虚拟机加载的类信息,常量,静态变量,即时变异后的代码等.
内存区域是硬盘和CPU的中间桥梁,承载着操作系统和应用程序的实时运行.
JVM内存布局规定了Java在运行过程中内存申请,分配,管理策略,保证JVM的高效稳定.
不同的JVM对内存的划分方式和管理机制存在着部分差异,以HotSpot虚拟机为例
**线程间共享:**堆,对外内存
**线程独立:**程序计数器,栈,本地方法栈
3.2程序计数器(Program Counter Register)
3.2.1概述
JVM中的程序计数寄存器中的Register命名来源于CPU寄存器,寄存器存储指令相关的现场信息,CPU只有把数据装在到寄存器才能运行.
3.2.2作用
程序计数器用来存储下一条指令的地址,由执行引擎读取下一条指令
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7FVzs5YT-1638941124880)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618316367157.png)]
- 他占很小的内存空间,也是运行速度最快的存储区域
- 每个线程都有自己的程序计数器,是线程私有的,生命周期和线程的生命周期一致
- 任何时间,一个线程只有一个方法执行,程序计数器存储当前方法的JVM指令地址,如果在执行native方法,则是未指定值(undefined)
- 他是程序控制流的指示器,分支,循环,跳转,异常处理,线程回复等基础功能都需要依赖这个计数器完成
- 字节码解释器工作时通过改变计数器的值来选取下一条需要执行的字节码指令
- 唯一一个在JVM中没有规定任何OutOfMemoryError情况的区域
程序计数器的作用位置
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2DWpUkL3-1638941124881)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618369369178.png)]
3.2.3面试题
-
使用程序计数器存储字节码指令地址有什么用?为什么使用程序计数器记录当前线程的执行地址呢?
因为CPU不停的切换各个线程,在切换回来时候,需要知道从哪个位置继续向下执行.
JVM的字节码解释器就需要通过改变程序计数器的值来明确下一条应该执行什么样的字节码指令
-
程序计数器为什么被设定为线程私有的
所谓的多线程 其实是在一段特定的时间执行其中一个线程,因为执行的时间段,PCU切换快,所以在用户看来就是多线程,在切换过程中必然导致中断或恢复,如何保障呢个分毫不差?
为了精确记录正在执行的字节码指令地址,最好的办法是为每一个线程分配一个程序计数器,这样每个线程都可以独立计算,互不干扰
3.3java虚拟机栈(Java Virtual Machine Stacks)
3.3.1虚拟机栈出现的背景
由于跨平台的设计,java的指令根据栈设计,不同平台CPU架构不同,所以设计为基于栈的指令设计
优点:跨平台,指令集小,编译器易实现
缺点:性能下降,同样的功能需要的指令集多
3.3.2分清栈和堆
**栈:**运行时单位,解决程序的运行问题
**堆:**存储的单位,解决数据存储的问题
3.3.3java虚拟机栈是什么
Java Virtual Machine Stack,也叫java栈,每个线程在创建时都会创建一个虚拟机栈,内部保存一个个的栈帧,对应一次方法的调用
Java虚拟机栈是线程私有的,生命周期和线程一样
3.3.4作用
主观Java程序的运行,保存局部变量(8中基本数据类型,对象的引用地址),部分结果,参与方法的调用和返回
3.3.5栈的特点
- 快速的分配存储方式,访问速度仅次于程序计数器
- JVM对java栈的操作有两种:调用方法,进栈----->执行结束,出栈
- 不存在垃圾回收问题
3.3.6栈中出现的异常
- StackOverflowError:线程请求的栈深度大于虚拟机所允许的深度
- OutOfMemoryError:如果虚拟机栈可以动态扩展,而扩展时无法申请到足够的内存
3.3.7栈中存储什么
每个线程都有自己的栈,栈的数据都以栈帧为单位存储
在这个线程正在执行的每一个方法都对应一个栈帧
栈帧是一个内存区块,是一个数据集,维系着方法执行过程中的各种数据信息
3.3.8栈的运行原理
- JVM对栈的操作:对栈帧的压栈和出栈,遵循"先进后出"原则
- 在一条活动的线程中的一个时间点上,只会有一个活动栈,即只有当前在执行的方法的栈帧是有效的,这个栈帧被称为当前帧,对应的方法叫做当前方法,定义方法的类叫当前类
- 执行引擎运行的所有字节码指令只针对当前栈帧进行操作
- 若在该方法中国调用其他方法,对应的新的栈帧就会创建出来,放在栈的顶端,成为新的当前栈帧
在一个栈中不可能引用另一个线程的栈帧(方法)
3.3.9栈帧的内部结构
局部变量表(Local Variables)
局部变量表十一组变量存储空间,存放方法参数和方法内部定义的局部变量.对于基本数据类型的变量,直接存储他的值,对于引用类型的变量,则存的是指向对象的引用
操作数栈(Operand Stack)或表达式栈
栈最典型的一个应用就是用来对表达式求值,一个线程执行方法的过程就是不断执行语句的过程,归根到底是进行计算的过程.程序中所有计算过程都是借助操作数栈来完成的
动态链接(Dynamic Linking)
在方法执行的过程中有可能需要用到类中的常量,所以必须有一个引用指向运行时常量
方法返回地址(Return Address)
当一个方法执行完毕后,要返回调用它的地方,因此在栈帧中必须保存一个方法返回地址
3.3.10面试题
-
什么情况会出现栈溢出?
方法执行时创建的栈帧超过了栈的深度,最优可能的就是方法递归调用产生这种结果
-
通过调整栈大小,就可以保证不出现溢出吗?
不能
-
分配的栈内存越大越好吗?
并不会,只能延缓这种现象的出现,可能会影响其他内存空间
-
垃圾回收机制会涉及到虚拟机栈吗
不会
3.4本地方法栈(Native Method Stack)
-
java虚拟机栈管理java方法的调用,本地方法栈用于管理本地方法的调用
-
本地方法栈线程私有
-
允许被实现成固定或者可动态扩展的内存大小,内存溢出方面也是相同的
若线程申请分配的栈容量超过本地方法栈允许的最大容量抛出StackOverflowError
若本地方法可以动态扩展,在扩展时无法申请到足够的内存抛出OutOfMemoryError
-
本地方法栈使用c语言编写
-
具体实现是在Native Method Stack中登记native方法,在Execution Engine执行时加载本地方法库
3.5java堆内存
3.5.1堆内存概述
-
一个JVM实例只存在一个堆内存,堆也是java内存管理的核心区域
-
java堆区在JVM启动时被创建,其空间大小也就被确定,是JVM管理的最大一块内存空间
-
堆内存大小可以调节
-Xms10m(堆起始大小) -Xmx30m(堆最大内存大小)
-
对在物理上是不连续的,在逻辑上应该被视为连续
-
所有的线程共享java堆,在这还可以划分线程私有的缓冲区
-
所有的对象实例都应在运行时分配在堆上
-
方法结束后,堆中的对象不会马上移除,仅仅垃圾收集的时候才会被移除
-
堆,是GC执行垃圾回收的重点区域
3.5.2对内存区域划分
Java8之后堆内存分为:新生区(新生代)+老年区(老年代)
新生区被分为Eden(伊甸园)区和Survivor(幸存者)区
3.5.3为什么分区
将对象根据存活概率分类,时间长的对象,放在固定区,减少扫描垃圾的时间及GC频率.针对不同的地区使用不同的回收算法,对算法扬长避短
3.5.4对象创建内存分配过程
为新对象分配内存是一件非常严谨和复杂的任务,不仅需要考虑内存如何分配,在哪分配等问题,由于内存分配算法与内存回收算法密切相关,所以还需要考虑 GC 执行完内存回收后是否会在内存空间中产生内存碎片.
- new 的新对象先放到伊甸园去,此区大小有限制
- 当伊甸园填满时,又需要创建对象,JVM 的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC),将不再被其他对象所引用的对象进行销毁.再加载新的对象放到伊甸园区.
- 然后将伊甸园区中的剩余对象移动到幸存者 s0 区
- 如果再次出发垃圾回收,此 时上次幸存下来存放到幸存者 s0 区的对象,如果没有回收, 就会被放到幸存者 s1 区,每次会保证有一个幸存者区是空的
- 如果再次经历垃圾回收,此时会重新放回幸存者 s0 区,接着再去幸存者 s1 区
- 默认是 15 次会存放在老年区,可以通过-XX:MaxTenuringThreshold=设置参数
- 老年区只有内存不够使才会触发GC:Major GC,进行养老区的内存清理
- 若养老区执行了 Major GC 之后发现依然无法进行对象保存,就会产生 OOM 异常. Java.lang.OutOfMemoryError:Java heap space
3.5.5新生区与老年区配置比例
配置新生代与老年代在堆结构的占比
- 默认**-XX:NewRatio**=2,表示新生代占 1,老年代占 2,新生代占整个堆的 1/3
- 可以修改**-XX:NewRatio**=4,表示新生代占 1,老年代占 4,新生代占整个堆的 1/5
- 当发现在整个项目中,生命周期长的对象偏多,那么就可以通过调整老年代的大小,来
进行调优
在 HotSpot 中,Eden 空间和另外两个 survivor 空间缺省所占的比例是 8 : 1 : 1,当然开发
人员可以通过选项**-XX:SurvivorRatio**调整这个空间比例。比如-XX:SurvivorRatio=8
新生区的对象默认生命周期超过 15 ,就会去养老区养老
3.5.6分带收集思想Minor GC,Major GC,Full GC
JVM在进行GC时,大部分是对新生区回收.针对HotSpot VM的实现,其中的GC按照回收区域分为两大类型:一种是部分收集,一种是整堆收集
**部分收集:**不是收集整个java堆的垃圾收集
- 新生区收集(Minor GC/Yong GC):只是新生区(Eden,s0,s1)的垃圾收集
- 老年区收集(Major GC/Old GC):只是老年区的垃圾收集
- 混合收集(Mixed GC):收集整个新生区以及老年区的垃圾
**整堆收集:**收集整个java堆和方法区的垃圾收集
整堆收集出现的情况:
System.gc();
老年区空间不足
方法区空间不足
3.5.7 TLAB机制
-
为什么会有TLAB(Thread Local Allocation Buffer)
堆区是线程共享的区域,任何线程都可以访问到堆区中的共享数据
由于对象实例创建在JVM中十分频繁,在并发环境下从堆区划分内存空间是线程不安全的
为避免多个线程操作同一个地址,需要使用加锁等机制,进而影响分配速度
-
什么是TLAB
全名Thread Local Allocation Buffer,线程本地分配缓存区
JVM使用TLAB避免多线程冲突,再给对象分配内存时,每个线程会有TLAB,避免线程同步,提高对象分配的效率
TLAB空间非常小,缺省情况下只占Eden的1%,通过-XX:TLABWasteTargetPercent设置占比
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lcf1F7lq-1638941124882)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618384821270.png)]
3.5.8堆空间的参数设置
官网地址:https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html -XX:+PrintFlagsInitial 查看所有参数的默认初始值
-XX:+PrintFlagsFinal 查看所有参数的最终值(修改后的值)
-Xms:初始堆空间内存(默认为物理内的 1/64)
-Xmx:最大堆空间内存(默认为物理内存的 1/4)
-Xmn:设置新生代的大小(初始值及最大值)
-XX:NewRatio:配置新生代与老年代在堆结构的占比
-XX:SurvivorRatio:设置新生代中 Eden 和 S0/S1 空间比例
-XX:MaxTenuringTreshold:设置新生代垃圾的最大年龄
-XX:+PrintGCDetails 输出详细的 GC 处理日志
3.5.9字符串常量池
字符串常量池为什么调整位置?
JDK7将字符串常量池放在堆空间中.因为永久代的回收效率低,在Full GC时才会执行垃圾回收,而Full GC是老年代空间不足,永久代不足时才会触发,导致StringTable回收效率不高,在开发中有大量的字符串被创建,回收效率低,导致永久代内存不足.放在堆里,能及时回收内存
3.6方法区
3.6.1方法区的基本理解
方法区,**是线程共享的内存区域.**主要存储加载的类字节码,class/method/field等元数据,static final常量,static 变量,即时编译器编译后的代码等数据.方法区包含一个特殊的区域"运行时常量池".
方法区看做一个独立于java堆的内存空间
方法区在JVM启动时创建,物理内存地址是不连续的
大小可以选择固定大小或者可扩展大小
若系统定义太多的类,导致方法区溢出,抛出异常java.lang.OutMenoryError:Metaspace
关闭 JVM 就会释放这个区域的内存.
方法区,栈,堆的交互关系
3.6.2方法区大小设置
- 元 数 据 区 大 小 可 以 使 用 参 数 -XX:MetaspaceSize 和-XX:MaxMataspaceSize 指定,替代上述原有的两个参数
- 默认值依赖于平台,windows 下,-XXMetaspaceSize 是 21MB
- -XX:MaxMetaspaceSize 的值是-1,级没有限制.
- 这个-XX:MetaspaceSize 初始值是 21M 也称为高水位线 一旦触及 就会触发 Full GC
- 因此为了减少 FullGC 那么这个-XX:MetaspaceSize 可以设置一个较高的值
3.6.3方法区的内部结构
方法区用于存储:被虚拟机加载的类型信息,常量,静态变量,即时编译器编译后的代码缓存,运行常量池
通过反编译字节码文件查看.
反编译字节码文件,并输出值文本文件中,便于查看。参数 -p 确保能查看private 权限类型的字段或方法
javap -v -p Demo.class > test.txt
3.6.4方法区的垃圾回收
-
方法区有垃圾收集行为,《Java虚拟机规范》提到对方法区的约束宽松,不要求虚拟机在方法区中实现垃圾收集
-
该区域的回收效果不好,在类型的卸载,条件苛刻,但是该区域的回收有时又是必须的
方法区的垃圾收集主要回收两部分内容:运行时常量池中废弃的常量和不再使用
的类型。
回收废弃常量与回收 Java 堆中的对象非常类似。(关于常量的回收比较简单,
重点是类的回收)
下面也称作类卸载
判定一个常量是否“废弃”还是相对简单,而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件:
- 该类所有的实例都已经被回收,也就是 Java 堆中不存在该类及其任何派生子
类的实例。 - 加载该类的类加载器已经被回收,这个条件除非是经过精心设计的可替换类加
载器的场景,如 OSGi、JSP 的重加载等,否则通常是很难达成的。 - 该类对应的 java.lang.Class 对象没有在任何地方被引用,无法在任何地方通
过反射访问该类的方法
4.本地方法接口
4.1什么是本地方法
**一个Native Method就是一个java调用非java代码的接口,**一个native method 是这样一个java方法:底层由非java语言实现
关键字 native 可以与其他所有的 java 标识符连用,但是 abstract 除外。
4.2为什么要使用Native Method
- 与java环境外交互:本地方法是交流机制:它为我们提供了一个非常简洁的接口,而且我们无需去了解 java 应用之外的繁琐细节
- 与操作系统交互(比如线程最后要回归于操作系统线程):JVM 支持着 java 语言本身和运行库,它是 java 程序赖以生存的平台,它由一个解释器(解释字节码)和一些连接到本地代码的库组成。如果我们要使用一些 java语言本身没有提供封装的操作系统特性时,我们也需要使用本地方法
- Sun`s Java: Sun 的解释器是用 C 实现的,这使得它能像一些普通的 C 一样与外部交互。jre
大部分是用 java 实现的,它也通过一些本地方法与外界交互。
5.执行引擎
5.1 概述
- 执行引擎是java虚拟机核心组成部分之一
- JVM 的主要任务是负责装载字节码到其内部,但字节码并不能够直接运行在操作系统之上,因为字节码指令并非等价于本地机器指令,它内部包含的仅仅只是一些能够被 JVM 所识别的字节码指令、符号表,以及其他辅助信息。
- JVM 中的执行引擎充当了将高级语言翻译为机器语言的译者
注意区分概念:
- 前端编译:从java程序员到字节码文件的过程
- 执行引擎有两种行为:一种是解释执行,一种是编译执行(后端编译)
5.2什么是解释器?什么是JIT编译器?
解释器:当Java虚拟机启动时会根据预定义的规范对字节码采用逐行解释的方法执行,将每条字节码文件"翻译"成对应平台的本地机器指令执行
**JIT编译器:**就是虚拟机将源代码一次性直接编译成和本地及其平台相关的机器语言,但并不是马上执行
5.3为什么Java是半编译半解释型语言?
JVM 设计者们的初衷仅仅只是单纯地为了满足 Java 程序实现跨平台特性,因此避免采用静态编译的方式由高级语言直接生成本地机器指令,从而诞生了实现解释器在运行时采用逐行解释字节码执行程序的想法。
解释器真正意义上所承担的角色就是一个运行时“翻译者”,将字节码文件中的内容“翻译”为对应平台的本地机器指令执行,执行效率低。
JIT 编译器将字节码翻译成本地代码后,就可以做一个缓存操作,存储在方法区的 JIT 代码缓存中(执行效率更高了)。
是否需要启动 JIT 编译器将字节码直接编译为对应平台的本地机器指令,则需要根据代码被调用执行的频率而定。JIT 编译器在运行时会针对那些频繁被调用的“热点代码”做出深度优化,将其直接编译为对应平台的本地机器指令,以此提升 Java 程序的执行性能。一个被多次调用的方法,或者是一-个方法体内部循环次数较多的循环体都可以被称之为“热点代码”。
目前 HotSpot VM 所采用的热点探测方式是基于计数器的热点探测
JIT编译器执行效率高为什么还需要解释器?
- 当程序启动后,解释器马上发挥作用,响应速度快,省去编译时间,立即执行
- 编译器想要发挥作用,把代码编译成本地代码,需要一定的执行时间,但编译为本地代码后,执行效率高,需要采用解释器与即时编译器并存的架构换取一个平衡点
6.垃圾回收
6.1垃圾回收概述
6.1.1概述
- Java 和 C++语言的区别,就在于垃圾收集技术和内存动态分配上,C++语言没有垃圾收集技术,需要程序员手动的收集
- 垃圾收集,不是 Java 语言的伴生产物。早在 1960 年,第一门开始使用内存动态分配和垃圾收集技术的 Lisp 语言诞生
- 关于垃圾收集有三个经典问题:
哪些内存需要回收?
什么时候回收?
如何回收? - 垃圾收集机制是 Java 的招牌能力,极大地提高了开发效率。
6.1.2什么是垃圾
垃圾是指在运行程序中没有任何指针指向的对象,这个对象就是需要被回收的垃圾.
如果不及时对内存中的垃圾进行清理,这些垃圾对象所占的内存空间会一直保留到应用程序结束。甚至可能导致内存溢出。
6.1.3为什么需要GC
- 对于高级语言来说,运行时不断地分配内存空间,若不进行回收,内存就会被消耗完
- 除了释放没用的对象,垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端,以便 JVM 将整理出的内存分配给新的对象
- 随着应用程序所应付的业务越来越庞大、复杂,用户越来越多,没有 GC就不能保证应用程序的正常进行
6.1.4早期垃圾回收
在早期的 C/C++时代,垃圾回收基本上是手工进行的。开发人员可以使用 new关键字进行内存申请,并使用 delete 关键字进行内存释放。
MibBridge *pBridge= new cmBaseGroupBridge();
//如果注册失败,使用 Delete 释放该对象所占内存区域
if(pBridge->Register(kDestroy)!=NO ERROR)
delete pBridge;
这种方式可以灵活控制内存释放的时间,但是会给开发人员带来频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收,那么就会产生内存泄漏,垃圾对象永远无法被清除,随着系统运行时间的不断增长,垃圾对象所耗内存可能持续上升,直到出现内存溢出并造成应用程序崩溃。
有了垃圾回收机制后,上述代码极有可能变成这样
MibBridge *pBridge=new cmBaseGroupBridge();
pBridge->Register(kDestroy);
6.1.5java垃圾回收机制
6.1.5.1自动内存管理
优点:无序开发人员手动参与内存的分配与回收,降低内存泄漏和内存溢出的风险
将程序员从繁重的内存管理中释放出来,专注于业务开发
6.1.5.2关于自动内存管理的担忧
- 过度依赖"自动",会严重弱化java开发人员在程序出现内存溢出时定位问题和解决问题的能力
- 了解 JVM 的自动内存分配和内存回收原理就显得非常重要,只有在真正了解 JVM 是如何管理内存后,我们才能够在遇见 OutofMemoryError 时,快速地根据错误异常日志定位问题和解决问题
- 当需要排查各种内存溢出、内存泄漏问题时,当垃圾收集成为系统达到更高并发量的瓶颈时,我们就必须对这些“自动化”的技术实施必要的监控和调节
6.1.5.3应该关心那些区域的回收
垃圾收集器对年轻代回收,对老年代回收,对全栈和方法区回收,对java堆重点回收
次数上讲:频繁收集Yong区,较少收集Old区,基本不收集元空间(方法区)
6.2垃圾回收相关算法
6.2.1垃圾标记阶段算法
6.2.1.1标记阶段的目的
垃圾标记阶段:主要是为了判断对象是否存活
- .堆里存放着几乎所有的 Java 对象实例,在 GC 执行垃圾回收之前,首先需要区分出内存中哪些是存活对象,哪些是已经死亡的对象。只有被标记为己经死亡的对象,GC 才会在执行垃圾回收时,释放掉其所占用的内存空间,因此这个过程我们可以称为垃圾标记阶段。
- 那么在 JVM 中究竟是如何标记一个死亡对象呢?简单来说,当一个对象已经不再被任何的存活对象继续引用时,就可以宣判为已经死亡
- 判断对象存活一般有两种方式:引用计数算法和可达性分析算法
6.2.1.2引用计数算法
- 引用计数算法(Reference Counting)比较简单,对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。
- 对于一个对象 A,只要有任何一个对象引用了 A,则 A 的引用计数器就加 1;当引用失效时,引用计数器就减 1。只要对象 A 的引用计数器的值为 0,即表示对象 A 不可能再被使用,可进行回收。
- 优点:实现简单,垃圾对象便于辨识;判定效率高,回收没有延迟性
- 缺点:增加了存储空间的开销。增加了时间开销。引用计数器有一个严重的问题,即无法处理循环引用的情况。这是一条致命缺陷,导致在.Java 的垃圾回收器中没有使用这类算法。
6.2.1.3可达性分析算法
可达性分析算法:也可以称为根搜索算法、追踪性垃圾收集
- 可达性分析算法具有与引用计数算法相同的实现简单和执行高效的特点,要有效的解决,引用计数算法中循环引用的问题,防止内存泄漏的发生
- 相较于引用计数算法,这里的可达性分析就是 Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集
可达性分析实现思路
所谓"GCRoots”根集合就是一组必须活跃的引用
- 可达性分析算法是以根对象集合(GCRoots)为起始点,按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
- 使用可达性分析算法后,内存中的存活对象都会被根对象集合直接或间接连接着,搜索所走过的路径称为引用链
- 如果目标对象没有任何引用链相连,则是不可达的,就意味着该对象己经死亡,可以标记为垃圾对象
- 在可达性分析算法中,只有能够被根对象集合直接或者间接连接的对象才是存活对象。
GC Roots 可以是哪些元素
- 虚拟机栈中引用的对象,线程被调用使用的参数,局部变量等
- 本地方法栈内JNI(本地方法)引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象(字符串常量池中的引用)
- 被synchronized持有的对象
- java虚拟机内部的引用(基 本 数 据 类 型 对 应 的 Class 对 象 , 一 些 常 驻 的 异 常 对 象 如 :NullPointerException、OutofMemoryError),系统类加载器)
总结:
- 除了堆空间的周边,比如:虚拟机栈,本地方法栈,方法区,字符串常量池堆堆空间进行引用,都可以作为GC Roots进行可达性分析
- 除了这些固定的 GC Roots 集合以外,根据用户所选用的垃圾收集器以及当前回收的内存区域不同,还可以有其他对象“临时性”地加入,共同构成完整 GCRoots 集合。比如:分代收集和局部回收
小技巧:
由于 Root 采用栈方式存放变量和指针,所以如果一个指针,它保存了堆内存里面的对象,但是自己又不存放在堆内存里面,那它就是一个 Root
6.2.1.4对象的finalization机制
finalize() 方法机制
对象销毁前的回调函数:finalize();
Java 语言提供了对象终止(finalization)机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。
当垃圾回收器发现没有引用指向一个对象,即:垃圾回收此对象之前,总会先调用这个对象的 finalize()方法。
finalize() 方法允许在子类中被重写,用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作,比如关闭文件、套接字和数据库连接等
永远不要主动调用某个对象的 finalize()方法,应该交给垃圾回收机制调用。理
由包括下面三点:
- 在 finalize()时可能会导致对象复活。
- .finalize()方法的执行时间是没有保障的,它完全由 GC 线程决定,极端情况下,若不发生 GC,则 finalize()方法将没有执行机会。
- 一个糟糕的 finalize()会严重影响 GC 的性能。比如 finalize 是个死循环。
6.2.1.5生存还是死亡?
由于 finalize()方法的存在,虚拟机中的对象一般处于三种可能的状态。
可触及的:从根节点开始,可以到达这个对象。
可复活的:对象的所有引用都被释放,但是对象有可能在 finalize()中复活。
不可触及的:对象的 finalize()被调用,并且没有复活,那么就会进入不可触及状态。不可触及的对象不可能被复活,因为 finalize()只会被调用一次。
具体过程
- 如果对象 objA 到 GC Roots 没有引用链,则进行第一次标记。
- 进行筛选,判断此对象是否有必要执行 finalize()方法
- 如果对象 objA 没有重写 finalize()方法,或者 finalize()方法已经被虚拟机调用过,则虚拟机视为“没有必要执行”,objA 被判定为不可触及的
- 如果对象 objA 重写了 finalize()方法,且还未执行过,那么 objA 会被插入到 F-Queue 队列中,由一个虚拟机自动创建的、低优先级的 Finalizer 线程触发其 finalize()方法执行。
- finalize()方法是对象逃脱死亡的最后机会,稍后 GC 会对 F-Queue 队列中的对象进行第二次标记。如果 objA 在 finalize()方法中与引用链上的任何一个对象建立了联系,那么在第二次标记时,objA 会被移出“即将回收”集合。之后,对象会再次出现没有引用存在的情况。在这个情况下,finalize()方法不会被再次调用,对象会直接变成不可触及的状态,也就是说,一个对象的 finalize()方法只会被调用一次。
6.2.2垃圾回收阶段算法
当成功区分出内存中存活对象和死亡对象后,GC 接下来的任务就是执行垃圾回收,释放掉无用对象所占用的内存空间,以便有足够的可用内存空间为新对象分配内存。目前在 JVM 中比较常见的三种垃圾收集算法是:
- 标记-清除算法(Mark-Sweep)
- 复制算法(Copying)
- 标记-压缩算法(Mark-Compact)
6.2.2.1标记-清除算法
执行过程
当堆中的有效内存空间(available memory)被耗尽的时候,就会停止整个程序(也被称为 stop the world),然后进行两项工作,第一项则是标记,第二项则是清除
标记:Collector 从引用根节点开始遍历,标记所有被引用的对象。一般是在对象的 Header 中记录为可达对象。(注意:标记的是被引用的对象,也就是可达对象,并非标记的是即将被清除的垃圾对象)。
清除:Collector 对堆内存从头到尾进行线性的遍历,如果发现某个对象在其 Header 中没有标记为可达对象,则将其回收
标记-清除算法的优点:
非常基础和常见的垃圾收集算法容易理解
标记-清除算法的缺点:
标记清除算法的效率不算高
在进行 GC 的时候,需要停止整个应用程序,用户体验较差
这种方式清理出来的空闲内存是不连续的,产生内碎片,需要维护一个空闲列表。(空闲列表-记录垃圾对象地址)。
注意:何为清除?
这里所谓的清除并不是真的置空,而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时,判断垃圾的位置空间是否够,如果够,就存放(也就是覆盖原有的地址)
6.2.2.2复制算法
为了解决标记-清除算法在垃圾收集效率方面的缺陷,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中,之后清除正在使用的内存块中的所有对象,交换两个内存的角色,最后完成垃圾回收
优点
没有标记和清除过程,实现简单,运行高效
复制过去以后保证空间的连续性,不会出现“碎片”问题。
缺点
此算法的缺点也是很明显的,就是需要两倍的内存空间。
对于 G1 这种分拆成为大量 region 的 GC,复制而不是移动,意味着 GC 需要维护 region 之间对象引用关系,不管是内存占用或者时间开销也不小
主要使用这种收集算法回收新生代
6.2.2.3标记-压缩算法
标记压缩算法执行过程
第一阶段和标记清除算法一样,从根节点开始标记所有被引用对象
第二阶段将所有的存活对象压缩到内存的一端,按顺序排放。之后,清理边界外所有的空间
标记-压缩算法与标记-清除算法的比较
标记-压缩算法的最终效果等同于标记-清除算法执行完成后,再进行一次内存碎片整理,因此,也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法。
二者的本质差异在于标记-清除算法是一种非移动式的回收算法(空闲列表记录位置),标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。
优点
消除了标记-清除算法当中,内存区域分散的缺点,我们需要给新对象分配内存时,JVM 只需要持有一个内存的起始地址即可。
消除了复制算法当中,内存减半的高额代价。
缺点
从效率上来说,标记-整理算法要低于复制算法。
移动对象的同时,如果对象被其他对象引用,则还需要调整引用的地址
移动过程中,需要全程暂停用户应用程序。即:STW
6.2.2.4垃圾回收算法小结
效率上复制算法最快,但是浪费太多内存
标记-整理算法相对来说更平滑一些,但是效率上不尽如人意,它比复制算法多了一个标记的阶段,比标记-清除多了一个整理内存的阶段。
6.2.2.5分代收集算法
为什么要使用分代收集算法
分代收集算法,是基于这样一个事实:不同的对象的生命周期是不一样的。因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率。一般是把Java 堆分为新生代和老年代,这样就可以根据各个年代的特点使用不同的回收算法,以提高垃圾回收的效率
年轻代(Young Gen)
年轻代特点:区域相对老年代较小,对象生命周期短、存活率低,回收频繁。
这种情况复制算法的回收整理,速度是最快的。复制算法的效率只和当前存活对象大小有关,因此很适用于年轻代的回收。而复制算法内存利用率不高的问题,通过 hotspot 中的两个 survivor 的设计得到缓解
老年代(Tenured Gen)
老年代特点:区域较大,对象生命周期长、存活率高,回收不及年轻代频繁。
这种情况存在大量存活率高的对象,复制算法明显变得不合适。一般是由标记- 清除或者是标记-清除与标记-整理的混合实现。
1.Mark 阶段的开销与存活对象的数量成正比。
2.Sweep 阶段的开销与所管理区域的大小成正相关。
3.Compact 阶段的开销与存活对象的数据成正比。
以 HotSpot 中的 CMS 回收器为例,CMS 是基于 Mark-Sweep 实现的,对于对象的回收效率很高。对于碎片问题,CMS 采用基于 Mark-Compact 算法的Serial Old 回收器作为补偿措施:当内存回收不佳(碎片导致的 ConcurrentMode Failure 时),将采用 Serial Old 执行 Full GC 以达到对老年代内存的整理。
6.2.2.6增量手机算法和分区算法
增量收集算法
上述现有的算法,在垃圾回收过程中,应用软件将处于一种 Stop the World 的状态。在 Stop the World 状态下,应用程序所有的线程都会挂起,暂停一切正常的工作,等待垃圾回收的完成。如果垃圾回收时间过长,应用程序会被挂起很久,将严重影响用户体验或者系统的稳定性。为了解决这个问题,即对实时垃圾收集算法的研究直接导致了增量收集(Incremental Collecting)算法的诞生。
增量收集算法基本思想
如果一次性将所有的垃圾进行处理,需要造成系统长时间的停顿,那么就可以让垃圾收集线程和应用程序线程交替执行。每次,垃圾收集线程只收集一小片区域的内存空间,接着切换到应用程序线程。依次反复,直到垃圾收集完成。总的来说,增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理,允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作
增量收集算法的缺点
虽然减少系统的停顿时间。但是,因为线程切换和上下文转换的消耗,会使得垃圾回收的总体成本上升,造成系统吞吐量的下降。
分区算法
一般来说,在相同条件下,堆空间越大,一次 GC 时所需要的时间就越长,有关GC 产生的停顿也越长。为了更好地控制 GC 产生的停顿时间,将一块大的内存区域分割成多个小块,根据目标的停顿时间,每次合理地回收若干个小区间,而不是整个堆空间,从而减少一次 GC 所产生的停顿。
分代算法将按照对象的生命周期长短划分成两个部分,分区算法将整个堆空间划分成连续的不同小区间。每一个小区间都独立使用,独立回收。这种算法的好处是可以控制一次回收多少个小区间。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TXrjdxEc-1638941124883)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618741267310.png)]
6.3垃圾回收相关概念
6.3.1System.gc()的理解
在默认情况下,通过 System.gc()者 Runtime.getRuntime().gc() 的调用,会显式触发 Full GC,同时对老年代和新生代进行回收,尝试释放被丢弃对象占用的内存。
JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况下,垃圾回收应该是自动进行的,无须手动触发,否则就太过于麻烦了。在一些特殊情况下,如我们正在编写一个性能基准,我们可以在运行之间调用System.gc()。
6.3.2内存溢出和内存泄漏
内存溢出
由于 GC 一直在发展,所有一般情况下,除非应用程序占用的内存增长速度非常快,造成垃圾回收已经跟不上内存消耗的速度,否则不太容易出现 OOM 的情况。
大多数情况下,GC 会进行各种年龄段的垃圾回收,实在不行了就放大招,来一次独占式的 Full GC 操作,这时候会回收大量的内存,供应用程序继续使用。Javadoc 中对 OutofMemoryError 的解释是,没有空闲内存,并且垃圾收集器也无法提供更多内存
内存泄漏
内存泄漏也称作“存储渗漏”。严格来说,只有对象不会再被程序用到了,但是 GC 又不能回收他们的情况,才叫内存泄漏。
尽管内存泄漏并不会立刻引起程序崩溃,但是一旦发生内存泄漏,程序中的可用内存就会被逐步蚕食,直至耗尽所有内存,最终出现 OutofMemory 异常,导致程序崩溃。
一些提供 close()的资源未关闭导致内存泄漏
数据库连接 dataSourse.getConnection(),网络连接 socket 和 io 连接必须手动 close,否则是不能被回收的。
6.3.3Stop the World
Stop-the-World,简称 STW,指的是 GC 事件发生过程中,会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停,没有任何响应,有点像卡死的感觉,这个停顿称为 STW。
可达性分析算法中枚举根节点(GC Roots)会导致所有 Java 执行线程停顿,为什么需要停顿所有 Java 执行线程呢?
- 分析工作必须在一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
- 如果出现分析过程中对象引用关系还在不断变化,则分析结果的准确性无法保
证 - 被 STW 中断的应用程序线程会在完成 GC 之后恢复,频繁中断会让用户感觉像是网速不快造成电影卡带一样,所以我们需要减少 STW 的发生。
- .STW 事件和采用哪款 GC 无关,所有的 GC 都有这个事件。
- 越优秀,回收效率越来越高,尽可能地缩短了暂停时间
STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下,把用户正
常的工作线程全部停掉。
6.3.4对象的引用
6.3.4.1概述
当内存空间还足够时,则能保留在内存中;如果内存空间在进行垃圾收集后还是很紧张,则可以抛弃这些对象
强引用(StrongReference):最传统的“引用”的定义,是指在程序代码之中普遍存在的引用赋值,即类似“object obj=new Object()”这种引用关系。无论任何情况下,只要强引用关系还存在,垃圾收集器就永远不会回收掉被引用的对象。宁可报 OOM,也不会 GC 强引用
软引用(SoftReference):在系统将要发生内存溢出之前,将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存,才会抛出内存溢出异常。
弱引用(WeakReference):被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时,无论内存空间是否足够,都会回收掉被弱引用关联的对象。
虚引用(PhantomReference):一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。
6.3.4.2强引用
当在 Java 语言中使用 new 操作符创建一个新的对象,并将其赋值给一个变量的
时候,这个变量就成为指向该对象的一个强引用。
只要强引用的对象是可触及的,垃圾收集器就永远不会回收掉被引用的对象。
只要强引用的对象是可达的,jvm 宁可报 OOM,也不会回收强引用
对于一个普通的对象,如果没有其他的引用关系,只要超过了引用的作用域或者显式地将相应(强)引用赋值为 null,就是可以当做垃圾被收集了
强引用是造成 Java 内存泄漏的主要原因之一
6.3.4.3软引用(Soft Reference):内存不足即回收
**软引用是用来描述一些还有用,但非必需的对象。**只被软引用关联着的对象,在系统将要发生内存溢出异常前,会把这些对象列进回收范围之中进行第二次回收,如果这次回收还没有足够的内存,才会抛出内存溢出异常。注意,这里的第一次回收是不可达的对象
软引用通常用来实现内存敏感的缓存。比如:高速缓存就有用到软引用。如果还有空闲内存,就可以暂时保留缓存,当内存不足时清理掉,这样就保证了使用缓存的同时,不会耗尽内存
Object obj = new Object();// 声明强引用
SoftReference<Object> sf = new SoftReference<>(obj);
obj = null; //销毁强引用
6.3.4.4弱引用(Weak Reference) 发现即回收
弱引用也是用来描述那些非必需对象,只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统 GC 时,只要发现弱引用,不管系统堆空间使用是否充足,都会回收掉只被弱引用关联的对象。
// 声明强引用
Object obj = new Object();
WeakReference<Object> sf = new WeakReference<>(obj);
obj = null; //销毁强引用
弱引用对象与软引用对象的最大不同就在于,当 GC 在进行回收时,需要通过算法检查是否回收软引用对象,而对于弱引用对象,GC 总是进行回收。弱引用对象更容易、更快被 GC 回收
6.3.4.5引用(Phantom Reference)对象回收跟踪
也称为“幽灵引用”或者“幻影引用”,是所有引用类型中最弱的一个
一个对象是否有虚引用的存在,完全不会决定对象的生命周期。如果一个对象仅持有虚引用,那么它和没有引用几乎是一样的,随时都可能被垃圾回收器回收。它不能单独使用,也无法通过虚引用来获取被引用的对象。当试图通过虚引用的get()方法取得对象时,总是 null 。
虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时,如果发现它还有虚引用,就会在回收对象后,将这个虚引用加入引用队列,以通知应用程序对象的回收情况。
// 声明强引用
Object obj = new Object();
// 声明引用队列
ReferenceQueue phantomQueue = new ReferenceQueue();
// 声明虚引用(还需要传入引用队列)
PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);
obj = null;
6.4垃圾回收器
6.4.1垃圾回收器概述
垃圾收集器没有在规范中进行过多的规定,可以由不同的厂商、不同版本的JVM 来实现。
由于 JDK 的版本处于高速迭代过程中,因此 Java 发展至今已经衍生了众多的 GC 版本。
从不同角度分析垃圾收集器,可以将 GC 分为不同的类型。
6.4.2垃圾回收器分类
按线程数分,可以分为串行垃圾回收器和并行垃圾回收器。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GbZgLt45-1638941124884)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618748161570.png)]
串行回收指的是在同一时间段内只允许有一个 CPU 用于执行垃圾回收操作,此时工作线程被暂停,直至垃圾收集工作结束。
和串行回收相反,并行收集可以运用多个 CPU 同时执行垃圾回收,因此提升了应用的吞吐量,不过并行回收仍然与串行回收一样,采用独占式,使用"stop-the-world"机制。
按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器。
并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间
独占式垃圾回收器(stop the world)一旦运行,就停止应用程序中的所有用户线程,直到垃圾回收过程完全结束。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9EfNNOB4-1638941124886)(C:\Users\17509\AppData\Roaming\Typora\typora-user-images\1618748370755.png)]
按工作的内存区间分,又可分为年轻代垃圾回收器和老年代垃圾回收器。
6.4.3 GC性能指标
吞吐量:运行用户代码的时间占总运行时间的比例(总运行时间:程序的运行时间+内存回收的时间)
垃圾收集开销:垃圾收集所用时间与总运行时间的比例。
暂停时间:执行垃圾收集时,程序的工作线程被暂停的时间。
收集频率:相对于应用程序的执行,收集操作发生的频率。
内存占用:Java 堆区所占的内存大小。
快速:一个对象从诞生到被回收所经历的时间
6.4.4 HotSpot垃圾收集器
串行回收器:Serial,Serial old
并行回收器:ParNew,Parallel scavenge,Parallel old
并发回收器:CMS、G1
新生代收集器:Serial,ParNew.Parallel scavenge;
老年代收集器:Serial old.Parallel old.cMS;
整堆收集器:G1;
6.4.4.1 Serial 垃圾收集器(单线程)
只开启一条 GC 线程进行垃圾回收,并且在垃圾收集过程中停止一切用户线程(Stop The World)
一般客户端应用所需内存较小,不会创建太多对象,而且堆内存不大,因此垃圾收集器回收时间短,即使在这段时间停止一切用户线程,也不会感觉明显卡顿。因此 Serial 垃圾收集器适合客户端使用。
由于 Serial 收集器只使用一条 GC 线程,避免了线程切换的开销,从而简单高效
6.4.4.2 ParNew 垃圾收集器(多线程)
ParNew 是 Serial 的多线程版本。由多条 GC 线程并行地进行垃圾清理。但清理过程依然需要 Stop The World。
ParNew 追求“低停顿时间”,与 Serial 唯一区别就是使用了多线程进行垃圾收集,在多 CPU 环境下性能比 Serial 会有一定程度的提升;但线程切换需要额外的开销,因此在单 CPU 环境中表现不如 Serial。
6.4.4.3 Parallel Scavenge 垃圾收集器(多线程)
Parallel Scavenge 和 ParNew 一样,都是多线程、新生代垃圾收集器。但是两者有巨大的不同点:
Parallel Scavenge:追求 CPU 吞吐量,能够在较短时间内完成指定任务,因此适合没有交互的后台计算。
ParNew:追求降低用户停顿时间,适合交互式应用。
吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)
追求高吞吐量,可以通过减少 GC 执行实际工作的时间,然而,仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做,因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成,从而导致更高的暂停时间。而考虑到低暂停时间,最好频繁运行 GC 以便更快速完成,反过来又导致吞吐量下降。
6.4.4.4 Serial Old 垃圾收集器(单线程)
Serial Old 收集器是 Serial 的老年代版本,都是单线程收集器,只启用一条 GC线程,都适合客户端应用。它们唯一的区别就是:Serial Old 工作在老年代,使用“标记-整理”算法;Serial 工作在新生代,使用“复制”算法。
6.4.4.5 Parallel Old 垃圾收集器(多线程)
Parallel Old 收集器是 Parallel Scavenge 的老年代版本,追求 CPU 吞吐量。
6.4.4.6 CMS回收器(低延迟)
CMS:Concurrent Mark Sweep ,并发标记清除.
CMS是使用标记清除算法进行垃圾回收的
以获取最短回收停顿时间为目标的收集器,**在垃圾收集时是用户线程和GC线程并发执行,**所以在垃圾收集时用户并不会感到明显的卡顿
**初始标记:**Stop The World,仅使用一条初始标记线程对所有与GC ROOTS直接关联的对象进行标记
并发标记:使用多线标记线程,与用户线程并发执行.此过程可进行可达性分析,标记废弃对象
**重新标记:**Stop The World 使用多条标记线程并发执行,将并发标记过程新出现的废弃对象标记出来
**并发清除:**只是用一条GC线程,与用户线程并发执行,清除标记的对象,此过程非常耗时
并发标记与并发清除过程耗时最长,且可以与用户线程一起工作,因此,总体上说,CMS 收集器的内存回收过程是与用户线程一起并发执行的。
优点:
并发收集,低延迟
缺点:
- 产生内存碎片,导致并发清除后,用户线程可用的空间不足
- CMS收集器对CPU资源非常敏感,并发阶段,会占用一部分线程导致应用程序变慢,总吞吐量降低
- CMS收集器无法处理浮动垃圾.可能出现"Concurrent Mode Failure"失败而导致另一次 Full GC 的产生。
- G1(Garbage First)回收器
三色标记
将对象的标记过程分为三种颜色:白色、灰色、黑色。
- 白色:对象的默认颜色,从GC Root开始扫描,如果是不可达对象的话就是白色,也就是垃圾对象,在并发清理的时候会清理掉。
- 灰色:当前对象已经被扫描过,但是当前对象所依赖到的其他对象还没有被扫描。
- 黑色:当前对象和他所依赖的对象都已经被扫描过。
为什么要发布Garbage First GC
- 最主要的应用是需要低GC延迟,并具有大堆的应用程序提供解决方案。
原因就在于应用程序所应对的业务越来越庞大、复杂,用户越来越多,没有GC 就不能保证应用程序正常进行,而经常造成 STW 的 GC 又跟不上实际的需求,所以才会不断地尝试对 GC 进行优化。G1(Garbage-First)垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器,是当今收集器技术发展的最前沿成果之一.
与此同时,为了适应现在不断扩大的内存和不断增加的处理器数量,进一步降低暂停时间(pause time),同时兼顾良好的吞吐量。
为什么叫做G1呢?
G1是一个并行回收器,将堆内存分割为不相关的区域,使用不同的Region来表示Eden,s0,s1区,老年区
G1跟踪各个Region里面的垃圾堆积的价值大小(回收获得空间大小和回收所需时间),在后台维护优先列表,每次根据循序的收集时间,优先回收价值最大的Region
由于侧重回收垃圾最大量的区间,所以叫垃圾优先
G1(Garbage-First)是一款面向服务端应用的垃圾收集器,主要针对配备多核 CPU 及大容量内存的机器,以极高概率满足 Gc 停顿时间的同时,还兼具高吞吐量的性能特征。
从整体上看,G1 是基于“标记-整理”算法实现的收集器,从局部(两个 Region之间)上看是基于“复制”算法实现的,这意味着运行期间不会产生内存空间碎片。
问题:一个对象和它内部所引用的对象可能不在同一个 Region 中,那么当垃圾回收
时,是否需要扫描整个堆内存才能完整地进行一次可达性分析
并不!
每个 Region 都有一个 Remembered Set,用于记录本区域中所有对象引用的对象所在的区域,进行可达性分析时,只要在 GC Roots 中再加上Remembered Set 即可防止对整个堆内存进行遍历。
G1 收集器的工作过程分为以下几个步骤
初始标记:Stop The World,仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
并发标记:使用一条标记线程与用户线程并发执行。此过程进行可达性分析,速度很慢。
最终标记:Stop The World,使用多条标记线程并发执行。
筛选回收:回收废弃对象,此时也要 Stop The World,并使用多条筛选回收线程并发执行。
在下面的情况时,使用G1可能比CMS好:
- 超过50%的Java堆被活动数据占用
- 对象分配频率或年代提升频率变化很大
- GC停顿时间过长(长于0.5至1秒)