JVM总结

JVM总结

JVM的位置

JVM在操作系统之上,它与硬件没有直接的交互!

JVM体系结构图

栈中绝不会有垃圾,否则会影响出栈,程序就死了!

类加载器ClassLoader

一个类加载到JVM的一个基本结构:

在如下几种情况下,java虚拟机将结束生命周期:

  1. 执行了System.exit()方法
  2. 程序正常执行结束
  3. 程序执行过程中遇到异常或者错误而终止
  4. 由于操作系统出现错误而导致java虚拟机终止

类的加载、连接与初始化

在Java代码中,类的加载、连接与初始化过程都是在程序运行期间完成的。

  • 加载:查找并加载类的二进制数据

  • 连接:

    • 验证:确保被加载的类的正确性
    • 准备:为类的静态变量分配内存,并将其初始化为默认值
    • 解析:把类中的符号引用转换为直接引用

    在编译的时候一个每个java类都会被编译成一个class文件,但在编译的时候虚拟机并不知道所引用类的地址,所以就用符号引用来代替,而在这个解析阶段就是为了把这个符号引用转化成为真正的地址的阶段。

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

通过代码来理解:

class Test{
  public static int a = 1;
}
//我们程序中给定的是 public static int a = 1; //但是在加载过程中的步骤如下:
/*
1. 加载阶段
编译文件为 .class文件,然后通过类加载,加载到JVM
2. 连接阶段
第一步(验证):确保Class类文件没问题 
第二步(准备):先初始化为 a=0。(因为你int类型的初始值为0) 
第三步(解析):将引用转换为直接引用
3. 初始化阶段: 通过此解析阶段,把1赋值为变量a
*/

类的加载

类的加载指的是将类的.class文件中二进制数据读入到内存中,将其放在运行时数据区内的方法区内,然后再内存中创建一个java.lang.Class对象用来封装类在方法区内的数据结构。

//对于静态字段来说,只有直接定义了该字段的类才会被初始化; 
//当一个类在初始化时,要求其父类全部都已经初始化完毕了; 
//所有Java虚拟机实现必须在每个类或者接口被Java程序“首次主动使用”时才初始化他们 
public class MyTest1 {
    public static void main (String[] args){
        System.out.println(MyChild1.str2);
    } 
}
class MyParent1{
    public static String str = "hello world";
    static {
        System.out.println("MyParent1 static block ");
    }
}
class MyChild1 extends MyParent1{
    public static String str2 = "welcome";
    static{
        System.out.println("MyChild1 static block ");
    }
}
// 输出结果:
MyParent1 static block 
MyChild1 static block 
welcome

查看类的加载信息,并打印出来:

jvm 参数介绍: 
    -XX:+TraceClassLoading,用于追踪类的加载信息并打印出来。
所有的参数都是:
  -XX:+

常量池概念

问题1

public class Test2 {
    public static void main(String[] args) {
        System.out.println(Parent2.str);
    }
}

class Parent2 {
    public static final String str = "hello world";

    static {
        System.out.println("parent2 静态代码块");//不会输出
    }
}

只会输出helloword,因为常量在编译阶段会存入到调用这个常量的方法所在的类的常量池中。本质上,调用类并没有直接用到定义常量的类,因此并不会触发定义常量的类的初始化。

简而言之,这里将常量存放到了Test2的常量池中,之后Test2与Parent2就没有任何关系了。但如果使用new Parent2()来调用,必将初始化Parent2,同时打印代码块里的内容。

问题2

public class Test3 {
    public static void main(String[] args){
        System.out.println(Parent3.str);
    }
}
class Parent3{
    public static final String str = UUID.randomUUID().toString();
    static {
        System.out.println("parent3 静态代码块");//会输出
    } 
}

答案是会输出静态代码块里的内容。和问题1案例不同的是,此常量的值调用其他方法,只要初始化运行的时候才会被确定。而问题1的常量的值在编译时就确定了。

ClassLoader分类

有两种类型的类加载器

  1. Java虚拟机自带的加载器
    • 根类加载器(BootStrap or BootClassLoader) sun.boot.class.path(加载系统的包,包含jdk核 心库内类)
    • 扩展类加载器(Extension or ExtClassLoader) java.ext.dirs(加载扩展jar包中的类)
    • 系统(应用)类加载器(System or AppClassLoader) java.class.path(加载你编写的类,编译后的类)
  2. 用户自定义的类加载器
    • Java.long.ClassLoader的子类(继承),用户可以定制类的加载方式

