JVM （Java Virtual Machine）

就是一台虚拟的计算机，是一款软件，用来执行一系列虚拟计算机指令，虚拟机分为程序虚拟机和系统虚拟机

Visual Box、Vmware 就是系统虚拟机，他们完全是对物理计算机的仿真。提供了一个可运行完整操作系统的软件平台

典型的就是Java虚拟机，专门为执行单个计算机程序而设定，在java虚拟机中执行指令被我们成为java字节码指令

1、java虚拟机是一台执行java字节码的虚拟计算机，拥有独立的运行机制，其运行的java字节码也未必由java语言编译而成

2、JVM平台的各种语言可以共享java虚拟机带来的跨平台性，优秀的垃圾回收器以及可靠的及时编译器

3、java的核心技术就是java虚拟机（Java Virtual Machine）所有的java程序都是运行在java虚拟机内部

Java虚拟机就是二进制字节码的运行环境，负责装载字节码到其内部，解释和编译为对应平台上机器指令，每一条java指令，jvm规范中都有详细的定义（怎么操作取数、怎么处理操作数，处理结果）

一次编译处处运行

自动内存管理

自动内存回收

设计和实现更简单，适用于资源受限的系统

避开了寄存器的分配难题，使用零地址指令方式分配

指令流中的指令大部分都是零地址指令，其执行的过程中依赖于操作栈，指令集更小(8位)，编译器容易实现

不需要硬件支持，可移植性更好，更好的实现跨平台

典型的应用是x86的二进制指令集，比如传统pc以及安卓的Davlik虚拟机

指令集架构完全依赖硬件，可移植性差

性能优秀和执行高效

花费更少的指令(16位)执行一项操作

在大部分情况下，基于寄存器架构的指令集往往都是以1地址指令，2地址指令，3地址指令为主，而基于栈式架构的指令集却是以零地址为主

java虚拟机的启动是通过引导类加载器（Bootstrap class loader）创建一个初始类（init class）来完成，这个类是由虚拟机的具体实现指定

一个运行中的java虚拟机有着一个清晰的任务，执行java程序

程序开始执行时他才运行，程序结束时他就停止

执行一个所谓的java程序时，真正在执行的是一个叫Java虚拟机的进程

程序正常执行结束

程序在执行过程中遇到了异常或错误而异常终止

由于操作系统出现错误而导致Java虚拟机进程终止

某线程调用RunTime 类或者System类中exit方法，或者RunTime 类的halt方法，并且Java安全管理器也允许这次exit或者halt操作

除此之外，JNI（Java Native Interface）规范描述了JNI Invocation API 来加载或者卸载java虚拟机时，虚拟机退出情况

概念

作用

自动内存管理缺点

垃圾回收算法

内存模型

GC日志

垃圾收集器

一个JVM实例只存在一个堆内存,堆也是Java 内存管理的核心区域

Java 堆区在JVM启动的时候即被创建,其空间大小也确定了,是JVM管理的最大一块内存空间

<JVM规范> 规定,堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的

所有的线程共享Java 堆,在这里还可以划分线程私有的缓冲区(Thread Local Allocation Buffer ,TLAB)

<JVM规范> 中对java 堆的描述是: 所有的对象实例以及数组都应当在运行时分配在堆上

数组和对象可能永远不会存储在栈上,因为栈帧中保存引用,这个引用指向对象或者数组在堆中的位置

在方法结束后,对中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除

堆是GC 执行垃圾回收的重点区域

年轻代：声明周期较短的瞬时大小,这类对象的创建和消亡都非常迅速

老年代：生命周期非常长,在某些极端的情况下还能与JVM的生命周期保持一致

默认 -XX:NewRatio=2 表示新生占1,老年代占2,新生代占整个堆的1/3

-XX:NewRatio=4 表示新生代1,老年代占4,新生代占整个堆的1/5

几乎所有的Java 对象都在Eden中被new 创建出来的

可以使用选项 -Xmn 设置新生代最大内存大小

简介

过程

总结

1), 当年轻代空间不足的时候,就会触发 Minor GC ,这里年轻代指的是 Eden满, Survivor 满则不会引发YGC(每次Minor GC 会清理年轻代的内存)

2), 因为java 的对象大多具备朝生夕死的特性, 所以 Minor GC 非常频繁,一般回收速度很快,这一定义即清晰又易于理解

