JVM面试总结
Posted 肖帆咪
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JVM面试总结相关的知识,希望对你有一定的参考价值。
- 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)
以上是关于JVM面试总结的主要内容,如果未能解决你的问题,请参考以下文章