JVM困惑问题记录
JVM困惑问题记录
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类概述与实例