JVM困惑问题记录
- OopMap,安全点,安全区域的理解
- ClassLoader---类加载器资料整理
OopMap,安全点,安全区域的理解
目前主流虚拟机使用的都是准确式垃圾收集,即Exact VM
- oopMap
oop (ordinary object pointer) 普通对象指针,oopmap就是存放这些指针的map,OopMap 用于枚举 GC Roots,记录栈中引用数据类型的位置。迄今为止,所有收集器在根节点枚举这一步骤都是必须暂停用户线程的,
收集线程会对栈上的内存进行扫描,看看哪些位置存储了Reference类型。如果发现某个位置确实存的是Reference类型,它所引用的对象这一次不能被回收。问题是,栈上的本地变量表里面只有一部分数据是Reference类型的,那些非Reference类型的数据对我们而言毫无用途,但我们还是不得不堆整个栈全部扫描一遍,这是对时间和资源的一种浪费。
一个很自然的想法时,能不能用空间换时间,把栈上代表的引用的位置全部记录下来,这样到真正gc的时候就可以直接读取,而不用再一点一点的扫描了,Hotspot就是实现的。它使用一种叫做OopMak的数据结构来记录这类信息。
一个线程为一个栈,一个栈由多个栈桢组成,一个栈桢对应一个方法,一个方法有多个安全点。GC发生时,程序首先运行到最近的一个安全点停下来,然后更新自己的OopMap,记录栈上哪些位置代表着引用。枚举根节点时,递归遍历每个栈桢的OopMap ,通过栈中记录的被引用的对象内存地址,即可找到这些对象(GC Roots)
总结oopMap的作用
- 可以避免全栈扫描,加快枚举根节点的速度
- 可以帮助HotSpot实现准确式GC
- 安全点
通过oopMap 可以快速进行GCROOT枚举,但是随着而来的又有一个问题,就是在方法执行的过程中, 可能会导致引用关系发生变化,那么保存的OopMap就要随着变化。如果每次引用关系发生了变化都要去修改OopMap的话,这又是一件成本很高的事情。所以这里就引入了安全点的概念。
并不需要一发生改变就去更新这个映射表。只要这个更新在GC发生之前就可以了。所以OopMap只需要在预先选定的一些位置上记录变化的OopMap就行了。这些特定的点就是SafePoint(安全点)。由此也可以知道,程序并不是在所有的位置上都可以进行GC的,只有在达到这样的安全点才能暂停下来进行GC。
安全点太少,会让GC等待的时间太长,太多会浪费性能
上面这句话摘抄至深入理解JVM虚拟机第三版
如何让程序在要进行GC的时候都跑到最近的安全点上停顿下来,1.抢断式中断,2.主动式中断,目前都是主动式,设置一个标志,当程序运行到安全点时就去轮训该位置,发现该位置被设置为真时就自己中断挂起
- 安全区域
安全点的使用似乎解决了OopMap计算的效率的问题,但是这里还有一个问题。安全点需要程序自己跑过去,那么对于那些已经停在路边休息或者看风景的程序(比如那些处在Sleep或者Blocked状态的线程),他们可能并不会在很短的时间内跑到安全点去。所以这里为了解决这个问题,又引入了安全区域的概念。
安全区域很好理解,就是在程序的一段代码片段中并不会导致引用关系发生变化,也就不用去更新OopMap表了,那么在这段代码区域内任何地方进行GC都是没有问题的。这段区域就称之为安全区域。线程执行的过程中,如果进入到安全区域内,就会标志自己已经进行到安全区域了。那么虚拟机要进行GC的时候,就不会管这些已经运行到安全区域的线程,当线程要脱离安全区域的时候,要自己检查系统是否已经完成了GC或者根节点枚举(这个跟GC的算法有关系),如果完成了就继续执行,如果未完成,它就必须等待收到可以安全离开安全区域的Safe Region的信号为止。
ClassLoader—类加载器资料整理
classpath和jar
URLClassLoader使用以及特性详解
一看你就懂,超详细java中的ClassLoader详解
java中使用URLClassLoader访问外部jar包的java类
Java —— URLStreamHandler
URI类与URL类概述与实例