3), Minor GC 会引发 STW(stop the world),暂停其它用户线程,等垃圾回收结束,用户线程才能恢复

1), 指发生在老年代的GC, 对象从老年代取消时,我们说 Major GC 或 Full GC 发生了

2), 出现 Major GC ,经常伴随至少一次的Minor GC (并非绝对)

3), Major GC 的速度一般是 Minor GC 的十倍以上,STW停留的时间更长

4), 如果 Major GC 后,内存还是不足,就报OOM异常

1), 调用 System.gc() 时,系统建议执行 Full GC 但是不必然执行

2),老年代空间不足

3), 方法区空间不足

4), 通过 Minor GC 后进行老年代的平均大小大于老年代的可用内存

5), 由Eden 区, Survivor S0区向 S1区复制时,对象大小2大于 To 空间可用内存,则把该对象转存到老年代,且老年代的可用内存小于该对象大小

说明: Full GC 是开发或者调优中尽量避免的,这样暂停时间会短一些

为什么需要把Java 堆分代?不分代就不能正常工作?

为什么需要把Java 堆分代? 不分代就不能正常工作了?

如果对象在 Eden出生并经过 Minor GC 之后,仍然存活,并且能被 Surivor 容纳的话, 将被移动到 Surivor 中,将对象的年龄设置为1, 对象在 Surivor 中每经过一次 MinorGC 对象年龄就会加1,当年龄超过15岁时,就会晋升老年代

1),优先分配到Eden

2), 大对象直接存放到老年代 -- 尽量避免程序中出现过多的大对象

3), 长期存活的对象分配到老年代

4), 动态对象年龄判断

5), 空间分配担保

定义

意义

说明

-XX:+PrintFlagsInitial : 查看所有的参数默认值大小

-XX:+PrintFlagsFinal : 查看所有参数的最终值

-Xms : 堆初始默认值大小(默认物理内存的1/64)

-Xmx: 堆最大空间大小(默认物理内存1/4)

-Xmn: 设置新生代的大小

-XX:NewRadio: 配置新生代与老年代在堆结构的占比

-XX:SurvivoRatio: 设置新生代中 Eden 与 S0/S1空间的比例

-XX:MaxTenuringThreshold : 设置新生代垃圾的最大年龄

-XX:+PrintGCDetails : 输出详细的GC处理日志

-XX: HandlePromotionFailure : 是否设置空间内存担保

在<深入理解java虚拟机>关于java 堆内存有这样一段描述:

随着JIT编译器的发展与逃逸分析技术逐渐成熟,栈上分配,标量替换优化技术将会导致一些微妙的变化,所有的对象都分配在堆上显得不是那么绝对了

在java 虚拟机中,对象是在java堆中进行分配的,这是一个普遍的常识,但是有一种特殊情况,那就是如果经过逃逸分析(Escape Analysis) 后发现,一个对象并没有逃逸出方法的话,那么它可能被优化成栈上分配,这样就无需堆上分配内存,也无需进行垃圾回收,这就是常见的堆外存储技术

此外,基于OpenJDK 深度定制的 TaoBaoVM ,其中创新的GCIH(GC invisible Heap) 技术实现了 off-heap ,将声明周期长的java 对象从heap中移至 heap 外,并且 GC不能管理GCIH 内部的java对象, 以此达到降低GC的回收频率和提升GC回收效率的目的

概述

参数设置

代码优化

总结

栈是运行时的单位,而堆是存储单位 ,即 栈解决程序的运行问题,即程序如何执行,或者说如何处理数据,堆解决的是数据存储问题,即数据该往哪里放

每个线程在创建时都创建一个虚拟机栈,其内部都会保存一个栈帧,一个栈帧对应一个java方法

与线程一致

主管Java程序运行,它保存方法的局部变量,部分结果,并参与方法的调用与返回，栈是运行时的单位,而堆是存储单位 ,即 栈解决程序的运行问题,即程序如何执行,或者说如何处理数据,堆解决的是数据存储问题,即数据该往哪里放

栈是一种快速有效的分配存储方式,访问速度仅次于程序计数器

JVM 直接对Java 栈的操作只有两个

对于栈来说不存在垃圾回收问题

outofmemoryError(内存溢出)

stackOverflowError(栈溢出)