代码测试:

public class ClassLoaderDemo01 {
    public static void main(String[] args) {
        Object object = new Object();
        ClassLoaderDemo01 demo01 = new ClassLoaderDemo01();
        System.out.println(object.getClass().getClassLoader());
        System.out.println(demo01.getClass().getClassLoader());
        System.out.println(demo01.getClass().getClassLoader().getParent());
 System.out.println(demo01.getClass().getClassLoader().getParent().getParent
());
        /*
        结果:
            null
            sun.misc.Launcher$AppClassLoader@18b4aac2
            sun.misc.Launcher$ExtClassLoader@1b6d3586
            null
                **/
            } 
}

双亲委派机制

双亲委派机制的工作原理:一层一层的 让父类去加载,最顶层父类不能加载往下数,依次类推。

  1. 类加载器收到类加载的请求;
  2. 把这个请求委托给父加载器去完成,一直向上委托,直到启动类加载器
  3. 启动器加载器检查能不能加载(使用findClass()方法),能就加载(结束);否则抛出异常,通知子加载器进行加载
  4. 重复步骤三;

代码测试:

package java.lang;
public class String {
    public static void main(String[] args) {
        System.out.println(1);
    }
}

大家所熟知的String类,直接告诉大家,String默认情况下是启动类加载器进行加载的。假设我也自定义一个String 。现在你会发现自定义的String可以正常编译,但是永远无法被加载运行。这是因为申请自定义String加载时,总是启动类加载器,而不是自定义加载器,也不会是其他的加载器。双亲委派机制可以确保Java核心类库所提供的类,不会被自定义的类所替代。

Native方法

凡是带了native关键字的,说明java的作用范围达不到,去调用底层C语言的库!

JNI:Java Native Interface (Java本地方法接口)

凡是带了native关键字的方法就会进入本地方法栈--->Native Method Stack

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

程序计数器

每个线程都有一个程序计数器,是线程私有的。
程序计数器是一块较小的内存空间,它的作用可以看作是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。保证程序执行顺序。是一个非常小的内存空间,几乎可以忽略不计。

代码案例:

public class Calc {
    public int calc(){
        int a = 100;
            int b = 200;
            int c = 300;
            return ( a + b ) * c;
        }
}

反编译: Javap -c xx.class

  • ldc:表示将int、float或是String类型的常量值从常量池中推送至栈顶
  • bipush:表示将单字节(-128~127)的常量值推送至栈顶。
  • sipush:表示将短整型(-32767~32768)的常量值推送至栈顶。
  • istore_1:将一个数值从操作数栈存储到局部变量表
  • iadd:加
  • imul:乘

图中使用红框框起来的就是字节码指令的偏移地址,偏移地址对应的bipush 等等是jvm中的操作指令, 这是入栈指令。 当执行到方法calc()时在当前的线程中会创建相应的程序计数器,在计数器中为存放执 行地址 (红框中的)0 2 3...等等

方法区

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

什么是栈

  1. 栈也叫栈内存,主管Java程序的运行,是在线程创建时创建,它的生命期是跟随线程的生命期,线程 结束栈内存也就释放。
  2. 对于栈来说不存在垃圾回收问题,只要线程一旦结束,该栈就Over,生命周期和线程一致,是线程私有的。

栈的运行原理

Java栈的组成元素是栈帧,栈帧是一种用于帮助虚拟机执行方法调用与方法执行的数据结构。他是独立于线程的,一个线程有自己的一个栈帧。封装了方法的局部变量表、动态链接信息、方法的返回地址以及操作数栈等信息。
第一个方法从调用开始到执行完成,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。

Java堆是java虚拟机所管理内存中最大的一块内存空间,处于物理上不连续的内存空间,只要逻辑连续即可,主要用于存放各种类的实例对象。该区域被所有线程共享,在虚拟机启动时创建,用来存放对象的实例,几乎所有的对象以及数组都在这里分配内存(栈上分配、标量替换优化技术的例外)。
在 Java 中,堆被划分成两个不同的区域:新生代 ( Young )老年代 ( Old )新生代 ( Young ) 又被划分为三个区域:EdenFrom Survivor(S0)To Survivor(S1)。如图所示:

