JVM学习笔记


垃圾回收99%都在堆里面,正常不可能在java栈、本地方法栈、程序计数器中。

JVM体系结构

  1. jvm的位置

在操作系统之上,包含在jre里。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V7a6WCGY-1609695316107)(D:/work/1921676-20201007094926264-668681814.png)]

栈、本地方法栈、程序计数器不会发生gc。

jvm调优主要在堆,方法区有一小部分。

类加载器

类是一个模板是抽象化的,而对象是具体的实例。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WZJLS27S-1609695316112)(D:/work/image-20210101230232511.png)]

作用:加载.class文件。(保障安全)

新建的对象放入堆里面,引用(地址)放到栈,其中引用指向堆里面对应的对象。

  1. 虚拟机自带的加载器
  2. 启动类(根)加载器 Bootstrap ClassLoader
  3. 扩展类加载器 Extension ClassLoader
  4. 应用程序(系统类)加载器 Application ClassLoader
  5. 自定义加载器

双亲委派机制

向上委托向下递归派遣

  1. 类加载器收到类加载的请求
  2. 将这个请求向上委托给父类加载器去完成,一直向上委托,直到启动类加载器
  3. 启动类加载器检查是否能够加载当前这个类,能加载就结束,使用当前的加载器,否则,抛出异常,通知子加载器进行加载
  4. 重复步骤3
  5. 常见错误 Class not Found 找不到加载类去加载这个请求。

沙箱安全机制

Java安全模型的核心就是Java沙箱(sandbox) ,  什么是沙箱?沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机(JVM)特定的运行范围中,并且严格限制代码对本地系统资源访问,通过这样的措施来保证对代码的有效隔离,防止对本地系统造成破坏。  沙箱主要限制系统资源访问,那系统资源包括什么? CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。  所有的Java程序运行都可以指定沙箱,可以定制安全策略。  在Java中将执行程序分成本地代码和远程代码两种,本地代码默认视为可信任的,而远程代码则被看作是不受信的。对于授信的本地代码,可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中,安全依赖于沙箱Sandbox)机制。如下图所示JDK1.0安全模型 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XqBdvbiN-1609695316120)(D:/work/20200714083918143.png)]

图 JDK1.0安全模型

但如此严格的安全机制也给程序的功能扩展带来障碍,比如当用户希望远程代码访问本地系统的文件时候,就无法实现。因此在后续的Java1.1版本中,针对安全机制做了改进,增加了安全策略,允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oBnZYcAN-1609695316122)(D:/work/20200714084054727.png)]

图 JDK1.1安全模型

在Java1.2版本中,再次改进了安全机制,增加了代码签名。不论本地代码或是远程代码,都会按照用户的安全策略设定,由类加载器加载到虚拟机中权限不同的运行空间,来实现差异化的代码执行权限控制。如下图所示 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GqeUZUwM-1609695316124)(D:/work/20200714084127482.png)]

图 JDK1.2安全模型

当前最新的安全机制实现,则引入了域(Domain)的概念。虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责与关键资源进行交互,而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域(Protected Domain),对应不一样的权限(Permission)。存在于不同域中的类文件就具有了当前域的全部权限,如下图所示最新的安全模型(jdk 1.6) [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C12f5Hua-1609695316128)(D:/work/20200714084152611.png)]

图 JDK1.6安全模型

组成沙箱的基本组件

●字节码校验器(bytecode verifier) :确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验,比如核心类。 ●类裝载器(class loader) :其中类装载器在3个方面对Java沙箱起作用   它防止恶意代码去干涉善意的代码;   它守护了被信任的类库边界;   它将代码归入保护域,确定了代码可以进行哪些操作。  虚拟机为不同的类加载器载入的类提供不同的命名空间,命名空间由一系列唯一的名称组成, 每一个被装载的类将有一个名字,这个命名空间是由Java虚拟机为每一个类装载器维护的,它们互相之间甚至不可见。  类装载器采用的机制是双亲委派模式。  1.从最内层JVM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用;  2.由于严格通过包来区分了访问域,外层恶意的类通过内置代码也无法获得权限访问到内层类,破坏代码就自然无法生效。 ●存取控制器(access controller) :存取控制器可以控制核心API对操作系统的存取权限,而这个控制的策略设定,可以由用户指定。 ●安全管理器(security manager) : 是核心API和操作系统之间的主要接口。实现权限控制,比存取控制器优先级高。 ●安全软件包(security package) : java.security下的类和扩展包下的类,允许用户为自己的应用增加新的安全特性,包括:   安全提供者   消息摘要   数字签名   加密   鉴别

