Java之JVM

谈到JVM,对于很多干了三四年的程序员来说,还是很模糊。我待了好几个公司,问过很多干了3-5年Java开发的同事,大部分人其实对于JVM理解都不深(当然对于我自己来说,也是一样)。JVM相当于一个武林高手的内功,内功强大才是真的强,所以我用本文整理出来JVM的重点知识。

JVM总体分为四大块,每一块都有大量的细节内容说,这里只做主干梳理

一,类的加载机制

1.什么是类的加载

类的加载指的是将类的.class文件中的二进制数据读入到内存中,将其放在运行时数据区的方法区内,然后在堆区创建一个java.lang.Class对象,用来封装类在方法区的数据结构。类的加载最终是位于堆区中的Class对象,Class对象封装了类在方法区的数据结构,并且向程序员提供了访问方法区内的数据结构的接口

2.类的生命周期

类的生命周期包括这几个部分,加载、连接、初始化、使用和卸载。前三步是类的加载过程,如下图

其中 验证,准备,解析 为连接部分

加载:查找并加载类的二进制数据,在Java堆中也创建一个java.lang.Class类的对象

连接:连接又包含三块内容:验证、准备、解析。1)验证,文件格式、元数据、字节码、符号引用验证;2)准备,为类的静态变量分配内存,并将其初始化为默认值;3)解析,把类中的符号引用转换为直接引用

初始化:为类的静态变量赋予正确的初始值

使用:new出对象在程序中使用

卸载:执行垃圾回收

3.类加载器与双亲委派模型

从虚拟机角度看,只存在2种类加载器

一种是启动类加载器(Bootstrap ClassLoader),使用C++实现的,是虚拟机本身的一种。

一种是其他的类加载器,使用Java实现,独立于虚拟机,继承于java.lang.ClassLoader。

从Java开发者的角度看,类加载器可以进一步划分,一般情况分为3种

第一种:启动类加载器(Bootstrap ClassLoader) ,这个类加载器负责将存放在<JAVA_HOME>\lib目录下的,或被-Xbootclasspath参数所制定的路径种的,并且是被虚拟机识别的类库加载到虚拟机内存中启动类加载器无法被Java程序直接引用,用户在编写自定义类加载器时,如果需要加载请求委派到引导类加载器,可直接使用null代替即可。

第二种:扩展类加载器(Extension ClassLoader) ,该加载器由sun.misc.Lanucher$ExtClassLoader实现,负责加载<JAVA_HOME>\lib\ext目录中,或者被java.ext.dirs系统变量指定路径中的类库,开发者可以直接使用扩展类加载器

第三种:应用程序类加载器<Application ClassLoader>, 该类是ClassLoader中getSystemClassLoader()方法返回值,所以一般称为系统类加载器。负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序没有自定义类加载器,一般情况下是默认的类加载器

为什么采用双亲委派模型,如图

除启动类加载器外,所有其它类加载器都有其父类加载器。如果一个类加载器收到了类加载请求,它不会首先加载这个类,而是将请求委派给父类加载器去完成所有的加载请求最终都委派给顶层的引导类加载器,只有当父类加载器无法完成加载请求(也就是搜索范围内无该类)子加载器才会尝试自己去加载这个类

——使得Java类随着类加载器不同而具备带优先级的层次关系,如java.lang.Object(位于rt.jar内),无论那个类加载器要加载该类,最终都委派给顶层引导类加载器,因此Object类在程序的各种类加载环境中都是同一个类。

——如果没有双亲委派,用户自定义重名的类,将会使得系统带有多个同名的类,使得基础的Java类型体系混乱双亲委派模型对于保证Java程序的稳定运行十分重要,它实现却很简单首先检查是否被加载过,若没有加载则调用父类加载器的loadClass方法,若父类加载器为空,则默认使用引导类加载器作为父类加载器,如果加载失败,则调用自身的findClass()方法加载

——破坏双亲委派情形:使用JNDI服务、代码模块热部署

二,JVM内存结构

1.内存结构组成

方法区和堆是所有线程共享的内存区域;java栈、本地方法栈和程序计数器是运行线程私有的内存区域。

Java堆(Heap):是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存。

方法区(Method Area):方法区(Method Area)与Java堆一样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。

程序计数器(Program Counter Register):程序计数器(Program Counter Register)是一块较小的内存空间,它的作用可以看做是当前线程所执行的字节码的行号指示器。

