1.JVM的位置
应用程序->JVM->操作系统->硬件体系
2.JVM体系结构
Class File(字节码文件)
类加载子系统:
- 三个阶段:加载阶段,链接阶段,初始化阶段
- 加载阶段:引导类加载器,拓展类加载器,系统类加载器
- 链接阶段:验证,准备,解析
- 初始化阶段
运行时数据区:
方法栈,堆,虚拟机栈,PC寄存器,本地方法区
执行引擎:
-
解释器,即时编译器,垃圾回收器
-
即时编译器:中间代码生成器,代码优化器,目标代码生成器
程序计数器
程序计数器是一块较小的内存空间，它的作用可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现）字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。- - 摘自《深入理解Java虚拟机》
程序计数器是一块较小的内存空间,可以把它看做当前线程正在执行的字节码的行号指示器.也就是说,程序计数器里面记录的是当前线程正在执行的那一条字节码执行的地址.如果当前线程正在执行的是一个本地方法,那么此时程序计数器为空.
99%的JVM调优都是在堆中调优,Java栈,本地方法栈,程序计数器是不会有垃圾存在的.
3.类加载器和双亲委派机制
https://www.cnblogs.com/zhihaospace/p/12227726.html
类加载器
-
JVM自带的加载器(3种)
- 启动类加载器:Bootstrap ClassLoader,又名根类加载器或引导类加载器
- 拓展类加载器:Extension ClassLoader
- 系统类加载器:Application ClassLoader,又名应用类加载器
-
用户自定义的类加载器,一般是java.lang.ClassLoader
Java早期Java Applet需要从远程下载Java类文件到浏览器中并执行.
在java.net包中，JDK提供了一个更加易于使用的类加载器URLClassLoader，来扩展ClassLoader，能够从本地或网络上指定的位置加载类。我们可以使用该类作为自定义的类加载器使用
热部署类加载器
- 相同的类被同一个类加载器多次加载，则会报错。因此热部署是让同一个类文件被不同的类加载器加载重复加载即可。
- 我们不能调用loadClass方法，而应该调用findClass方法，避免双亲委派机制，从而实现同一个类被加载多次，实现热部署
类加载器的种类：
1-启动类加载器，负责加载%JAVA_HOME%\bin目录下的所有jar包，或者是-Xbootclasspath参数指定的路径；
2-扩展类加载器：负责加载%JAVA_HOME%\bin\ext目录下的所有jar包，或者是java.ext.dirs参数指定的路径；
3-应用程序类加载器：负责加载用户类路径上所指定的类库，如果应用程序中没有自定义加载器，那么次加载器就为默认加载器。
双亲委派机制
委派机制图:
双亲委派机制的工作过程:
- 类加载器收到类加载的请求;
- 把这个请求委托给父加载器去完成,一直向上委托,直到启动类加载器;
- 启动类加载器检查能不能加载(使用findClass()方法),能加载就结束;否则抛出异常,通知子加载器进行加载;
- 重复步骤三.
接下来举个例子：
大家所熟知的Object类，直接告诉大家，Object默认情况下是启动类加载器进行加载的。假设我也自定义一个Object，并且制定加载器为自定义加载器。现在你会发现自定义的Object可以正常编译，但是永远无法被加载运行。
这是因为申请自定义Object加载时，总是启动类加载器，而不是自定义加载器，也不会是其他的加载器。
4、Java历史-沙箱安全机制
Java安全模型的核心就是Java沙箱(sandbox) , 什么是沙箱?沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机(JVM)特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。 沙箱主要限制系统资源访问，那系统资源包括什么? CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。 所有的Java程序运行都可以指定沙箱，可以定制安全策略。 在Java中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码,可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱Sandbox)机制。如下图所示JDK1.0安全模型
ps:和360的隔离沙箱有点像,不安全的程序在里面执行.
图 JDK1.0安全模型
但如此严格的安全机制也给程序的功能扩展带来障碍，比如当用户希望远程代码访问本地系统的文件时候，就无法实现。因此在后续的Java1.1版本中，针对安全机制做了改进，增加了安全策略，允许用户指定代码对本地资源的访问权限。如下图所示JDK1.1安全模型
图 JDK1.1安全模型
在Java1.2版本中，再次改进了安全机制，增加了代码签名。不论本地代码或是远程代码，都会按照用户的安全策略设定，由类加载器加载到虚拟机中权限不同的运行空间，来实现差异化的代码执行权限控制。如下图所示
图 JDK1.2安全模型
当前最新的安全机制实现，则引入了域(Domain)的概念。虚拟机会把所有代码加载到不同的系统域和应用域,系统域部分专门负责与关键资源进行交互，而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域(Protected Domain),对应不一样的权限(Permission)。存在于不同域中的类文件就具有了当前域的全部权限，如下图所示最新的安全模型(jdk 1.6)
图 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下的类和扩展包下的类，允许用户为自己的应用增加新的安全特性，
包括: 安全提供者 消息摘要 数字签名 加密 鉴别
5.Native
native :凡是带了native关键字的，说明java的作用范围达不到了，回去调用底层c语言的库!
会进入本地方法栈 去调用本地方法接口将native方法引入执行
调用本地方法本地接口 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~
Native Method Stack
它的具体做法是Native Method Stack中登记native方法，在( Execution Engine )执行引擎执行的时候加载Native Libraies。[本地库]
Native Interface本地接口
本地接口的作用是融合不同的编程语言为Java所用，它的初衷是融合C/C++程序, Java在诞生的时候是C/C++横行的时候，想要立足，必须有调用C、C++的程序，于是就在内存中专门开辟了块区域处理标记为native的代码，它的具体做法是在Native Method Stack 中登记native方法,在( Execution Engine )执行引擎执行的时候加载Native Libraies。
目前该方法使用的越来越少了，除非是与硬件有关的应用，比如通过Java程序驱动打印机或者Java系统管理生产设备，在企业级应用中已经比较少见。因为现在的异构领域间通信很发达，比如可以使用Socket通信,也可以使用Web Service等等，不多做介绍!
6.PC寄存器
程序计数器: Program Counter Register
每个线程都有一个程序计数器，是线程私有的，就是一个指针, 指向方法区中的方法字节码(用来存储指向像一条指令的地址， 也即将要执行的指令代码)，在执行引擎读取下一条指令, 是一个非常小的内存空间，几乎可以忽略不计
7.方法区 Method Area
方法区是被所有线程共享,所有字段和方法字节码，以及一些特殊方法，如构造函数,接口代码也在此定义,简单说，所有定义的方法的信息都保存在该区域,此区域属于共享区间; 静态变量、常量、类信息(构造方法、接口定义)、运行时的常量池存在方法区中，但是实例变量存在堆内存中，和方法区无关
图 类实例化后
8.栈stack
栈:先进后出,栈内存主管程序的运行,生命周期和线程同步,线程结束,栈内存也就是释放,对于栈来说,不存在垃圾回收问题,一旦线程结束,栈就结束.
栈内存中运行:8大基本类型+对象引用+实例的方法.
栈运行原理:栈桢
栈满了:*Error
队列:先进先出(FIFO:First Input First Output)
main()先执行,最后结束.
栈桢图解
栈底部子帧指向上一个栈的方法,上一个栈的父桢指向栈底部方法.
补充:
对象实例化过程,总之一句话,静态代码块内容先执行(父先子后),接着执行父类费静泰代码块和构造方法,然后执行子类非静态代码块和构造方法.
栈溢出(*Error),a方法调用b方法,b方法调用a方法,死循环无限执行.
Robot(),机器人类可以操作电脑.
9.三种JVM
10.堆heap
一个JVM只有一个堆内存,堆内存的大小是可以调节的.类加载器读取类文件后,一般会把类,方法,常量,变量,保存我们所有引用类型的真实对象.
堆内存细分为三个区域:
-
新生区(伊甸园区):Young/New
-
养老区old
-
永久区Perm
图 对内存详细划分
新生区
目的:控制对象的诞生,成长和死亡
分为:
伊甸园区:所有对象都在伊甸园区new出来
幸存0去和幸存1区:轻GC之后存下来的
老年区(养老区)
永久存在的对象放在老年区,真理:经过研究，99%的对象都是临时对象!
步骤:
- 当伊甸园区满了之后进行轻GC幸存下来的放到幸存0区或幸存1区
- 当伊甸园区,幸存0区和幸存1区都满了进行重GC,幸存下来的放到养老区
- 当伊甸园区,幸存0区和幸存1区和养老区都满了,会出现OOM
永久区
注意:
-
元空间在逻辑上存在而物理上不存在,又称为非堆,但是实际上是和堆放在同一个物理空间中;
-
方法区中的一小块为常量区.
默认情况下,JVM使用的最大内存为电脑总内存的四分之一,JVM使用的总内存为电脑总内存的十六分之一.
11.堆内存调优
在一个项目中,突然出现了OOM堆内存溢出错误,该如何排查.
内存快照分析工具,MAT,Jprofiler,Debug一行一行分析代码.
MAT,Jprofiler作用
分析Dump内存文件,快速定位内存泄漏
获得堆中的数据,获得大的对象.
MAt是集成在Eclipse中使用.
IDEA+Jprofile https://blog.csdn.net/wytocsdn/article/details/79258247
Jprofile https://blog.csdn.net/a294039255/article/details/84863892
12.GC
GC:Garbage Collection 垃圾收集
Java中,GC的对象是Java堆和方法区(即永久区)
Eden与Survivor的内存大小比例为8:1:1
1.引用计数法
引用计数算法算是实现最简单的了，它只需要一个简单的递归即可实现。现代编程语言比如Lisp，Python，Ruby等的垃圾收集算法采用的就是引用计数算法。现在就让我们来看下引用计数算法(reference counting)是如何工作的。
原理:实际上是通过在对象头中分配一个空间来保存该对象被引用的次数。如果该对象被其它对象引用，则它的引用计数+1，如果删除对该对象的引用，那么它的引用计数就-1，当该对象的引用计数为0时，那么该对象就会被回收。
GC的时候会将计数器为0的对象C给销毁.
引用计数法无法解决循环引用的问题
1,1根搜索算法的概念：
由于引用计数算法的缺陷，所以JVM一般会采用一种新的算法，叫做根搜索算法。它的处理方式就是，设立若干种根对象，当任何一个根对象到某一个对象均不可达时，则认为这个对象是可以被回收的。
2.复制算法(新生代)
复制算法的概念：
将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
-
与标记-清除算法相比，复制算法是一种相对高效的回收方法
-
不适用于存活对象较多的场合，如老年代（复制算法适合做新生代的GC）
-
幸存区from和幸存区to中谁空谁是to,我们会将to中的数据复制到from中保持to中数据为空;
-
from和to区实际上为逻辑上的概念,保证to区一直空;
-
默认对象经过15次GC后还没有被销毁就会进入养老区.
-
流程:
-
将Eden区进行GC存活对象放入空的to区,将from区存活的放到空的to区
-
此时from区为空变成了to区,to区有数据变为from区
-
经过15次GCfrom区还存活的对象会被移动到养老区
好处:没有内存碎片
坏处:浪费了内存空间(to区为空)
复制算法最佳使用场景:对象存货度较低(如果存活度较高,则from区空间全部被占满导致会将全部内容复制到to区)
3.标记-清除算法
标记清除算法的概念：
标记-清除算法是现代垃圾回收算法的思想基础。标记-清除算法将垃圾回收分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段，首先通过根节点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象；然后，在清除阶段，清除所有未被标记的对象。
它的做法是当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被成为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。
-
需要两次扫描,第一次扫描标记存活对象,第二次扫描清除没有被标记的对象
-
优点:不需要额外的空间
缺点:两次扫描严重浪费时间,并且还会产生内存碎片
4.标记-压缩/整理算法(老年代)
概念：
标记-压缩算法适合用于存活对象较多的场合，如老年代。它在标记-清除算法的基础上做了一些优化。和标记-清除算法一样，标记-压缩算法也首先需要从根节点开始，对所有可达对象做一次标记；但之后，它并不简单的清理未标记的对象，而是将所有的存活对象压缩到内存的一端；之后，清理边界外所有的空间。
-
在标记清除算法上进行优化,再扫描一次将存活对象移动到一起
总结:
内存效率:复制算法>标记清除算法>标记压缩算法(时间复杂度)
内存整齐度:复制算法=标记压缩算法>标记清除算法
内存利用率:标记压缩算法=标记清除算法>复制算法
没有最好的算法,只有最合适的算法 GC:分代收集算法
年轻代:
-
存活率低
-
复制算法
老年代:
- 区域大:存活率
- 标记清除(内存碎片不是太多)+标记压缩混合实现
5.分代收集算法（新生代的GC+老年代的GC）
当前商业虚拟机的GC都是采用的“分代收集算法”，这并不是什么新的思想，只是根据对象的存活周期的不同将内存划分为几块儿。一般是把Java堆分为新生代和老年代：短命对象归为新生代，长命对象归为老年代。
- 少量对象存活，适合复制算法：在新生代中，每次GC时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成GC。
- 大量对象存活，适合用标记-清理/标记-整理：在老年代中，因为对象存活率高、没有额外空间对他进行分配担保，就必须使用“标记-清理”/“标记-整理”算法进行GC。
注：老年代的对象中，有一小部分是因为在新生代回收时，老年代做担保，进来的对象；绝大部分对象是因为很多次GC都没有被回收掉而进入老年代。
//当执行GC时，会执行finalize方法，并且只会执行一次
system.gc();
Stop-The-World(part的清洁工,终止part来打扫)：
Java中一种全局暂停的现象。全局停顿，所有Java代码停止，native代码可以执行，但不能和JVM交互
多半情况下是由于GC引起。
少数情况下由其他情况下引起，如：Dump线程、死锁检查、堆Dump。
危害:长时间服务停止，没有响应（将用户正常工作的线程全部暂停掉）
https://www.cnblogs.com/qianguyihao/p/4744233.html
13.垃圾收集器
如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现
1.serial(串行)收集器
2.并行收集器
2.1 PartNew
2.2 Parallel收集器
3.CMS收集器(并发标记清除)
- Concurrent Mark Sweep 并发标记清除（应用程序线程和GC线程交替执行）
- 使用标记-清除算法
- 并发阶段会降低吞吐量（停顿时间减少，吞吐量降低）
- 老年代收集器（新生代使用ParNew）
- -XX:+UseConcMarkSweepGC
4.G1收集器
https://blog.csdn.net/laomo_bible/article/details/83112622
14.finalize()方法详解
1. finalize的作用
(1)finalize()是Object的protected方法，子类可以覆盖该方法以实现资源清理工作，GC在回收对象之前调用该方法。
(2)finalize()与C++中的析构函数不是对应的。C++中的析构函数调用的时机是确定的（对象离开作用域或delete掉），但Java中的finalize的调用具有不确定性
(3)不建议用finalize方法完成“非内存资源”的清理工作，但建议用于：① 清理本地对象(通过JNI创建的对象)；② 作为确保某些非内存资源(如Socket、文件等)释放的一个补充：在finalize方法中显式调用其他资源释放方法。其原因可见下文[finalize的问题]
2. finalize的问题
(1)一些与finalize相关的方法，由于一些致命的缺陷，已经被废弃了，如System.runFinalizersOnExit()方法、Runtime.runFinalizersOnExit()方法
(2)System.gc()与System.runFinalization()方法增加了finalize方法执行的机会，但不可盲目依赖它们
(3)Java语言规范并不保证finalize方法会被及时地执行、而且根本不会保证它们会被执行
(4)finalize方法可能会带来性能问题。因为JVM通常在单独的低优先级线程中完成finalize的执行
(5)对象再生问题：finalize方法中，可将待回收对象赋值给GC Roots可达的对象引用，从而达到对象再生的目的
(6)finalize方法至多由GC执行一次(用户当然可以手动调用对象的finalize方法，但并不影响GC对finalize的行为)
3. finalize的执行过程(生命周期)
(1) 首先，大致描述一下finalize流程：当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。否则，若对象未执行过finalize方法，将其放入F-Queue队列，由一低优先级线程执行该队列中对象的finalize方法。执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活”。
(2) 具体的finalize流程：
对象可由两种状态，涉及到两类状态空间，一是终结状态空间 F = {unfinalized, finalizable, finalized}；二是可达状态空间 R = {reachable, finalizer-reachable, unreachable}。
finalize方法的使用总结：
- 经验：避免使用finalize()，操作不慎可能导致错误。
- 优先级低，何时被调用，不确定
何时发生GC不确定，自然也就不知道finalize方法什么时候执行
- 如果要使用finalize去释放资源，我们可以使用try-catch-finally来替代它