Native

  • native :凡是带了native关键字的,说明java的作用范围达不到了,回去调用底层c语言的库!
  • 会进入本地方法栈
  • 调用本地方法本地接口 JNI (Java Native Interface)
  • JNI作用:开拓Java的使用,融合不同的编程语言为Java所用!最初: C、C++
  • java诞生的时候C、C++横行,想要立足,必须要有调用C、C++的程序
  • 它在内存区域中专门开辟了一块标记区域: Native Method Stack,登记native方法
  • 在最终执行的时候,加载本地方法库中的方法通过JNI
  • 例如:Java程序驱动打印机,管理系统,掌握即可,在企业级应用比较少
  • private native void start0(); (java的作用到达不了c、c++层面,java的处理过程就是先进入本地方法栈,本地方法栈通过JNI去调用本地方法库就是是其他语言的代码。)
  • 现在在企业开发中我们通常调用其他接口:Socket. . WebService~. .http~

本地方法栈

它的具体做法是Native Method Stack中登记native方法,在( Execution Engine )执行引擎执行的时候加载Native Libraies。[本地库]

本地方法接口

本地接口的作用是融合不同的编程语言为Java所用,它的初衷是融合C/C++程序, Java在诞生的时候是C/C++横行的时候,想要立足,必须有调用C、C++的程序,于是就在内存中专门开辟了块区域处理标记为native的代码,它的具体做法是在Native Method Stack 中登记native方法,在( Execution Engine )执行引擎执行的时候加载Native Libraies。

目前该方法使用的越来越少了,除非是与硬件有关的应用,比如通过Java程序驱动打印机或者Java系统管理生产设备,在企业级应用中已经比较少见。因为现在的异构领域间通信很发达,比如可以使用Socket通信,也可以使用Web Service等等,不多做介绍!

java栈

线程私有,生命周期和线程一致。描述的是 Java 方法执行的内存模型:每个方法在执行时都会创建一个栈帧(Stack Frame)用于存储局部变量表操作数栈动态链接方法出口等信息。每一个方法从调用直至执行结束,就对应着一个栈帧从虚拟机栈中入栈到出栈的过程。

局部变量表:存放了编译期可知的各种基本类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型)和 returnAddress 类型(指向了一条字节码指令的地址)

  • StackOverflowError:线程请求的栈深度大于虚拟机所允许的深度。
  • OutOfMemoryError:如果虚拟机栈可以动态扩展,而扩展时无法申请到足够的内存。

PC寄存器

程序计数器: Program Counter Register

每个线程都有一个程序计数器,是线程私有的,就是一个指针, 指向方法区中的方法字节码(用来存储指向像一条指令的地址, 也即将要执行的指令代码),在执行引擎读取下一条指令, 是一个非常小的内存空间,几乎可以忽略不计

Method Area

方法区是被所有线程共享,所有字段和方法字节码,以及一些特殊方法,如构造函数,接口代码也在此定义,简单说,所有定义的方法的信息都保存在该区域,此区域属于共享区间;

静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中,但是实例变量存在堆内存中,和方法区无关

static,final,Class

下图就是一个类的实例化,class模板和一些常量都是存在方法区的。属于共享数据区。

栈:先进后出 桶:后进先出 队列:先进先出( FIFO : First Input First Output )

栈:栈内存,主管程序的运行,生命周期和线程同步; 线程结束,栈内存也就是释放,对于栈来说,不存在垃圾回收问题 一旦线程结束,栈就Over!

栈内存中:8大基本类型+对象引用+实例的方法

栈运行原理:栈帧

栈满了: StackOverflowError

下图为对象的引用过程,class引用一个对象,将对象的引用存入栈中,具体的实例在堆中,静态常量在方法区中。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ggv9tdRY-1609695316131)(D:/work/image-20210103204005500.png)]

下图是栈帧的图解,栈底部子帧指向上一个栈的方法 上一个栈的父帧指向栈底部方法,所以说正在执行的方法就是在栈的最顶部。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CdrHrZzZ-1609695316134)(D:/work/image-20210103203158968.png)]

三种jvm

HotSpot(sun公司的,我们一般使用的都是这个)

JRockit BEA

J9 vm IBM

Heap, 一个JVM只有一个堆内存,堆内存的大小是可以调节的。 类加载器读取了类文件后,一般会把什么东西放到堆中?

类, 方法,常量,变量~,保存我们所有引用类型的真实对象;

堆内存中还要细分为三个区域:

