JVM

前言：

本文是在狂神的基础上，继续整合《深度理解jvm》和他人的一些博客，完善了一些模糊的理论，使得jvm整体框架的学习理解逻辑更加自洽。

JVM探究

面试常见：

请你谈谈你对JVM的理解?
java8虚拟机和之前的变化更新?
什么是OOM，什么是栈溢出StackOverFlowError? 怎么分析?
JVM的常用调优参数有哪些?
内存快照如何抓取，怎么分析Dump文件？
谈谈JVM中，类加载器你的认识

1. JVM的位置

2. JVM的体系结构

3. 类加载器

虚拟机自带的加载器

启动类(根)加载器 BootstrapClassLoader
扩展类加载器 ExtClassLoader
应用程序加载器 AppClassLoader

个人总结：

任何一个类，只要继承ClassLoader，并覆盖findClass方法，那么这个就是自定义加载器，ExtClassLoader和AppclassLoader就是自定义加载器。

所以除了上述的3种类加载器，我们还可以写自己的类加载器，只要继承ClassLoader，并覆盖findClass方法即可。

4. 双亲委派机制

ps：这个图解释了双亲委派机制：

就是一个类先被AppClassLoader检查是否加载过，一直都是无的话一直向上委托，知道根加载器，然后尝试加载，不行就让子加载器加载，一直到AppClassLoader，如果不行，那就只能抛出ClassNotFoundException了，如果可以就直接加载进jvm.

注意：这里的向上委托并不是指他们之间存在继承关系，而是存在包含关系。

5.沙箱安全机制

Java安全模型的核心就是Java沙箱(sanddiox)，什么是沙箱？

沙箱是一个限制程序运行的环境。

沙箱机制就是将Java代码限定在虚拟机 (JVM) 特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。

沙箱主要限制系统资源访问，那系统资源包括什么? CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。

所有的Java程序运行都可以指定沙箱，可以定制安全策略。

在Java中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。

对于授信的本地代码，可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱(Sandbox)机制。如下图所示JDK1.0安全模型

但如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。

因此在后续的Java1.1版本中，针对安全机制做了改进，增加了安全策略，允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型

在Java1.2版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如下图所示

当前最新的安全机制实现，则引入了域(Domain)的概念。

虚拟机会把所有代码加载到不同的系统域和应用域，系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域(Protected Domain)对应不一样的权限(Permission)。存在于不同域中的类文件就具有了当前域的全部权限，如下图所示最新的安全模型(jdk 1.6)

组成沙箱的基本组件：

字节码校验器(bytecode verifier)：确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验，比如核心类。
类裝载器(class loader) ：其中类装载器在3个方面对Java沙箱起作用
- 它防止恶意代码去干涉善意的代码（双亲委派）;
- 它守护了被信任的类库边界（双亲委派）;
- 它将代码归入保护域,确定了代码可以进行哪些操作（加载的时候归域）。
虚拟机为不同的类加载器载入的类提供不同的命名空间，命名空间由一系列唯一的名称组成，每一个被装载的类将有一个名字，这个命名空间是由Java虚拟机为每一个类装载器维护的，它们互相之间甚至不可见。
类装载器采用的机制是双亲委派模式。

从最内层JVM自带类加载器开始加载,外层恶意同名类得不到加载从而无法使用;

由于严格通过包来区分了访问域,外层恶意的类通过内置代码也无法获得权限访问到内层类，破坏代码就自然无法生效。
存取控制器(access controller) :存取控制器可以控制核心API对操作系统的存取权限，而这个控制的策略设定,可以由用户指定。
安全管理器(security manager) : 是核心API和操作系统之间的主要接口。实现权限控制，比存取控制器优先级高。
安全软件包(security package) : java.security下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，包括:

安全提供者

消息摘要

数字签名

加密

鉴别

6.native

native：

凡是带了native关键字的，说明java的作用范围达不到了，会去调用本地方法库