新生代

新生代是类诞生,成长,消亡的区域,一个类在这里产生,应用,最后被垃圾回收器收集,结束生命。

新生代含有两部分:伊甸区(Eden Space)和幸存者区(Survivor Space),所有的类都是在伊甸区被new出来的,幸存区有两个:0区和1区,当伊甸园的空间用完时,程序又需要创建对象,JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)。将伊甸园中的剩余对象移动到幸存0区,若幸存0区也满了,再对该区进行垃圾回收,然后移动到1区,那如果1区也满了呢?(这里幸存0区和1区是一个互相交替的过程)再移动到老年代,若老年代也满了,那么这个时候将产生MajorGC(Full GC),进行老年区的内存清理,若老年代执行了Full GC后发现依然无法进行对象的保存,就会产生OOM异常 “OutOfMemoryError ”。

如果出现 java.lang.OutOfMemoryError:java heap space异常,说明Java虚拟机的堆内存不够,原因如下:

  1. Java虚拟机的堆内存设置不够,可以通过参数 -Xms(初始值大小),-Xmx(最大大小)来调整。
  2. 代码中创建了大量大对象,并且长时间不能被垃圾收集器收集(存在被引用)或者死循环

永久代

永久存储区是一个常驻内存区域,用于存放JDK自身所携带的Class,Interface的元数据,也就是说它存储的是运行环境必须的类信息,被装载进此区域的数据是不会被垃圾回收器回收掉的,关闭JVM才会释 放此区域所占用的内存。

如果出现java.lang.OutOfMemoryError:PermGen space,说明是Java虚拟机对永久代Perm内存设置不够。一般出现这种情况,都是程序启动需要加载大量的第三方jar包,例如:在一个Tomcat下部署了太多的应用。或者大量动态反射生成的类不断被加载,最终导致Perm区被占满。

注意:

Jdk1.6之前 : 有永久代,常量池1.6在方法区
Jdk1.7. : 有永久代,但是已经逐步 “去永久代”,常量池1.7在堆
Jdk1.8及之后: 无永久代,常量池1.8在元空间(1.8之前的永久代)

堆内存调优

-Xms :设置初始分配大小,默认为物理内存的“1/64”

-Xmx :最大分配内存,默认为物理内存的“1/4”

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

Dump内存快照

在idea中也有这么一个插件, 就是JProfiler,一款性能瓶颈分析工具! 需要在idea里下载拆件,并在Settings–Tools–JProflier–JProflier executable中配置JProfile安装可执行文件

作用:

  1. 分析Dump文件,快速定位内存泄漏;
  2. 获得堆中对象的统计数据
  3. 获得对象相互引用的关系
  4. 采用树形展现对象间相互引用的情况

代码测试:

public class Demo03 {
    byte[] byteArray = new byte[1*1024*1024]; //1M = 1024K
    public static void main(String[] args) {
        ArrayList list = new ArrayList<>();
        int count = 0;
        try {
    while (true){
        list.add(new Demo03());
        count = count + 1;
}
}catch (Error e){
    System.out.println("count:"+count);
    e.printStackTrace();
}
}
}

vm参数 :-Xms1m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

运行结果

找到文件,并用jprofiler打开,即可进行分析

GC垃圾回收

GC作用域在于方法区和堆

JVM在进行GC时,并非每次都对上面三个内存区域一起回收的,大部分时候回收的都是指新生代
因此GC按照回收的区域又分了两种类型,一种是普通的GC(minor GC),一种是全局GC (major GC or Full GC)
普通GC:只针对新生代区域的GC
全局GC:针对老年代的GC,偶尔伴随对新生代的GC以及对永久代的GC

判断垃圾可以回收的算法

引用计数法

基本概念:

引用计数是垃圾收集器中的早期策略。在这种方法中,堆中每个对象实例都有一个引用计数。当一个对象被创建时,就将该对象实例分配给一个变量,该变量计数设置为 1。当任何其它变量被赋值为这个对象的引用时,计数加1(a = b,则 b 引用的对象实例的计数器加 1),但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时,对象实例的引用计数器减 1。任何引用计数器为 0 的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时,它引用的任何对象实例的引用计数器减 1。