● 新生区(伊甸园区) Young/New

● 养老区old

● 永久区Perm

下图是JDK1.8以前的堆内存:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NpOC3oBu-1609695316135)(D:/work/image-20210103224159869.png)]

GC垃圾回收,主要是在伊甸园区和养老区~ 假设内存满了,OOM,堆内存不够!

java.lang.OutOfMemoryError:Java heap space

永久存储区里存放的都是Java自带的 例如lang包中的类 如果不存在这些,Java就跑不起来了 在JDK8以后,永久存储区改了个名字(元空间)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-O4ZtCfYj-1609695316136)(D:/work/image-20210103231115086.png)]

新生区

  • 类:诞生和成长的地方,甚至死亡;
  • 伊甸园,所有的对象都是在伊甸园区new出来的!
  • 幸存者区(0,1)
  • 新生区标记次数,经过多次轻GC还存在就进入养老区

下图是重GC和轻GC

伊甸园满了就触发轻GC,经过轻GC存活下来的就到了幸存者区,幸存者区满之后意味着新生区也满了,则触发重GC,经过重GC之后存活下来的就到了养老区。

真理:经过研究,99%的对象都是临时对象!|

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7IiKv43x-1609695316138)(D:/work/image-20210103231153714.png)]

永久区

这个区域常驻内存的。用来存放JDK自身携带的Class对象。Interface元数据,存储的是Java运行时的一些环境~ 这个区域不存在垃圾回收,关闭虚拟机就会释放内存

  • jdk1.6之前:永久代,常量池是在方法区;

  • jdk1.7:永久代,但是慢慢的退化了,去永久代,常量池在堆中

  • jdk1.8之后:无永久代,常量池在元空间

  • 元空间:逻辑上存在,物理上不存在 (因为存储在本地磁盘内) 所以最后并不算在JVM虚拟机内存中

    为什么常量池慢慢的退出了方法区:

    因为常量池不好控制,方法区又很小,经常会出现永久区溢出,这在开发中是不允许的,最后发现常量就存磁盘就好了没必要就占用jvm内存。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IpjtyYXq-1609695316139)(D:/work/image-20210103231718917.png)]

JVM内存分配

堆内存分配

JVM初始分配的内存是由-Xms指定的,默认是物理内存的1/64,最大内存由-Xmx指定,默认是物理内存的1/4。默认如果空余对内存小于40%,JVM会增大堆直到最大限制,如果空余对内存大于70%,JVM就会减少直到最小限制,因此服务器一般设置-Xms、-Xmx相等以避免在每次GC后调整堆内存的大小。

非堆内存分配

JVM使用-XX:PermSize设置非堆内存初始值,默认是物理内存的1/64,由XX:MaxPermSize设置最大非堆内存的大小,默认是物理内存的1/4。

堆内存调优

这里我们在说明一下为什么元空间逻辑上存在,物理上不存在;

看下面一段测试:

我们可以看到分配了内存后的新生区和养老区的总和刚好等于总的分配内存,所以可以证明元空间在物理上是不存在的,他是属于“非堆”。

在这里插入图片描述

OOM调优

我们来解决实际问题了,如果我们遇到oom堆内存溢出怎么办?

  1. 尝试手动扩大堆内存,看结果,如果还是oom,可能就是代码的问题,比如出现了死循环。
  2. 分析内存,看在哪个地方出现了问题,这个时候需要用专业的工具,

专业用来分析内存的工具:

  • JPofiler:能够看到代码第几行出错

    使用:

    ​ 1.在idea中下载jprofile插件

    ​ 2.联网下载jprofile客户端

    ​ 3.在idea中VM参数中写参数 -Xms1m -Xmx8m -XX: +HeapDumpOnOutOfMemoryError

    ​ 4.运行程序后在jprofile客户端中打开找到错误 告诉哪个位置报错

    ​ 5.命令参数详解

    // -Xms设置初始化内存分配大小/164 
    // -Xmx设置最大分配内存,默以1/4 
    // -XX: +PrintGCDetails 
    // 打印GC垃圾回收信息 
    // -XX: +HeapDumpOnOutOfMemoryError //oom DUMP
    

在这里插入图片描述

作用:

- 分析Dump内存文件
- 获得对中最大对象
- 获得最大的对象		
  • MAT:内存快照分析工具(eclipse集成的)

垃圾回收

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lcOKD3rX-1609695316142)(D:/work/image-20210104004521503.png)]

JVM在进行GC时,并不是对这三个区域统一回收。 大部分时候,回收都是新生代~