调用本地方法本地接口 JNI (Java Native Interface)
JNI作用：开拓Java的使用，融合不同的编程语言为Java所用，最初: C、C++
Java诞生的时候C、C++横行，想要立足，必须要有调用C、C++的程序

它在内存区域中专门开辟了一块标记区域: Native Method Stack，登记native方法
在最终执行的时候，加载本地方法库中的方法通过JNI
例如：Java程序驱动打印机，管理系统，掌握即可，在企业级应用比较少
private native void start0();
调用其他接口：Socket… WebService … http~

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

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

7. PC寄存器

程序计数器: Program Counter Register

每个线程都有一个程序计数器，是线程私有的，就是一个指针，指向方法区中的方法字节码(用来存储指向像一条指令的地址，也即将要执行的指令代码)，在执行引擎读取下一条指令

是一个非常小的内存空间，几乎可以忽略不计

8. 方法区 Method Area

事实上，jdk8之后，这个方法区=原空间=持久代，就是一个放类模板和属于类的变量，方法，常量，常量池的地方。

方法区是被所有线程共享，所有字段和方法字节码，以及一些特殊方法，如构造函数，接口代码也在此定义,简单说，所有定义的方法的信息都保存在该区域，此区域属于共享区间;
静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关
static、final、Class、常量池

ps：常量池放置的是java程序在编译的时候就已经确定的常量，包括字符串常量，如 String s = "hello java" 这种申明方式；

9. 栈

栈：Java栈指线程存放信息的数据结构；
栈帧：栈里的信息的基本单位，每一个方法形成一个栈帧放在栈内；

主管程序的运行，生命周期和线程同步（一个线程一个栈）；
线程结束，栈内存也就释放，对于栈来说，不存在垃圾回收的问题。
一旦线程结束，栈就Over

栈：8大基本类型的变量数据＋对象的引用＋实例的方法
但对象本身不存放在栈中，而是存放在堆（new 出来的对象）或者常量池中(对象可能在常量池里)（字符串常量对象存放在常量池中。）；

栈运行原理：栈帧

栈帧：局部变量表+操作数栈
每执行一个方法，就会产生一个栈帧。程序正在运行的方法永远都会在栈的顶部

栈满了: StackOverflowError

栈＋堆＋方法区：交互关系

蓝色为堆,绿色为栈,粉红色为方法区,深蓝色为常量池

10.三种JVM

目前市面上就只有三种主流的JVM：SUN、BEA和IBM。

Sun公司的HotSpot 是目前使用范围最广的Java虚拟机。
BEA公司的JRockit（原来的 Bea JRockit）电脑软件，系列产品是一个全面的Java运行时解决方案组合。
IBM公司的J9 VM 是一个高性能的企业级 Java 虚拟机。

11.堆

Heap，一个JVM只有一个堆内存，堆内存的大小是可以调节的。
类加载器读取了类文件后，一般会把什么东西放到堆中？类，方法，常量，变量~，保存我们所有引用类型的真实对象；

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

新生区（伊甸园区) Young/New
养老区 old
永久区 Perm（事实上，只是逻辑上有这个玩意儿，jdk8之后，没有永久区，只有元空间（方法区），在堆之外）

GC：Garbage recycling：垃圾回收机制
轻GC：伊甸园满了之后触发，清理伊甸园区，活下来的对象进入幸存者区；
重GC（Full GC）：整个新生区满了之后触发，清理新生区，活下来的对象进入老年区；

假设内存满了，OOM（Out Of memory），堆内存不够！java.lang.OutOfMemoryError: Java heap space

在JDK8以后，永久存储区改了个名字——元空间，事实上，就是方法区这个地方，存放与类有关的东西——类的模板、类的变量、常量、常量池

真理：经过研究，99%的对象都是临时对象!

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

一个启动类，加载了大量的第三方jar包。Tomcat部署了太多的应用，大量动态生成的反射类。不断的被加载。直到内存满，就会出现OOM;