优点:

引用计数收集器可以很快的执行,交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。

缺点:

无法检测出循环引用。如父对象有一个对子对象的引用,子对象反过来引用父对象。这样,他们的引用计数永远不可能为 0。

可达性分析算法

基本概念:

可达性分析算法是从离散数学中的图论引入的,程序把所有的引用关系看作一张图,从一个节点 GC ROOT 开始,寻找对应的引用节点,找到这个节点以后,继续寻找这个节点的引用节点,当所有的引用节点寻找完毕之后,剩余的节点则被认为是没有被引用到的节点,即无用的节点,无用的节点将会被判定为是可回收的对象。

在Java语言中,可作为GC Roots的对象包括下面几种:

  1. 虚拟机栈中引用的对象(栈帧中的本地变量表)
  2. 方法区中类静态属性引用的对象
  3. 方法区中常量引用的对象
  4. 本地方法栈中 JNI(Native方法)引用的对象

常用的垃圾收集算法

标记清除算法(Mark-Sweep)

标记-清除算法采用从根集合(GC Roots)进行扫描,对存活的对象进行标记,标记完毕后,再扫描整个空间中未被标记的对象,进行回收。标记-清除算法不需要进行对象的移动,只需对不存活的对象进行处理,在存活对象比较多的情况下极为高效,但由于标记-清除算法直接回收不存活的对象,因此会造成内存碎片。

缺点:

这个算法需要暂停整个应用,会产生内存碎片。所谓的内存碎片就是这块哈希地址不可用了,出现零散的内存碎片。碎片最直接的问题就是会导致无法分配大块的内存空间,以及程序运行效率降低。
用通俗的话解释一下 标记/清除算法,就是当程序运行期间,若可以使用的内存被耗尽的时候,GC线程 就会被触发并将程序暂停,随后将依旧存活的对象标记一遍,最终再将堆中所有没被标记的对象全部清 除掉,接下来便让程序恢复运行。

复制算法(Copying)

当对象在Eden(包括一个Survivor区域,这里假设是From区域)出生后,在经过一次Minor GC后,如 果对象还存活,并且能够被另外一块Survivor区域所容纳 (上面已经假设为from区域,这里应为to区域,即to区域有足够的内存空间来存储Eden 和 From 区域中存活的对象),则使用复制算法将这些仍然 还活着的对象复制到另外一块Survivor区域(即 to 区域)中,然后清理所使用过的Eden 以及Survivor 区域(即form区域),并且将这些对象的年龄设置为1,以后对象在Survivor区,每熬过一次Minor GC,就将这个对象的年龄 + 1,当这个对象的年龄达到某一个值的时候(默认是15岁,通过-XX:MaxTenuringThreshold 设定参数)这些对象就会成为老年代。

如何判断哪个是幸存区中的to区呢? 一句话:谁空谁是to

标记压缩(Mark-Compact)

在整理压缩阶段,不再对标记的对象作回收,而是通过所有存活对象都像一端移动,然后直接清除边界 以外的内存。可以看到,标记的存活对象将会被整理,按照内存地址依次排列,而未被标记的内存会被 清理掉,如此一来,当我们需要给新对象分配内存时,JVM只需要持有一个内存的起始地址即可,这比 维护一个空闲列表显然少了许多开销。

分代收集算法

年轻代(Young Generation)的回收算法 (主要以 Copying 为主)

  1. 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
  2. 新生代发生的 GC 也叫做 Minor GC,MinorGC 发生频率比较高(不一定等 Eden 区满了才触发)

年老代(Old Generation)的回收算法(主要以 Mark-Compact 为主)

  1. 在年轻代中经历了 N 次垃圾回收后仍然存活的对象,就会被放到年老代中。因此,可以认为年老代中存放的都是一些生命周期较长的对象
  2. 内存比新生代也大很多(大概比例是1 : 2),当老年代内存满时触发 Major GC 即 Full GC,Full GC 发生频率比较低,老年代对象存活时间比较长,存活率标记高

你可能感兴趣的:(JVM总结)