JVM探究
双亲委派机制
Bootstrap classLoader:主要负责加载核心的类库(java.lang.*等),构造ExtClassLoader和APPClassLoader。
ExtClassLoader:主要负责加载jre/lib/ext目录下的一些扩展的jar。
AppClassLoader:主要负责加载应用程序的主函数类
- 类加载器收到类加载得请求!
- 将这个请求向上委托给父类得加载器去完成 一直是委托 知道启动类加载器
- 启动加载器类检查是否能够加载当前这个类 能加载就结束 使用当前得加载器 否则抛出异常 通知子加载器进行加载
- 重复步骤 3
当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器,首先会在AppClassLoader中检查是否加载过,如果有那就无需再加载了。如果没有,那么会拿到父加载器,然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过,如果没有再往上。注意这个类似递归的过程,直到到达Bootstrap classLoader之前,都是在检查是否加载过,并不会选择自己去加载。直到BootstrapClassLoader,已经没有父加载器了,这时候开始考虑自己是否能加载了,如果自己无法加载,会下沉到子加载器去加载,一直到最底层,如果没有任何加载器能加载,就会抛出ClassNotFoundException。那么有人就有下面这种疑问了?
为什么要设计这种机制
这种设计有个好处是,如果有人想替换系统级别的类:String.java。篡改它的实现,在这种机制下这些系统的类已经被Bootstrap classLoader加载过了(为什么?因为当一个类需要加载的时候,最先去尝试加载的就是BootstrapClassLoader),所以其他类加载器并没有机会再去加载,从一定程度上防止了危险代码的植入。
沙箱安全机制
NATIVE关键字
凡是带了native关键字 说明了java得作用范围达不到了 回去调用了 c 语言得库
会进入本地方法栈
调用本地方法本地接口 JNI
JNI作用 扩展java得使用 融合不同的编程语言为java所用
栈
先进后出
堆
垃圾回收是在堆内存中
主要是在伊甸区 (幸运1 区 幸运2区) 养老区
伊甸园 > 幸存区0 > 幸存区1 > 养老区 > 永久区
调优命令配置
-Xms8m -Xmx8m -XX:+PringGCDetails
java 代码
public class Demo2{
public static void main(String[] args){
//字节 1024*1024
long max = Runtime.getRuntime().maxMemory();
//返回jvm的初始化总内存
long total = Runtime.getRuntime().totalMemory();
//打印
System.out.println("max="+max+"字节\t"+(max/(double)1024/1024)+"MB");
System.out.prkntln("total"+max+"字节\t"+(total/(double)1024/1024)+"MB")
//默认情况下 分配内存是电脑的1/4 而初始化的内存:1/64
}
}
//OOM
//1 尝试扩大内存看结果
//2 分析内存 看一下那个地方出现问题(工具查看)
//-Xms1024m -Xmx1024m -XX:+PrintGCDetails
元空间 : 逻辑上存在 物理上不存在
在一个项目中 突然出现了OOM故障 那么该如何排除 研究为什么出错!~
- 能看到代码第几行出错 内存快照分析工具 MAT 、Jprofiler
- DeBug 一行行代码分析
MAT、Jprofiler
GC
复制算法
标记清除算法
总结
内存效率 :复制算法>标记清除算法>标记压缩算法(时间复杂度算法)
内存整齐度:复制算法 = 标记压缩算法 > 标记清除算法
内存利用率:标记压缩算法 = 标记 清除算法 > 复制算法
年轻代
- 存活率低
- 复制算法
老年代
- 区域大 存活率
- 标记清除(内存碎片不是太多)+ 标记压缩混合实现