方法区中那个小框是：常量池；

元空间又被称为非堆，用来区分堆，说明这玩意儿不在堆内存中，有人逻辑上把非堆当作堆的一部分；

元空间：逻辑上存在，物理上不存在 (因为存储在本地磁盘内) 而并不算在JVM虚拟机内存中，也就是并没有占堆内存。

12. 堆内存调优

测试代码：

//-Xms8m -Xmx8m -XX:+PrintGCDetails
public class Hello{
	public static void main( String[ ] args) i
	string str = "kuangshensayjava";
	while (true){
	str += str + new Random( ) .nextInt( bound: 888888888)+new Random( ) .nextInt( bound: 99999999);
	}
}

IDEA调整堆内存大小的地方：Edit Configuration—>VM options

上图的1m指的是把堆内存设置为1m

可以通过调整这个参数控制Java虚拟机初始内存和分配的总内存的大小。默认情况下：

分配的总内存是电脑内存的 1/4，而初始化的内存: 1/64

聊到如何解决OOM：

1、尝试扩大堆内存看结果

2、分析内存，看一下哪个地方出现了问题（专业工具)

调优参数：

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

13. Jprofile使用

在idea中下载 jprofile 插件
百度搜索官网下载 jprofile 客户端，安装路径要求：没有中文没有空格
安装破解完之后，在IDEA的Settings—>Tools下找到 jprofiles，然后绑定安装目录bin下的.exe文件
-在idea中VM参数中写参数 -Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError （假如堆内存heap出现了OOM则dump出这个异常）
运行程序后在jprofile客户端中打开（dump出的文件应该在src目录下）找到错误告诉哪个位置报错

14. GC算法

GC题目：

JVM的内存模型和分区，详细到每个区放什么?
堆里面的分区有哪些? Eden，from，to，老年区，说说他们的特点!
GC的算法有哪些? 标记清除法，标记压缩，复制算法，引用计数器，怎么用的?
轻GC和重GC分别在什么时候发生?

引用计数法：

描述：给每个对象加一个计数器，挑引用次数小的清理

特点：

low
有消耗
JVM不会用，因为大型项目有超多对象

复制算法：

新生区使用的算法

算法描述：每次 Eden 满了就会触发，清空 Eden，把存活下来的对象复制到 To 区，把所有 From 区的对象复制到 To 区

优点：没有内存的碎片

缺点：浪费了内存空间，To 区永远是空的

极端情况：加入Eden 存活对象 + From 对象 > To 空间，那么多出来的就会复制到老年区

最佳使用场景：新生区对象存活度较低的时候

第一次GC后，Eden区和to区空了，经过15次垃圾回收后依然存活下来的对象就会去养老区

这里查了一下对象进入老年区的条件：

对象经历了15次 Minor GC 依旧存活 (默认值 -XX:MaxTenuringThreshold = 15)
Survivor区中同龄对象大小超过Survivor区空间的50%,大于此年龄的对象会进入老年代 (动态对象年龄判定) (其实是这个年龄以及低于这个年龄的对象占据超过Survivor 50% 1+2+3大于50% 则大于等于3岁的对象会进入老年代)
Minor GC后对象大小大于Survivor大小，会进入老年代 (空间担保机制)
大对象直接进入老年代 (-XX:PretenureSizeThreshold=1M 只对Serial和ParNew两款收集器有效)

标记清除压缩系列算法：

老年区使用的算法

标记：扫描对象，对存活的对象进行标记
清除：对没有标记的对象进行清除
压缩：再扫描，把存活的对象往一端移动

标记清除算法：

步骤1 + 步骤2
优点：不需要额外的空间
缺点：
1. 扫描，严重浪费时间
2. 会产生内存碎片

标记压缩算法：

步骤1 + 步骤2 + 步骤3
特点：用时间换空间，多扫描一遍，去除了内存碎片

再改进：先标记清除几次，然后压缩一次。