●新生代

●幸存区(form,to)

●老年区

GC两种类:轻GC (普通的GC), 重GC (全局GC) GC

常见面试题目:

  • JVM的内存模型和分区~详细到每个区放什么?

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cof4cvMk-1609695316144)(D:/work/image-20210104004819732.png)]

  • 堆里面的分区有哪些? Eden, form, to, 老年区,说说他们的特点!
  • GC的算法有哪些? 标记清除法,标记整理,复制算法,引用计数器
  • 轻GC和重GC分别在什么时候发生?

gc算法

引用计数法(判断是否可以清楚)

给每个对象分配计数器,所以计数器本身也会消耗资源。如果有一个死循环就出现问题,如果计数器为0,表示这个对象不被使用了,就清楚掉。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mEgvpHZ2-1609695316145)(D:/work/image-20210104005352344.png)]

复制算法
  • 每次GC都会将Eden区活的对象移到幸存区,一旦Eden区被GC后,就会是空的。

  • 在对对象进入幸存区的时候就会来回复制,那个幸存区是空的就将对象那个转移到那个幸存区中,入伙都不为空就将一个幸存区的对象先转移到另一个幸存区。

  • 当一个对象经历了15次GC还没有死,就进入养老区,可以设置进入养老区的时间-XX:-XX:MaxTenuringThreshold=15,默认是15

  • 好处:没有内存碎片

  • 坏处:浪费了内存空间,一个幸存区to为空、

  • 使用场景:对象存活率比较低的时候,因为如果对象的存活率100%,每次复制的成本很高。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MN8DZ6ys-1609695316146)(D:/work/image-20210104011331677.png)]

标记清除算法
  • 优点:不需要额外的空间
  • 缺点:2次扫描,严重浪费时间,会产生内存碎片

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b273LueP-1609695316147)(D:/work/image-20210104011350644.png)]

标记压缩算法

在标记清除的基础上,再次扫描,像一段移动存存活的对象,多了一个移动成本,在防止内存碎片的产生

标记清除-压缩

先标记清除几次,在进行标记压缩。节约成本

总结

如何选择四种算法:

内存效率:复制算法>标记清除算法>标记压缩算法(时间复杂度)

内存整齐度:复制算法=标记压缩算法>标记清除算法

内存利用率:标记压缩算法=标记清除算法>复制算法

难道没有一个最优的算法吗?

答案:没有,没有最好的算法,只有最合适的算法---->GC:分带收集算法

年轻代:

  • 存活率低
  • 复制算法

老年代:

  • 区域大:存活率高
  • 标记清除(内存碎片不是太多)+标记压缩混合实现

JMM

1.什么是JMM?

JMM :(java Memory Model 缩写)java内存模型

2.他是干什么的?

**作用:**缓存-致性协议,用于定义数据读写的规则(遵守,找到这个规则)。
JMM定义了线程.工作内存和主内存之间的抽象关系:线程之间的共享变量存储在主内存(Main Memory)
中,每个线程都有一一个私有的本地内存(Local Memory)

解决共享对象可见性这个问题: volilatel

3.他该如何学习

JMM :抽象的概念,理论

JMM对这八种指令的使用,制定了如下规则:

  • 允许read和load. store和write操作之- 单独出现。即使用了read必须load, 使用了store必须
    write
  • 不允许线程丢弃他最近的assign操作,即工作变量的数据改变了之后,必须告知主存
  • 不允许一个线程将没有assign的数据从工作内存同步回主内存
  • 一个新的变量必须在主内存中诞生,不允许工作内存直接使用一个未被初始化的变量。就是怼变量实
    施use、store操作之 前,必须经过assign和load操作
  • 一个变量同一时间只有一一个线程能对其进行lock。 多次lock后,必须执行相同次数的unlock才能解锁
  • 如果对一个变量进行lock操作,会清空所有工作内存中此变量的值,在执行引擎使用这个变量前,必
    须重新load或assign操作初始化变量的值
  • 如果一个变量没有被lock,就不能对其进行unlock操作。也不能unlock- 个被其他线程锁住的变量
  • 对一个变量进行unlock操作之前,必须把此变量同步回主内存htpt:/blog.cscn.netqq. _43649223

JMM对这八种操作规则和对yolatile的一些特殊规则就能确定哪里操作是线程安全,哪些操作是线程不安
全的了。但是这些规则实在复杂,很难在实践中直接分析。所以一般我们也不会通过.上述规则进行分析。更多
的时候,使用java的happen-before规则来进行分析。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值