基本介绍

运行原理

栈帧的内部架构

<java 虚拟机>说明: 尽管所有的方法区在逻辑上属于堆的一部分,但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩, 但对于 HotSpot JVM 而言,方法区还有一个别名交 no-Heap (非堆),目的就是要与方法区分开,所以方法区看做是一块独立于java 堆的内存空间

1), 方法区 与 java 堆一样,是各个线程共享的内存区域

2), 方法区在 JVM启动的时候创建完成,并且它的实际物理内存区域和 java 堆区一样都可以是不连续的

3), 方法区的大小,根堆空间大小一样,可以选择固定大小或者可扩展

4), 方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区溢出的话 JDK8之前报 OutOfMemoryError: PermGen space , JDK8之后报 OutOfMemoryError:Metaspace

5), 关闭JVM就会释放这个区域

在JDK7之前,习惯上把方法区称为永久代,JDK8开始把永久代改为元空间

在JDK8后的改变完全废除了永久代的概念,改用与 JRockit ,J9 一样在本地内存中实现的元空间(Metaspace) 来代替

元空间的本质和永久代类似, 都是对JVM 规范中方法区的实现,不过元空间与永久代最大的区别在于 元空间不在虚拟机设置的内存中,而是使用本地内存

永久代,元空间 二者不只是名字变了,内部结构也调整了

根据<Java 虚拟机规范> 的规定,如果方法区无法满足新的内存分配需求时, 将抛出 OutOfMemoryError:Metaspace 异常

JDK8之后, 元空间可以使用惨 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 来设置元空间大小

默认依赖于平台, windows 下 -XX:MetaspaceSize 是21M; -XX:MaxMetaspaceSize是-1 即没有限制

与永久代不同,如果不指定大小,默认情况下,虚拟机会耗尽所有的可用系统内存,如果元数据发生溢出,虚拟机一样会抛出OOM异常

-XX:MetaspaceSize 设置初始的元空间大小,对于一个64位的服务端JVM来说,默认的21M 这就是初始的高水位线,一旦触及这个水位线,就会 Full GC 卸载那些没用的类,然后这个水位将会重置,新的高水位线取决于GC后释放多少空间,如果释放的空间不足,那么再不超过 MaxMetaspaceSize 时,适当提高该值,如果释放空间过多,则适当降低该值

如果初始化的高水位线设置过低,上述高水位线调整情况会发生很多次,通过垃圾回收器的日志可以观察到 FGC 多次调用,为了避免频繁GC ,建议将 -XX:MetaspaceSize 设置为一个相对较高的值

1), 要解决oom 异常或 heap space 的异常,一般的手段是 首先通过内存映射分析工具(jvisualvm.exe...) 对dump 出来的堆转储快照进行分析, 重点是确认呢日村中的对象是否是必要的,也就是要分析清除到底出现了内存泄漏(memory)还是内存溢出 (overflow)

2), 如果是内存泄漏,可进一步通过工具查看泄漏对象到 GC Roots 的引用链,于是就能找到泄漏对象是通过怎样的路径与GC Roots 相关联并导致垃圾收集器无法自动回收它们的, 掌握了泄漏对象的类型信息, 以及GC Roots 引用链信息 ,就可以比较准备的定位出泄漏代码的位置

3), 如果不存在内存在泄漏,换句话说 就是内存中的对象确定都还必须存活着, 那就应当检查虚拟机的堆参数,(-Xmx 与 Xms) ,与物理机内存对比看是否还可以增大,从代码上检查是否存在某些对象生命周期过长,持有状态时间过长的情况,尝试减少程序运行期间的内存消耗

它用于存储已被虚拟机加载的类型信息, 常量 ,静态变量, 即时编译器编译后的代码缓存等

为什么需要常量池?

常量池里面有什么?

常量池可以看做一张表, 虚拟机指令根据这张常量表找到要执行的类名,方法名,参数类型,字面量等类型

运行时常量池

方法区演进细节

永久代为什么要被元空间替换?

StringTable 为什么要调整?

方法区的垃圾收集

一个 Native Method 就是一个Java 调用非java代码的接口,一个 Native method 是这样一个java 接口,该方法的实现由非Java语言实现

1), 与Java 环境外交互,有时java 需要与外面的环境交互,这是本丢方法存在的主要原因