ps：GC算法永远没有最优的方案，永远只是时间或空间的权衡，而现在不缺空间，所以都是优先选择复制算法。

15. 算法总结

内存效率：复制算法>标记清除算法>标记压缩算法(时间复杂度)
内存整齐度：复制算法=标记压缩算法>标记清除算法
内存利用率：标记压缩算法=标记清除算法>复制算法

思考一个问题：难道没有最优算法吗?
答案：没有，没有最好的算法，只有最合适的算法 —> GC：分代收集算法

年轻代：

存活率低
复制算法!

老年代:

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

16. 轻重gc的分类以及触发机制

GC按照回收区域分为两大种类型：一种是部分收集（Partial GC），一种是整堆收集（Full GC）

1. gc分类

部分收集：不是完整收集整个Java堆的垃圾收集。其中分为：
1. 新生代收集（Minor GC / Young GC）：只是新生代的垃圾收集，用复制算法；
2. 老年代收集（Major GC / Old GC）：只是老年代的收集，用标记清除压缩算法。注意很多时候Major GC 会和Full GC混淆使用，需要具体分辨是老年代回收还是整堆回收
整堆收集（Full GC）：收集整个Java堆和方法区的垃圾回收。

2. gc触发机制

Minor GC 触发机制

Minor GC 只在Eden区满的时候触发，Survivor区满并不会触发Minor GC，但是并不是说Survivor区不会被垃圾回收，而是说在Eden区满时触发Minor GC然后Eden区和Survivor区一起被垃圾回收，可以说Survivor区是被动垃圾回收的
Major GC 触发机制

在老年代空间不足的时候，会先尝试触发Minor GC，如果之后空间还不足，就会执行Major GC。
Full GC触发机制
1. 调用System.gc()时，系统建议执行Full GC，但是不必然执行
2. 老年代不足的时候
3. 方法区不足的时候
4. 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
5. 由Eden区，survivor0（From Space）区先survivor1（To Space）区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
说明：Full GC是开发或者调优中尽量要避免的，这样暂停时间会短一些

17. 方法区的gc

方法区和堆一样，都是线程共享的内存区域，被用于存储已被虚拟机加载的类信息（字段等）、即时编译后的代码（方法字节码）、静态变量和常量等数据。

根据Java虚拟机规范的规定，方法区无法满足内存分配需求时，也会抛出OutOfMemoryError异常，虽然规范规定虚拟机可以不实现垃圾收集，因为和堆的垃圾回收效率相比，方法区的回收效率实在太低，但是此部分内存区域也是可以被回收的。

方法区的垃圾回收主要有两种，分别是对废弃常量的回收（常量池的回收）和对无用类的回收（类的卸载）。

常量池回收

当一个常量对象不再任何地方被引用的时候，则被标记为废弃常量，这个常量可以被回收。
类的卸载

方法区中的类需要同时满足以下三个条件才能被标记为无用的类：
1. Java堆中不存在该类的任何实例对象；
2. 加载该类的类加载器已经被回收；
3. 该类对应的java.lang.Class对象不在任何地方被引用，且无法在任何地方通过反射访问该类的方法。
当满足上述三个条件的类才可以被回收，但是并不是一定会被回收，需要参数进行控制，例如HotSpot虚拟机提供了-Xnoclassgc参数进行控制是否回收。

18. JMM

什么是JMM?

JMM：(Java Memory Model的缩写)
作用：缓存一致性协议，用于定义数据读写的规则 (遵守，找到这个规则)。

JMM定义了线程和主内存之间的抽象关系:线程之间的共享变量存储在主内存(Main Memory)中，每个线程都有一个私有的本地内存(Local Memory)

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

一旦刷新了就会很快的同步到主内存中。

它该如何学习?

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操作之前，必须把此变量同步回主内存

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

posted @ 2021-06-20 17:13 何-某人阅读(84) 评论(0) 收藏举报

刷新页面返回顶部

何-某人

JVM

前言：