JVM栈(JVM Stacks):与程序计数器一样,Java虚拟机栈(Java Virtual Machine Stacks)也是线程私有的,它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型:每个方法被执行的时候都会同时创建一个栈帧(Stack Frame)用于存储局部变量表、操作栈、动态链接、方法出口等信息。每一个方法被调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

本地方法栈(Native Method Stacks):本地方法栈(Native Method Stacks)与虚拟机栈所发挥的作用是非常相似的,其区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则是为虚拟机使用到的Native方法服务。

2.对象分配规则

JVM区域大体分为两个区域,如上图

对象优先分配在Eden区,如果Eden区没有足够的空间时,虚拟机执行一次Minor GC。

大对象直接进入老年代(大对象是指需要大量连续内存空间的对象)。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝(新生代采用复制算法收集内存)。

长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄计数器,如果对象经过了1次Minor GC那么对象会进入Survivor区,之后每经过一次Minor GC那么对象的年龄加1,知道达到阀值对象进入老年区。

动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象可以直接进入老年代。

空间分配担保。每次进行Minor GC时,JVM会计算Survivor区移至老年区的对象的平均大小,如果这个值大于老年区的剩余值大小则进行一次Full GC,如果小于检查HandlePromotionFailure设置,如果true则只进行Monitor GC,如果false则进行Full GC。

三,GC算法 垃圾回收

1.对象存活判断

判断对象是否存活一般有两种方式:

引用计数:每个对象有一个引用计数属性,新增一个引用时计数加1,引用释放时计数减1,计数为0时可以回收。此方法虽然简单,但是无法解决对象相互循环引用的问题。

可达性分析(Reachability Analysis):从GC Roots开始向下搜索,搜索走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的,为不可达对象。

2.GC算法

GC最基础的算法有三种:标记 -清除算法复制算法标记-压缩算法

我们常用的垃圾回收器一般都采用分代收集算法

标记 -清除算法:“标记-清除”(Mark-Sweep)算法,如它的名字一样,算法分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象,在标记完成后统一回收掉所有被标记的对象。

复制算法:“复制”(Copying)的收集算法,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。

标记-压缩算法:标记过程仍然与“标记-清除”算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存分代收集算法

分代收集(Generational Collection)算法:把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。

3.垃圾回收器

Serial收集器:串行收集器是最古老,最稳定以及效率高的收集器,可能会产生较长的停顿,只使用一个线程去回收。

ParNew收集器:ParNew收集器其实就是Serial收集器的多线程版本。

Parallel收集器:Parallel Scavenge收集器类似ParNew收集器,Parallel收集器更关注系统的吞吐量。

Parallel Old 收集器:Parallel Old是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-清理”算法

CMS收集器:CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。

G1收集器:G1 (Garbage-First)是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足GC停顿时间要求的同时,还具备高吞吐量性能特征

四,GC调优

1.调优工具

常用调优工具分为两类

JDK自带监控工具:JconsoleJvisualvm

第三方:MAT(Memory Analyzer Tool)GChisto

Jconsole,Java Monitoring and Management Console 是从java5开始,在JDK中自带的java监控和管理控制台,用于对JVM中内存,线程和类等的监控 

 Jvisualvm,jdk自带全能工具,可以分析内存快照、线程快照;监控内存变化、GC变化等。

MAT,Memory Analyzer Tool,一个基于Eclipse的内存分析工具,是一个快速、功能丰富的Java heap分析工具,它可以帮助我们查找内存泄漏和减少内存消耗

GChisto,一款专业分析gc日志的工具

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
【社区内容提示】社区部分内容疑似由AI辅助生成,浏览时请结合常识与多方信息审慎甄别。
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

相关阅读更多精彩内容

  • 一. JVM JVM是Java Virtual Machine(Java虚拟机)的缩写,也就是指的JVM虚拟机,是...
    大鹏的鹏阅读 4,751评论 1 0
  • 面试专题我放在git上了,地址Github 欢迎fork然后一起更新 1. 内存模型以及分区,需要详细到每个区放什...
    hloong阅读 5,800评论 3 4
  • 1.JVM的架构 说明: Java栈,程序计数器,本地方法栈是线程独享的方法区,堆是线程共享的 2.常用GC算法 ...
    zhglance阅读 2,953评论 0 2
  • go runtime和java jvm之间的共同点就是GC,通过两者的对比,可以更加深入理解两者。 go runt...
    Wu杰语阅读 5,851评论 0 1
  • 参考博客:1 2 3 JVM工作原理 java虚拟机体系结构Java平台由Java虚拟机和Java应用程序接口搭建...
    小明今晚加班阅读 4,911评论 0 33

友情链接更多精彩内容