2), 与操作系统交互,通过使用本地方法,我们得以使用 Java 实现 jre 的域底层系统交互,甚至JVM的一部分C写的

3), sun的解释器是C实现的,这使得它能像一些普通的C一样与外部交互

目前该方法使用的越来越少了,除非是与硬件有关的应用

JVM 中的程序计数寄存器(Program Counter Register), Register 的名字源于CPU 的寄存器,寄存器存储的指令相关的现场信息,CPU 只有把数据装载到寄存器才能够运行

这里,并非广义上所指的物理寄存器,或许将其翻译为 PC计数器(或指令计数器)会更加贴切(也称为程序钩子) ,并非不容易引起一些不必要的误会,JVM 的

它是一块很小的内存空间,几乎可以忽略不计,也是运行速度最快的存储区域

在JVM规范中,每个线程都有它自己程序计数器,是线程私有的,声明周期与线程的声明周期一致

任何时间一个线程都只有一个方法在执行,也就是所谓的,程序计数器会存储当前线程正在执行的Java 方法的JVM指令地址 或者 如果是在执行native 方法,则是未指定值(undefind)

它是程序控制流的指示器, 分支,循环,跳转,异常处理,线程恢复等基础功能都需要依赖这个计数器来完成

字节码解释器在工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令

它是唯一一个在Java 虚拟机规范中没有规定任何 outofMemoryError 情况的区域

CPU 时间片即 CPU 分配给各个程序的时间,每个线程被分配一个时间段,称作它的时间片

在宏观上,我们可以同时打开多个应用程序,每个程序并不停止,同时在运行

在微观上,由于只有一个CPU,一次只能处理程序要求的一部分,如果处理公平,一种方式就是引入时间片,每个程序轮流执行

使用pc 寄存器存储字节码指令地址有什么用呢?

pc 寄存器为什么会被设定为线程私有的?

Java 7 与Java 8堆的区别

如何设置堆内存大小

如何查看使用gc情况

Minor GC ,Major GC 与Full GC区别

这个类加载使用C/C++语言实现，嵌套在JVM内部

它是用来加载java的核心内库（rt.jar，resource.jar或者sun.boot.class.path）路径下面的内容，提供JVM自身需要的类

并不继承与java.lang.ClassLoader没有父类加载器

加载扩展类加载器和应用程序加载器并指定他们的父类加载器

出于安全考虑，Bootstrap启动类加载器只加载包名为java,javax,sun等开头的类

java 语言编写，有Launcher的内部类

派生于ClassLoader类

父类加载器启动为启动类加载器

从java.ext.dirs系统属性所指定的目录中加载类库或从JDK的安装目录的jre/lib/ext子目录（拓展目录）下，如果用户创建的jar放在此目录，也会由拓展类加载器加载

java语言编写，有Launcher的内部类

派生于ClassLoader类

父类加载器启动为拓展类加载器

它负责加载环境classpath或系统属性，java.class.path指定路径下的类库

该类加载时程序中默认的类加载器，一般来说，java应用类都是由它来完成

通过ClassLoader#getSystemClassLoader()方法可以直接获取该类加载器

日常开发中，类加载器几乎由上述3种类加载器互相配合执行，必要时也可以自定义类加载器来定制类的加载方式

什么情况需要自定义类加载器

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器（Bootstrap ClassLoader)中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类

（向下委派）避免类的重复加载，保障所有类都被加载

（向下委派）保护程序安全，防止核心API被恶意篡改

比如我定义了一个类名为String所在包为java.lang，因为这个类本来是属于jdk的，如果没有沙箱安全机制的话，这个类将会污染到我所有的String,但是由于沙箱安全机制，所以就委托顶层的bootstrap加载器查找这个类，如果没有的话就委托extsion,extsion没有就到aapclassloader，但是由于String就是jdk的源代码，所以在bootstrap那里就加载到了，先找到先使用，所以就使用bootstrap里面的String,后面的一概不能使用，这就保证了不被恶意代码污染

创建类的实例

创建某个类或接口的静态变量或者对该静态变量赋值

调用类的静态方法

反射

初始化一个类的子类

Java虚拟机启动时被标记为启动类的类

JDK1.7开始提供的动态语言支持

除了主动使用外，其他都是被动使用，都不会导致类的初始化