Java虚拟机工作原理详解 ( 二 )

Java虚拟机工作原理详解 ( 二 )

首先这里澄清两个概念:JVM实例和JVM执行引擎实例,JVM实例对应了一个独立运行的Java程序,而JVM执行引擎实例则对应了属于用户运行程序的线程;也就是JVM实例是进程级别,而执行引擎是线程级别的。

JVM是什么?—JVM的生命周期

JVM实例的诞生:当启动一个Java程序时,一个JVM实例就产生了,任何一个拥有 publicstaticvoidmain(String[]args)函数的class都可以作为JVM实例运行的起点,既然如此,那么JVM如何知道 是运行classA的main而不是运行classB的main呢?这就需要显式的告诉JVM类名,也就是我们平时运行Java程序命令的由来,如 JavaclassAhelloworld,这里Java是告诉os运行SunJava2SDK的Java虚拟机,而classA则指出了运行JVM所需 要的类名。

JVM实例的运行:main()作为该程序初始线程的起点,任何其他线程均由该线程启动。JVM内部有两种线程:守护线程和非守护线程,main()属于 非守护线程,守护线程通常由JVM自己使用,Java程序也可以标明自己创建的线程是守护线程。JVM实例的消亡:当程序中的所有非守护线程都终止 时,JVM才退出;若安全管理器允许,程序也可以使用Runtime类或者System.exit()来退出。

JVM是什么?—JVM的体系结构

粗略分来,JVM的内部体系结构分为三部分,分别是:类装载器(ClassLoader)子系统,运行时数据区,和执行引擎。下面将先介绍类装载器,然后是执行引擎,*后是运行时数据区

1,类装载器,顾名思义,就是用来装载.class文件的。JVM的两种类装载器包括:启动类装载器和用户自定义类装载器,启动类装载器是JVM实现的一 部分,用户自定义类装载器则是Java程序的一部分,必须是ClassLoader类的子类。(下面所述情况是针对SunJDK1.2)

动类装载器:只在系统类(JavaAPI的类文件)的安装路径查找要装入的类

用户自定义类装载器:

系统类装载器:在JVM启动时创建,用来在CLASSPATH目录下查找要装入的类其他用户自定义类装载器:这里有必要先说一下ClassLoader类的几个方法,了解它们对于了解自定义类装载器如何装载.class文件至关重要。

  1. protectedfinalvoidresolveClass(Classc)

defineClass用来将二进制class文件(新类型)导入到方法区,也就是这里指的类是用户自定义的类(也就是负责装载类)

findSystemClass通过类型的全限定名,先通过系统类装载器或者启动类装载器来装载,并返回Class对象。

ResolveClass:让类装载器进行连接动作(包括验证,分配内存初始化,将类型中的符号引用解析为直接引用),这里涉及到Java命名空间的问 题,JVM保证被一个类装载器装载的类所引用的所有类都被这个类装载器装载,同一个类装载器装载的类之间可以相互访问,但是不同类装载器装载的类看不见对 方,从而实现了有效的屏蔽。

2,执行引擎:它或者在执行字节码,或者执行本地方法

要说执行引擎,就不得不的指令集,每一条指令包含一个单字节的操作码,后面跟0个或者多个操作数。

(一)指令集以栈为设计中心,而非以寄存器为中心这种指令集设计如何满足Java体系的要求:

平台无关性:以栈为中心使得在只有很少register的机器上实现Java更便利compiler一般采用stack向连接优化器传递编译的中间结果, 若指令集以stack为基础,则有利于运行时进行的优化工作与执行即时编译或者自适应优化的执行引擎结合,通俗的说就是使编译和运行用的数据结构统一,更 有利于优化的开展。

网络移动性:class文件的紧凑性。

安全性:指令集中*大部分操作码都指明了操作的类型。(在装载的时候使用数据流分析期进行一次性验证,而非在执行每条指令的时候进行验证,有利于提高执行速度)。

(二)执行技术

主要的执行技术有:解释,即时编译,自适应优化、芯片级直接执行其中解释属于*代JVM,即时编译JIT属于第二代JVM,自适应优化(目前Sun的HotspotJVM采用这种技术)则吸取*代JVM和第二代JVM的经验,采用两者结合的方式

自适应优化:开始对所有的代码都采取解释执行的方式,并监视代码执行情况,然后对那些经常调用的方法启动一个后台线程,将其编译为本地代码,并进行仔细优化。若方法不再频繁使用,则取消编译过的代码,仍对其进行解释执行。

3,运行时数据区:主要包括:方法区,堆,Java栈,PC寄存器,本地方法栈

(1)方法区和堆由所有线程共享

堆:存放所有程序在运行时创建的对象

方法区:当JVM的类装载器加载.class文件,并进行解析,把解析的类型信息放入方法区。

(2)Java栈和PC寄存器由线程独享,在新线程创建时间里

(3)本地方法栈:存储本地方法调用的状态

上边总体介绍了运行时数据区的主要内容,下边进行详细介绍,要介绍数据区,就不得不说明JVM中的数据类型。

JVM中的数据类型:JVM中基本的数据单元是word,而word的长度由JVM具体的实现者来决定

数据类型包括基本类型和引用类型,

(1)基本类型包括:数值类型(包括除boolean外的所有的Java基本数据类型),boolean(在JVM中使用int来表示,0表示false,其他int值均表示true)和returnAddress(JVM的内部类型,用来实现finally子句)。

(2)引用类型包括:数组类型,类类型,接口类型

前边讲述了JVM中数据的表示,下面让我们输入到JVM的数据区

首先来看方法区:

上边已经提到,方法区主要用来存储JVM从class文件中提取的类型信息,那么类型信息是如何存储的呢?众所周知,Java使用的是大端序 (big?endian:即低字节的数据存储在高位内存上,如对于1234,12是高位数据,34为低位数据,则Java中的存储格式应该为12存在内存 的低地址,34存在内存的高地址,x86中的存储格式与之相反)来存储数据,这实际上是在class文件中数据的存储格式,但是当数据倒入到方法区中 时,JVM可以以任何方式来存储它。

类型信息:包括class的全限定名,class的直接父类,类类型还是接口类型,类的修饰符(public,等),所有直接父接口的列表,Class对 象提供了访问这些信息的窗口(可通过Class.forName(“”)或instance.getClass()获得),下面是Class的方法,相信 大家看了会恍然大悟,(原来如此J)

getName(),getSuperClass(),isInterface(),getInterfaces(),getClassLoader();

static变量作为类型信息的一部分保存

指向ClassLoader类的引用:在动态连接时装载该类中引用的其他类

指向Class类的引用:必然的,上边已述

该类型的常量池:包括直接常量(String,integer和floatpoint常量)以及对其他类型、字段和方法的符号引用(注意:这里的常量池并 不是普通意义上的存储常量的地方,这些符号引用可能是我们在编程中所接触到的变量),由于这些符号引用,使得常量池成为Java程序动态连接中至关重要的 部分

字段信息:普通意义上的类型中声明的字段

方法信息:类型中各个方法的信息

编译期常量:指用final声明或者用编译时已知的值初始化的类变量

class将所有的常量复制至其常量池或者其字节码流中。

方法表:一个数组,包括所有它的实例可能调用的实例方法的直接引用(包括从父类中继承来的)

除此之外,若某个类不是抽象和本地的,还要保存方法的字节码,操作数栈和该方法的栈帧,异常表。

举例:

  1. privateintspeed5LavalavanewLava}

 

 

运行命令JavaVolcano;

(1)JVM找到Volcano.class倒入,并提取相应的类型信息到方法区。通过执行方法区中的字节码,JVM执行main()方法,(执行时会一直保存指向Vocano类的常量池的指针)

(2)Main()中*条指令告诉JVM需为列在常量池*项的类分配内存(此处再次说明了常量池并非只存储常量信息),然后JVM找到常量池的* 项,发现是对Lava类的符号引用,则检查方法区,看Lava类是否装载,结果是还未装载,则查找“Lava.class”,将类型信息写入方法区,并将 方法区Lava类信息的指针来替换Volcano原常量池中的符号引用,即用直接引用来替换符号引用。

(3)JVM看到new关键字,准备为Lava分配内存,根据Volcano的常量池的*项找到Lava在方法区的位置,并分析需要多少对空间,确定后,在堆上分配空间,并将speed变量初始为0,并将lava对象的引用压到栈中

(4)调用lava的flow()方法

好了,大致了解了方法区的内容后,让我们来看看堆

Java对象的堆实现:

Java对象主要由实例变量(包括自己所属的类和其父类声明的)以及指向方法区中类数据的指针,指向方法表的指针,对象锁(非必需),等待集合(非必 需),GC相关的数据(非必需)(主要视GC算法而定,如对于标记并清除算法,需要标记对象是否被引用,以及是否已调用finalize()方法)。

那么为什么Java对象中要有指向类数据的指针呢?我们从几个方面来考虑

首先:当程序中将一个对象引用转为另一个类型时,如何检查转换是否允许?需用到类数据

其次:动态绑定时,并不是需要引用类型,而是需要运行时类型,

这里的迷惑是:为什么类数据中保存的是实际类型,而非引用类型?这个问题先留下来,我想在后续的读书笔记中应该能明白

指向方法表的指针:这里和C++的VTBL是类似的,有利于提高方法调用的效率

对象锁:用来实现多个线程对共享数据的互斥访问

等待集合:用来让多个线程为完成共同目标而协调功过。(注意Object类中的wait(),notify(),notifyAll()方法)。

Java数组的堆实现:数组也拥有一个和他们的类相关联的Class实例,具有相同dimension和type的数组是同一个类的实例。数组类名的表 示:如[[LJava/lang/Object表示Object[][],[I表示int[],[[[B表示byte[][][]

至此,堆已大致介绍完毕,下面来介绍程序计数器和Java栈

 

程序计数器:为每个线程独有,在线程启动时创建,

 

若thread执行Java方法,则PC保存下一条执行指令的地址。

 

若thread执行native方法,则Pc的值为undefined

 

Java栈:Java栈以帧为单位保存线程的运行状态,Java栈只有两种操作,帧的压栈和出栈。

 

每个帧代表一个方法,Java方法有两种返回方式,return和抛出异常,两种方式都会导致该方法对应的帧出栈和释放内存。

 

帧的组成:局部变量区(包括方法参数和局部变量,对于instance方法,还要首先保存this类型,其中方法参数按照声明顺序严格放置,局部变量可以任意放置),操作数栈,帧数据区(用来帮助支持常量池的解析,正常方法返回和异常处理)。

 

本地方法栈:依赖于本地方法的实现,如某个JVM实现的本地方法借口使用C连接模型,则本地方法栈就是C栈,可以说某线程在调用本地方法时,就进入了一个不受JVM限制的领域,也就是JVM可以利用本地方法来动态扩展本身。

相信大家都明白JVM是什么了吧

JVM内幕:Java虚拟机详解

转载自:https://www.cnblogs.com/yhl-yh/p/7145218.html

这篇文章解释了Java 虚拟机(JVM)的内部架构。下图显示了遵守 Java SE 7 规范的典型的 JVM 核心内部组件。

%title插图%num

上图显示的组件分两个章节解释。*章讨论针对每个线程创建的组件,第二章节讨论了线程无关组件。

  • 线程
    • JVM 系统线程
    • 每个线程相关的
    • 程序计数器
    • 本地栈
    • 栈限制
    • 栈帧
    • 局部变量数组
    • 操作数栈
    • 动态链接
  • 线程共享
    • 内存管理
    • 非堆内存
    • 即时编译
    • 方法区
    • 类文件结构
    • 类加载器
    • 更快的类加载
    • 方法区在哪里
    • 类加载器参考
    • 运行时常量池
    • 异常表
    • 符号表
    • Interned 字符串

线程

这里所说的线程指程序执行过程中的一个线程实体。JVM 允许一个应用并发执行多个线程。Hotspot JVM 中的 Java 线程与原生操作系统线程有直接的映射关系。当线程本地存储、缓冲区分配、同步对象、栈、程序计数器等准备好以后,就会创建一个操作系统原生线程。Java 线程结束,原生线程随之被回收。操作系统负责调度所有线程,并把它们分配到任何可用的 CPU 上。当原生线程初始化完毕,就会调用 Java 线程的 run() 方法。run() 返回时,被处理未捕获异常,原生线程将确认由于它的结束是否要终止 JVM 进程(比如这个线程是*后一个非守护线程)。当线程结束时,会释放原生线程和 Java 线程的所有资源。

JVM 系统线程

如果使用 jconsole 或者其它调试器,你会看到很多线程在后台运行。这些后台线程与触发 public static void main(String[]) 函数的主线程以及主线程创建的其他线程一起运行。Hotspot JVM 后台运行的系统线程主要有下面几个:

虚拟机线程(VM thread) 这个线程等待 JVM 到达安全点操作出现。这些操作必须要在独立的线程里执行,因为当堆修改无法进行时,线程都需要 JVM 位于安全点。这些操作的类型有:stop-the-world 垃圾回收、线程栈 dump、线程暂停、线程偏向锁(biased locking)解除。
周期性任务线程 这线程负责定时器事件(也就是中断),用来调度周期性操作的执行。
GC 线程 这些线程支持 JVM 中不同的垃圾回收活动。
编译器线程 这些线程在运行时将字节码动态编译成本地平台相关的机器码。
信号分发线程 这个线程接收发送到 JVM 的信号并调用适当的 JVM 方法处理。

线程相关组件

每个运行的线程都包含下面这些组件:

程序计数器(PC)

PC 指当前指令(或操作码)的地址,本地指令除外。如果当前方法是 native 方法,那么PC 的值为 undefined。所有的 CPU 都有一个 PC,典型状态下,每执行一条指令 PC 都会自增,因此 PC 存储了指向下一条要被执行的指令地址。JVM 用 PC 来跟踪指令执行的位置,PC 将实际上是指向方法区(Method Area)的一个内存地址。

栈(Stack)

每个线程拥有自己的栈,栈包含每个方法执行的栈帧。栈是一个后进先出(LIFO)的数据结构,因此当前执行的方法在栈的顶部。每次方法调用时,一个新的栈帧创建并压栈到栈顶。当方法正常返回或抛出未捕获的异常时,栈帧就会出栈。除了栈帧的压栈和出栈,栈不能被直接操作。所以可以在堆上分配栈帧,并且不需要连续内存。

Native栈

并非所有的 JVM 实现都支持本地(native)方法,那些提供支持的 JVM 一般都会为每个线程创建本地方法栈。如果 JVM 用 C-linkage 模型实现 JNI(Java Native Invocation),那么本地栈就是一个 C 的栈。在这种情况下,本地方法栈的参数顺序、返回值和典型的 C 程序相同。本地方法一般来说可以(依赖 JVM 的实现)反过来调用 JVM 中的 Java 方法。这种 native 方法调用 Java 会发生在栈(一般是 Java 栈)上;线程将离开本地方法栈,并在 Java 栈上开辟一个新的栈帧。

栈的限制

栈可以是动态分配也可以固定大小。如果线程请求一个超过允许范围的空间,就会抛出一个StackOverflowError。如果线程需要一个新的栈帧,但是没有足够的内存可以分配,就会抛出一个 OutOfMemoryError。

栈帧(Frame)

每次方法调用都会新建一个新的栈帧并把它压栈到栈顶。当方法正常返回或者调用过程中抛出未捕获的异常时,栈帧将出栈。更多关于异常处理的细节,可以参考下面的异常信息表章节。

每个栈帧包含:

  • 局部变量数组
  • 返回值
  • 操作数栈
  • 类当前方法的运行时常量池引用

局部变量数组

局部变量数组包含了方法执行过程中的所有变量,包括 this 引用、所有方法参数、其他局部变量。对于类方法(也就是静态方法),方法参数从下标 0 开始,对于对象方法,位置0保留为 this。

有下面这些局部变量:

  • boolean
  • byte
  • char
  • long
  • short
  • int
  • float
  • double
  • reference
  • returnAddress

除了 long 和 double 类型以外,所有的变量类型都占用局部变量数组的一个位置。long 和 double 需要占用局部变量数组两个连续的位置,因为它们是 64 位双精度,其它类型都是 32 位单精度。

操作数栈

操作数栈在执行字节码指令过程中被用到,这种方式类似于原生 CPU 寄存器。大部分 JVM 字节码把时间花费在操作数栈的操作上:入栈、出栈、复制、交换、产生消费变量的操作。因此,局部变量数组和操作数栈之间的交换变量指令操作通过字节码频繁执行。比如,一个简单的变量初始化语句将产生两条跟操作数栈交互的字节码。

int i;

 

被编译成下面的字节码:

iconst_0    // Push 0 to top of the operand stack

istore_1    // Pop value from top of operand stack and store as local variable 1

 

更多关于局部变量数组、操作数栈和运行时常量池之间交互的详细信息,可以在类文件结构部分找到。

动态链接

每个栈帧都有一个运行时常量池的引用。这个引用指向栈帧当前运行方法所在类的常量池。通过这个引用支持动态链接(dynamic linking)。

C/C++ 代码一般被编译成对象文件,然后多个对象文件被链接到一起产生可执行文件或者 dll。在链接阶段,每个对象文件的符号引用被替换成了*终执行文件的相对偏移内存地址。在 Java中,链接阶段是运行时动态完成的。

当 Java 类文件编译时,所有变量和方法的引用都被当做符号引用存储在这个类的常量池中。符号引用是一个逻辑引用,实际上并不指向物理内存地址。JVM 可以选择符号引用解析的时机,一种是当类文件加载并校验通过后,这种解析方式被称为饥饿方式。另外一种是符号引用在*次使用的时候被解析,这种解析方式称为惰性方式。无论如何 ,JVM 必须要在*次使用符号引用时完成解析并抛出可能发生的解析错误。绑定是将对象域、方法、类的符号引用替换为直接引用的过程。绑定只会发生一次。一旦绑定,符号引用会被完全替换。如果一个类的符号引用还没有被解析,那么就会载入这个类。每个直接引用都被存储为相对于存储结构(与运行时变量或方法的位置相关联的)偏移量。

线程间共享

堆被用来在运行时分配类实例、数组。不能在栈上存储数组和对象。因为栈帧被设计为创建以后无法调整大小。栈帧只存储指向堆中对象或数组的引用。与局部变量数组(每个栈帧中的)中的原始类型和引用类型不同,对象总是存储在堆上以便在方法结束时不会被移除。对象只能由垃圾回收器移除。

为了支持垃圾回收机制,堆被分为了下面三个区域:

  • 新生代
    • 经常被分为 Eden 和 Survivor
  • 老年代
  • 永久代

内存管理

对象和数组永远不会显式回收,而是由垃圾回收器自动回收。通常,过程是这样的:

  1. 新的对象和数组被创建并放入老年代。
  2. Minor垃圾回收将发生在新生代。依旧存活的对象将从 eden 区移到 survivor 区。
  3. Major垃圾回收一般会导致应用进程暂停,它将在三个区内移动对象。仍然存活的对象将被从新生代移动到老年代。
  4. 每次进行老年代回收时也会进行永久代回收。它们之中任何一个变满时,都会进行回收。

非堆内存

非堆内存指的是那些逻辑上属于 JVM 一部分对象,但实际上不在堆上创建。

非堆内存包括:

  • 永久代,包括:
    • 方法区
    • 驻留字符串(interned strings)
  • 代码缓存(Code Cache):用于编译和存储那些被 JIT 编译器编译成原生代码的方法。

即时编译(JIT)

Java 字节码是解释执行的,但是没有直接在 JVM 宿主执行原生代码快。为了提高性能,Oracle Hotspot 虚拟机会找到执行*频繁的字节码片段并把它们编译成原生机器码。编译出的原生机器码被存储在非堆内存的代码缓存中。通过这种方法,Hotspot 虚拟机将权衡下面两种时间消耗:将字节码编译成本地代码需要的额外时间和解释执行字节码消耗更多的时间。

方法区

方法区存储了每个类的信息,比如:

  • Classloader 引用
  • 运行时常量池
    • 数值型常量
    • 字段引用
    • 方法引用
    • 属性
  • 字段数据
    • 针对每个字段的信息
      • 字段名
      • 类型
      • 修饰符
      • 属性(Attribute)
  • 方法数据
    • 每个方法
      • 方法名
      • 返回值类型
      • 参数类型(按顺序)
      • 修饰符
      • 属性
  • 方法代码
    • 每个方法
      • 字节码
      • 操作数栈大小
      • 局部变量大小
      • 局部变量表
      • 异常表
      • 每个异常处理器
      • 开始点
      • 结束点
      • 异常处理代码的程序计数器(PC)偏移量
      • 被捕获的异常类对应的常量池下标

所有线程共享同一个方法区,因此访问方法区数据的和动态链接的进程必须线程安全。如果两个线程试图访问一个还未加载的类的字段或方法,必须只加载一次,而且两个线程必须等它加载完毕才能继续执行。

类文件结构

一个编译后的类文件包含下面的结构:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

ClassFile {

    u4            magic;

    u2            minor_version;

    u2            major_version;

    u2            constant_pool_count;

    cp_info        contant_pool[constant_pool_count – 1];

    u2            access_flags;

    u2            this_class;

    u2            super_class;

    u2            interfaces_count;

    u2            interfaces[interfaces_count];

    u2            fields_count;

    field_info        fields[fields_count];

    u2            methods_count;

    method_info        methods[methods_count];

    u2            attributes_count;

    attribute_info    attributes[attributes_count];

}

magic, minor_version, major_version 类文件的版本信息和用于编译这个类的 JDK 版本。
constant_pool 类似于符号表,尽管它包含更多数据。下面有更多的详细描述。
access_flags 提供这个类的描述符列表。
this_class 提供这个类全名的常量池(constant_pool)索引,比如org/jamesdbloom/foo/Bar。
super_class 提供这个类的父类符号引用的常量池索引。
interfaces 指向常量池的索引数组,提供那些被实现的接口的符号引用。
fields 提供每个字段完整描述的常量池索引数组。
methods 指向constant_pool的索引数组,用于表示每个方法签名的完整描述。如果这个方法不是抽象方法也不是 native 方法,那么就会显示这个函数的字节码。
attributes 不同值的数组,表示这个类的附加信息,包括 RetentionPolicy.CLASS 和 RetentionPolicy.RUNTIME 注解。

可以用 javap 查看编译后的 java class 文件字节码。

如果你编译下面这个简单的类:

1

2

3

4

5

6

package org.jvminternals;

public class SimpleClass {

    public void sayHello() {

        System.out.println("Hello");

    }

}

运行下面的命令,就可以得到下面的结果输出: javap -v -p -s -sysinfo -constants classes/org/jvminternals/SimpleClass.class。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

public class org.jvminternals.SimpleClass

  SourceFile: "SimpleClass.java"

  minor version: 0

  major version: 51

  flags: ACC_PUBLIC, ACC_SUPER

Constant pool:

   #1 = Methodref          #6.#17         //  java/lang/Object."<init>":()V

   #2 = Fieldref           #18.#19        //  java/lang/System.out:Ljava/io/PrintStream;

   #3 = String             #20            //  "Hello"

   #4 = Methodref          #21.#22        //  java/io/PrintStream.println:(Ljava/lang/String;)V

   #5 = Class              #23            //  org/jvminternals/SimpleClass

   #6 = Class              #24            //  java/lang/Object

   #7 = Utf8               <init>

   #8 = Utf8               ()V

   #9 = Utf8               Code

  #10 = Utf8               LineNumberTable

  #11 = Utf8               LocalVariableTable

  #12 = Utf8               this

  #13 = Utf8               Lorg/jvminternals/SimpleClass;

  #14 = Utf8               sayHello

  #15 = Utf8               SourceFile

  #16 = Utf8               SimpleClass.java

  #17 = NameAndType        #7:#8          //  "<init>":()V

  #18 = Class              #25            //  java/lang/System

  #19 = NameAndType        #26:#27        //  out:Ljava/io/PrintStream;

  #20 = Utf8               Hello

  #21 = Class              #28            //  java/io/PrintStream

  #22 = NameAndType        #29:#30        //  println:(Ljava/lang/String;)V

  #23 = Utf8               org/jvminternals/SimpleClass

  #24 = Utf8               java/lang/Object

  #25 = Utf8               java/lang/System

  #26 = Utf8               out

  #27 = Utf8               Ljava/io/PrintStream;

  #28 = Utf8               java/io/PrintStream

  #29 = Utf8               println

  #30 = Utf8               (Ljava/lang/String;)V

{

  public org.jvminternals.SimpleClass();

    Signature: ()V

    flags: ACC_PUBLIC

    Code:

      stack=1, locals=1, args_size=1

        0: aload_0

        1: invokespecial #1    // Method java/lang/Object."<init>":()V

        4: return

      LineNumberTable:

        line 3: 0

      LocalVariableTable:

        Start  Length  Slot  Name   Signature

          0      5      0    this   Lorg/jvminternals/SimpleClass;

 

  public void sayHello();

    Signature: ()V

    flags: ACC_PUBLIC

    Code:

      stack=2, locals=1, args_size=1

        0: getstatic      #2    // Field java/lang/System.out:Ljava/io/PrintStream;

        3: ldc            #3    // String "Hello"

        5: invokevirtual  #4    // Method java/io/PrintStream.println:(Ljava/lang/String;)V

        8: return

      LineNumberTable:

        line 6: 0

        line 7: 8

      LocalVariableTable:

        Start  Length  Slot  Name   Signature

          0      9      0    this   Lorg/jvminternals/SimpleClass;

}

这个 class 文件展示了三个主要部分:常量池、构造器方法和 sayHello 方法。

  • 常量池:提供了通常由符号表提供的相同信息,详细描述见下文。
  • 方法:每一个方法包含四个区域,
    • 签名和访问标签
    • 字节码
    • LineNumberTable:为调试器提供源码中的每一行对应的字节码信息。上面的例子中,Java 源码里的第 6 行与 sayHello 函数字节码序号 0 相关,第 7 行与字节码序号 8 相关。
    • LocalVariableTable:列出了所有栈帧中的局部变量。上面两个例子中,唯一的局部变量就是 this。

这个 class 文件用到下面这些字节码操作符:

aload0 这个操作码是aload格式操作码中的一个。它们用来把对象引用加载到操作码栈。 表示正在被访问的局部变量数组的位置,但只能是0、1、2、3 中的一个。还有一些其它类似的操作码用来载入非对象引用的数据,如iload, lload, float 和 dload。其中 i 表示 int,l 表示 long,f 表示 float,d 表示 double。局部变量数组位置大于 3 的局部变量可以用 iload, lload, float, dload 和 aload 载入。这些操作码都只需要一个操作数,即数组中的位置
ldc 这个操作码用来将常量从运行时常量池压栈到操作数栈
getstatic 这个操作码用来把一个静态变量从运行时常量池的静态变量列表中压栈到操作数栈
invokespecial, invokevirtual 这些操作码属于一组函数调用的操作码,包括:invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual。在这个 class 文件中,invokespecial 和 invokevirutal 两个指令都用到了,两者的区别是,invokevirutal 指令调用一个对象的实例方法,invokespecial 指令调用实例初始化方法、私有方法、父类方法。
return 这个操作码属于ireturn、lreturn、freturn、dreturn、areturn 和 return 操作码组。每个操作码返回一种类型的返回值,其中 i 表示 int,l 表示 long,f 表示 float,d 表示 double,a 表示 对象引用。没有前缀类型字母的 return 表示返回 void

跟任何典型的字节码一样,操作数与局部变量、操作数栈、运行时常量池的主要交互如下所示。

构造器函数包含两个指令。首先,this 变量被压栈到操作数栈,然后父类的构造器函数被调用,而这个构造器会消费 this,之后 this 被弹出操作数栈。

%title插图%num

 

sayHello() 方法更加复杂,正如之前解释的那样,因为它需要用运行时常量池中的指向符号引用的真实引用。*个操作码 getstatic 从System类中将out静态变量压到操作数栈。下一个操作码 ldc 把字符串 “Hello” 压栈到操作数栈。*后 invokevirtual 操作符会调用 System.out 变量的 println 方法,从操作数栈作弹出”Hello” 变量作为 println 的一个参数,并在当前线程开辟一个新栈帧。

%title插图%num

 

类加载器

JVM 启动时会用 bootstrap 类加载器加载一个初始化类,然后这个类会在public static void main(String[])调用之前完成链接和初始化。执行这个方法会执行加载、链接、初始化需要的额外类和接口。

加载(Loading)是这样一个过程,找到代表这个类的 class 文件或根据特定的名字找到接口类型,然后读取到一个字节数组中。接着,这些字节会被解析检验它们是否代表一个 Class 对象并包含正确的 major、minor 版本信息。直接父类的类和接口也会被加载进来。这些操作一旦完成,类或者接口对象就从二进制表示中创建出来了。

链接(Linking)是校验类或接口并准备类型和父类父接口的过程。链接过程包含三步:校验(verifying)、准备(preparing)、部分解析(optionally resolving)。

校验会确认类或者接口表示是否结构正确,以及是否遵循 Java 语言和 JVM 的语义要求,比如会进行下面的检查:

  1. 格式一致且格式化正确的符号表
  2. final 方法和类没有被重载
  3. 方法遵循访问控制关键词
  4. 方法参数的数量、类型正确
  5. 字节码没有不当的操作栈数据
  6. 变量在读取之前被初始化过
  7. 变量值的类型正确

在验证阶段做这些检查意味着不需要在运行阶段做这些检查。链接阶段的检查减慢了类加载的速度,但是它避免了执行这些字节码时的多次检查。

准备过程包括为静态存储和 JVM 使用的数据结构(比如方法表)分配内存空间。静态变量创建并初始化为默认值,但是初始化代码不在这个阶段执行,因为这是初始化过程的一部分。

解析是可选的阶段。它包括通过加载引用的类和接口来检查这些符号引用是否正确。如果不是发生在这个阶段,符号引用的解析要等到字节码指令使用这个引用的时候才会进行。

类或者接口初始化由类或接口初始化方法<clinit>的执行组成。

%title插图%num

 

JVM 中有多个类加载器,分饰不同的角色。每个类加载器由它的父加载器加载。bootstrap 加载器除外,它是所有*顶层的类加载器。

  • Bootstrap 加载器一般由本地代码实现,因为它在 JVM 加载以后的早期阶段就被初始化了。bootstrap 加载器负责载入基础的 Java API,比如包含 rt.jar。它只加载拥有较高信任级别的启动路径下找到的类,因此跳过了很多普通类需要做的校验工作。
  • Extension 加载器加载了标准 Java 扩展 API 中的类,比如 security 的扩展函数。
  • System 加载器是应用的默认类加载器,比如从 classpath 中加载应用类。
  • 用户自定义类加载器也可以用来加载应用类。使用自定义的类加载器有很多特殊的原因:运行时重新加载类或者把加载的类分隔为不同的组,典型的用法比如 web 服务器 Tomcat。

%title插图%num

 

加速类加载

共享类数据(CDS)是Hotspot JVM 5.0 的时候引入的新特性。在 JVM 安装过程中,安装进程会加载一系列核心 JVM 类(比如 rt.jar)到一个共享的内存映射区域。CDS 减少了加载这些类需要的时间,提高了 JVM 启动的速度,允许这些类被不同的 JVM 实例共享,同时也减少了内存消耗。

方法区在哪里

The Java Virtual Machine Specification Java SE 7 Edition 中写得很清楚:“尽管方法区逻辑上属于堆的一部分,简单的实现可以选择不对它进行回收和压缩。”。Oracle JVM 的 jconsle 显示方法区和 code cache 区被当做为非堆内存,而 OpenJDK 则显示 CodeCache 被当做 VM 中对象堆(ObjectHeap)的一个独立的域。

Classloader 引用

所有的类加载之后都包含一个加载自身的加载器的引用,反过来每个类加载器都包含它们加载的所有类的引用。

运行时常量池

JVM 维护了一个按类型区分的常量池,一个类似于符号表的运行时数据结构。尽管它包含更多数据。Java 字节码需要数据。这个数据经常因为太大不能直接存储在字节码中,取而代之的是存储在常量池中,字节码包含这个常量池的引用。运行时常量池被用来上面介绍过的动态链接。

常量池中可以存储多种类型的数据:

  • 数字型
  • 字符串型
  • 类引用型
  • 域引用型
  • 方法引用

示例代码如下:

1 Object foo = new Object();

写成字节码将是下面这样:

1

2

3

0:     new #2             // Class java/lang/Object

1:    dup

2:    invokespecial #3    // Method java/ lang/Object "&lt;init&gt;"( ) V

new 操作码的后面紧跟着操作数 #2 。这个操作数是常量池的一个索引,表示它指向常量池的第二个实体。第二个实体是一个类的引用,这个实体反过来引用了另一个在常量池中包含 UTF8 编码的字符串类名的实体(// Class java/lang/Object)。然后,这个符号引用被用来寻找 java.lang.Object 类。new 操作码创建一个类实例并初始化变量。新类实例的引用则被添加到操作数栈。dup 操作码创建一个操作数栈顶元素引用的额外拷贝。*后用 invokespecial 来调用第 2 行的实例初始化方法。操作码也包含一个指向常量池的引用。初始化方法把操作数栈出栈的顶部引用当做此方法的一个参数。*后这个新对象只有一个引用,这个对象已经完成了创建及初始化。

如果你编译下面的类:

1

2

3

4

5

6

7

8

package org.jvminternals;

public class SimpleClass {

 

    public void sayHello() {

        System.out.println("Hello");

    }

 

}

生成的类文件常量池将是这个样子:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

Constant pool:

   #1 = Methodref          #6.#17         //  java/lang/Object."&lt;init&gt;":()V

   #2 = Fieldref           #18.#19        //  java/lang/System.out:Ljava/io/PrintStream;

   #3 = String             #20            //  "Hello"

   #4 = Methodref          #21.#22        //  java/io/PrintStream.println:(Ljava/lang/String;)V

   #5 = Class              #23            //  org/jvminternals/SimpleClass

   #6 = Class              #24            //  java/lang/Object

   #7 = Utf8               &lt;init&gt;

   #8 = Utf8               ()V

   #9 = Utf8               Code

  #10 = Utf8               LineNumberTable

  #11 = Utf8               LocalVariableTable

  #12 = Utf8               this

  #13 = Utf8               Lorg/jvminternals/SimpleClass;

  #14 = Utf8               sayHello

  #15 = Utf8               SourceFile

  #16 = Utf8               SimpleClass.java

  #17 = NameAndType        #7:#8          //  "&lt;init&gt;":()V

  #18 = Class              #25            //  java/lang/System

  #19 = NameAndType        #26:#27        //  out:Ljava/io/PrintStream;

  #20 = Utf8               Hello

  #21 = Class              #28            //  java/io/PrintStream

  #22 = NameAndType        #29:#30        //  println:(Ljava/lang/String;)V

  #23 = Utf8               org/jvminternals/SimpleClass

  #24 = Utf8               java/lang/Object

  #25 = Utf8               java/lang/System

  #26 = Utf8               out

  #27 = Utf8               Ljava/io/PrintStream;

  #28 = Utf8               java/io/PrintStream

  #29 = Utf8               println

  #30 = Utf8               (Ljava/lang/String;)V

这个常量池包含了下面的类型:

Integer 4 字节常量
Long 8 字节常量
Float 4 字节常量
Double 8 字节常量
String 字符串常量指向常量池的另外一个包含真正字节 Utf8 编码的实体
Utf8 Utf8 编码的字符序列字节流
Class 一个 Class 常量,指向常量池的另一个 Utf8 实体,这个实体包含了符合 JVM 内部格式的类的全名(动态链接过程需要用到)
NameAndType 冒号(:)分隔的一组值,这些值都指向常量池中的其它实体。*个值(“:”之前的)指向一个 Utf8 字符串实体,它是一个方法名或者字段名。第二个值指向表示类型的 Utf8 实体。对于字段类型,这个值是类的全名,对于方法类型,这个值是每个参数类型类的类全名的列表。
Fieldref, Methodref, InterfaceMethodref 点号(.)分隔的一组值,每个值都指向常量池中的其它的实体。*个值(“.”号之前的)指向类实体,第二个值指向 NameAndType 实体。

异常表

异常表像这样存储每个异常处理信息:

  • 起始点(Start point)
  • 结束点(End point)
  • 异常处理代码的 PC 偏移量
  • 被捕获异常的常量池索引

如果一个方法有定义 try-catch 或者 try-finally 异常处理器,那么就会创建一个异常表。它为每个异常处理器和 finally 代码块存储必要的信息,包括处理器覆盖的代码块区域和处理异常的类型。

当方法抛出异常时,JVM 会寻找匹配的异常处理器。如果没有找到,那么方法会立即结束并弹出当前栈帧,这个异常会被重新抛到调用这个方法的方法中(在新的栈帧中)。如果所有的栈帧都被弹出还没有找到匹配的异常处理器,那么这个线程就会终止。如果这个异常在*后一个非守护进程抛出(比如这个线程是主线程),那么也有会导致 JVM 进程终止。

Finally 异常处理器匹配所有的异常类型,且不管什么异常抛出 finally 代码块都会执行。在这种情况下,当没有异常抛出时,finally 代码块还是会在方法*后执行。这种靠在代码 return 之前跳转到 finally 代码块来实现。

符号表

除了按类型来分的运行时常量池,Hotspot JVM 在永久代还包含一个符号表。这个符号表是一个哈希表,保存了符号指针到符号的映射关系(也就是 Hashtable<Symbol*, Symbol>),它拥有指向所有符号(包括在每个类运行时常量池中的符号)的指针。

引用计数被用来控制一个符号从符号表从移除的过程。比如当一个类被卸载时,它拥有的在常量池中所有符号的引用计数将减少。当符号表中的符号引用计数为 0 时,符号表会认为这个符号不再被引用,将从符号表中卸载。符号表和后面介绍的字符串表都被保存在一个规范化的结构中,以便提高效率并保证每个实例只出现一次。

字符串表

Java 语言规范要求相同的(即包含相同序列的 Unicode 指针序列)字符串字面量必须指向相同的 String 实例。除此之外,在一个字符串实例上调用 String.intern() 方法的返回引用必须与字符串是字面量时的一样。因此,下面的代码返回 true:

1 ("j" "v" "m").intern() == "jvm"

Hotspot JVM 中 interned 字符串保存在字符串表中。字符串表是一个哈希表,保存着对象指针到符号的映射关系(也就是Hashtable<oop, Symbol>),它被保存到永久代中。符号表和字符串表的实体都以规范的格式保存,保证每个实体都只出现一次。

当类加载时,字符串字面量被编译器自动 intern 并加入到符号表。除此之外,String 类的实例可以调用 String.intern() 显式地 intern。当调用 String.intern() 方法时,如果符号表已经包含了这个字符串,那么就会返回符号表里的这个引用,如果不是,那么这个字符串就被加入到字符串表中同时返回这个引用。

异常、堆内存溢出、OOM的几种情况

1堆内存溢出
2Java异常
OOM
1、堆内存溢出
【情况一】:
java.lang.OutOfMemoryError: Java heap space:这种是java堆内存不够,一个原因是真不够,另一个原因是程序中有死循环;
如果是java堆内存不够的话,可以通过调整JVM下面的配置来解决:
< jvm-arg>-Xms3062m < / jvm-arg>
< jvm-arg>-Xmx3062m < / jvm-arg>

【情况二】
java.lang.OutOfMemoryError: GC overhead limit exceeded
【解释】:JDK6新增错误类型,当GC为释放很小空间占用大量时间时抛出;一般是因为堆太小,导致异常的原因,没有足够的内存。
【解决方案】:
1、查看系统是否有使用大内存的代码或死循环;
2、通过添加JVM配置,来限制使用内存:
< jvm-arg>-XX:-UseGCOverheadLimit< /jvm-arg>

【情况三】:
java.lang.OutOfMemoryError: PermGen space:这种是P区内存不够,可通过调整JVM的配置:
< jvm-arg>-XX:MaxPermSize=128m< /jvm-arg>
< jvm-arg>-XXermSize=128m< /jvm-arg>
【注】:
JVM的Perm区主要用于存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space,这个区域成为年老代,GC在主程序运行期间不会对年老区进行清理,默认是64M大小,当程序需要加载的对象比较多时,超过64M就会报这部分内存溢出了,需要加大内存分配,一般128m足够。

【情况四】:
java.lang.OutOfMemoryError: Direct buffer memory
调整-XX:MaxDirectMemorySize= 参数,如添加JVM配置:
< jvm-arg>-XX:MaxDirectMemorySize=128m< /jvm-arg>

【情况五】:
java.lang.OutOfMemoryError: unable to create new native thread
【原因】:Stack空间不足以创建额外的线程,要么是创建的线程过多,要么是Stack空间确实小了。
【解决】:由于JVM没有提供参数设置总的stack空间大小,但可以设置单个线程栈的大小;而系统的用户空间一共是3G,除了Text/Data/BSS /MemoryMapping几个段之外,Heap和Stack空间的总量有限,是此消彼长的。因此遇到这个错误,可以通过两个途径解决:
1.通过 -Xss启动参数减少单个线程栈大小,这样便能开更多线程(当然不能太小,太小会出现StackOverflowError);
2.通过-Xms -Xmx 两参数减少Heap大小,将内存让给Stack(前提是保证Heap空间够用)。

【情况六】:
java.lang.StackOverflowError
【原因】:这也内存溢出错误的一种,即线程栈的溢出,要么是方法调用层次过多(比如存在无限递归调用),要么是线程栈太小。
【解决】:优化程序设计,减少方法调用层次;调整-Xss参数增加线程栈大小。

2、Java异常

Throwable
Throwable是 Java 语言中所有错误或异常的超类。
Throwable包含两个子类: Error 和 Exception 。它们通常用于指示发生了异常情况。
Throwable包含了其线程创建时线程执行堆栈的快照,它提供了printStackTrace()等接口用于获取堆栈跟踪数据等信息。

Exception
Exception及其子类是 Throwable 的一种形式,它指出了合理的应用程序想要捕获的条件。

RuntimeException
RuntimeException是那些可能在 Java 虚拟机正常运行期间抛出的异常的超类。
编译器不会检查RuntimeException异常。 例如,除数为零时,抛出ArithmeticException异常。RuntimeException是ArithmeticException的超类。当代码发生除数为零的情况时,倘若既”没有通过throws声明抛出ArithmeticException异常”,也”没有通过try…catch…处理该异常”,也能通过编译。这就是我们所说的”编译器不会检查RuntimeException异常”!
如果代码会产生RuntimeException异常,则需要通过修改代码进行避免。 例如,若会发生除数为零的情况,则需要通过代码避免该情况的发生!

Error
和Exception一样, Error也是Throwable的子类。 它用于指示合理的应用程序不应该试图捕获的严重问题,大多数这样的错误都是异常条件。
和RuntimeException一样, 编译器也不会检查Error。

Java将可抛出(Throwable)的结构分为三种类型: 被检查的异常(Checked Exception),运行时异常(RuntimeException)和错误(Error)。

(01) 运行时异常
定义 : RuntimeException及其子类都被称为运行时异常。
特点 : Java编译器不会检查它。 也就是说,当程序中可能出现这类异常时,倘若既”没有通过throws声明抛出它”,也”没有用try-catch语句捕获它”,还是会编译通过。例如,除数为零时产生的ArithmeticException异常,数组越界时产生的IndexOutOfBoundsException异常,fail-fail机制产生的ConcurrentModificationException异常等,都属于运行时异常。
虽然Java编译器不会检查运行时异常,但是我们也可以通过throws进行声明抛出,也可以通过try-catch对它进行捕获处理。
如果产生运行时异常,则需要通过修改代码来进行避免。 例如,若会发生除数为零的情况,则需要通过代码避免该情况的发生!

(02) 被检查的异常
定义 : Exception类本身,以及Exception的子类中除了”运行时异常”之外的其它子类都属于被检查异常。
特点 : Java编译器会检查它。 此类异常,要么通过throws进行声明抛出,要么通过try-catch进行捕获处理,否则不能通过编译。例如,CloneNotSupportedException就属于被检查异常。当通过clone()接口去克隆一个对象,而该对象对应的类没有实现Cloneable接口,就会抛出CloneNotSupportedException异常。
被检查异常通常都是可以恢复的。

(03) 错误
定义 : Error类及其子类。
特点 : 和运行时异常一样,编译器也不会对错误进行检查。
当资源不足、约束失败、或是其它程序无法继续运行的条件发生时,就产生错误。程序本身无法修复这些错误的。例如,VirtualMachineError就属于错误。
按照Java惯例,我们是不应该是实现任何新的Error子类的!

对于上面的3种结构,我们在抛出异常或错误时,到底该哪一种?《Effective Java》中给出的建议是: 对于可以恢复的条件使用被检查异常,对于程序错误使用运行时异常。

OOM
1, OutOfMemoryError异常

除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(OOM)异常的可能,

Java Heap 溢出

一般的异常信息:java.lang.OutOfMemoryError:Java heap spacess

java堆用于存储对象实例,我们只要不断的创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,就会在对象数量达到*大堆容量限制后产生内存溢出异常。

出现这种异常,一般手段是先通过内存映像分析工具(如Eclipse Memory Analyzer)对dump出来的堆转存快照进行分析,重点是确认内存中的对象是否是必要的,先分清是因为内存泄漏(Memory Leak)还是内存溢出(Memory Overflow)。

如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链。于是就能找到泄漏对象时通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收。

如果不存在泄漏,那就应该检查虚拟机的参数(-Xmx与-Xms)的设置是否适当。

2, 虚拟机栈和本地方法栈溢出

如果线程请求的栈深度大于虚拟机所允许的*大深度,将抛出StackOverflowError异常。

如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常

这里需要注意当栈的大小越大可分配的线程数就越少。

3, 运行时常量池溢出

异常信息:java.lang.OutOfMemoryError:PermGen space

如果要向运行时常量池中添加内容,*简单的做法就是使用String.intern()这个Native方法。该方法的作用是:如果池中已经包含一个等于此String的字符串,则返回代表池中这个字符串的String对象;否则,将此String对象包含的字符串添加到常量池中,并且返回此String对象的引用。由于常量池分配在方法区内,我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小,从而间接限制其中常量池的容量。

4, 方法区溢出

方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述等。

异常信息:java.lang.OutOfMemoryError:PermGen space

方法区溢出也是一种常见的内存溢出异常,一个类如果要被垃圾收集器回收,判定条件是很苛刻的。在经常动态生成大量Class的应用中,要特别注意这点。

 

几种可能导致OOM异常的情况

本文将讲述两种可能导致OOM的案例
注意:1、程序计数器不会发生OOM
2、在jdk1.8中已经取消了永久代概念,改由元空间取代,就算设置-XX:MetaspaceSize=1m;这种参数限制大小,实际操作时并没有起到多大用处,因此很难通过简单的demo复现以前老年代产生OOM的异常。

由于递归深度过长导致
jvm对递归深度有限制,具体深度由于jdk 版本等的不同有差异,下面这个案例使用jdk1.8测试,递归深度测试为7893,附测试案例:

static int stackDeep = 0;
public static void main(String[] args) {
try{
TestStackOverFlow testStakOverFlow = new TestStackOverFlow();
testStakOverFlow.foo();
}catch(Throwable t){
System.out.println(t);
System.out.println(“栈的深度为:” + stackDeep);
}
}

public void foo() {
stackDeep ++ ;
foo();
}

测试结果:

java.lang.StackOverflowError
栈的深度为:7893

堆溢出
运行时堆溢出是一种常见的溢出情况,下面展示其中的一种,有感兴趣的朋友可以使用Set来代替List重写该案例,异常堆栈信息将不同:
设置JVM参数:

-Xmx1m -XX:+PrintGCDetails

测试代码:

int i = 0;
while(true){
test.add(String.valueOf(i++).intern());
}

异常日志打印如下:

[Full GC (Allocation Failure) [Tenured: 1407K->1408K(1408K), 0.0080421 secs] 1855K->1820K(1984K), [Metaspace: 82K->82K(4480K)], 0.0080726 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
Exception in thread “main” java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)…

可以看到,*后一次GC,是full GC,异常报错在扩容的地方,由于空间不够,扩容时申请不到空间,引发OOM。

小结:OOM发生的情况很多,很多时候需要结合实际产生的问题来具体分析,比如:机器实际内存2g,设置堆大小:-Xmx与-Xms为1.8g,而使用NIO的情况很多,那么可能由于直接内存不够导致异常;另外大对象的使用不当也可能导致OOM;再比如,大量数据直接使用内存作为缓存,也可能导致OOM…很多时候,可以根据JVM参数(比如设置堆栈等的大小,GC收集器等)或者增加机器配置来进行调优。实际上,很多OOM,都是程序不当引起的,因此出现该情况,应首先考虑程序问题。

Android 内存优化简介

1、内存占用高导致的问题

  • 1、内存泄漏导致OOM崩溃
  • 2、界面卡顿,影响用户体验
  • 3、高内存耗电,被系统及安全软件警告,容易被卸载或后台关闭

之所以要内存优化为了更好的适应JVM的GC机制,减少对程序的影响(减少卡顿)。

2、JVM 内存模型

Minor GC 使用标记-清除-复制算法,将Eden区和From Survivor区中存活下来的对象复制到 To Survivor区中,然后清空Eden区和From Survivor区,速度快。

Major GC 采用标记-清除-压缩算法,即,先标记无用的对象,然后将存活下来的对象移动,整理碎片,以腾出更大的连续空间。

如下图所示:

%title插图%num
JVM.png

3、GC原理及简介

采用是否根节点可访问判断是否需要回收对象,如下图所示

%title插图%num
GC.png
3.1标记清除复制算法
%title插图%num
mark-copy.png
3.2标记清除复制算法
%title插图%num
mark-press.png

4、GC Reason和Name

<pre class=”hljs undefined” data-original-code=”” reason”=”” data-snippet-id=”ext.fad1dd2cb080f9ce19557e96ccdfb127″ data-snippet-saved=”false” data-codota-status=”done”>

  1. Reason
  2. Concurrent—-后台回收内存,不暂停用户线程
  3. Alloc—-当app要申请内存,而堆又快满了的时候,会阻塞用户线程
  4. Explicit—-调用Systemt.gc()等方法的时候触发,一般不建议使用
  5. NativeAlloc—-当native内存有压力的时候触发
  6. Name
  7. Concurrent mark sweep—-全部对象的检测回收
  8. Concurrent partial mark sweep—-部分的检测回收
  9. Concurrent sticky mark sweep—-仅检测上次回收后创
  10. 建的对象,速度快,卡顿少,比较频繁

GC log 示例

04-06 09:41:48.541 5021-5045/com.husor.beibei I/art: Background partial concurrent mark sweep GC freed 22647(1359KB) AllocSpace objects, 5(969KB) LOS objects, 6% free, 53MB/57MB, paused 5.128ms total 68.744ms

5、如何进行内存优化

  • 1、消除内存泄漏
  • 2、使用高性能编程
  • 3、降低程序运行的内存占用

6、常见内存泄漏和高内存占用原因

  • 1、慎重使用static变量
  • 2、长周期内部类、匿名内部类长时间持有外部类引用导致相关资源无法释放(Handler或者内部线程等)
  • 3、BitMap导致内存溢出
  • 4、数据库、文件流等没有关闭
  • 5、监听器、广播注册后没有及时注销
  • 6、Adapter没有使用convertView
  • 7、字符串拼接尽量使用StringBuilder或者StringBuffer
  • 8、避免内存抖动,例如不要在onDraw中创建对象。
  • 9、界面不可见时,停止动画和相关线程
6.1、示例一:
%title插图%num
sample1.png

原因:
sBackground, 是一个静态的变量,但是我们发现,我们并没有显式的保存Contex的引用,但是,当Drawable与View连接之后,Drawable就将View设置为一个回调,由于View中是包含Context的引用的,所以,实际上我们依然保存了Context的引用。这个引用链如下:Drawable->TextView->Context

解决办法:

  1. *,应该尽量避免static成员变量引用资源耗费过多的实例,比如Context。
  2. 第二、Context尽量使用Application Context,因为Application的Context的生命周期比较长
  3. 第三、使用WeakReference代替强引用。比如WeakReference<Context> mContextRef; (已经不推荐)
6.1、示例二:
%title插图%num
sample2.png

原因:

Activity退出后,其实例并未被回收。因为OneThread作为非静态内部类还持有BasicActivity的实例。

解决方案:

  1. 1、OneThread改为静态内部类
  2. 2、如果OneThread需要Context实例,使用弱引用保存它。
  3. 3、如果有必要,在BasicActivity的OnDestroy里面关闭线程

7、内存分析工具

7、1 Android Monitor
%title插图%num
util1.png

** 优点:**
使用简单,直观显示当前app的内存变化
缺点:
无法具体定位内存问题,只能给出内存笼统的变化。
常用于分析内存变化趋势。

7、2 Allocation Tracker
%title插图%num
util2.png
  1. 1、选择进程,在合适的实际开始和结束追踪。
  2. 2、Studio会自动打开文件,里面展示这一段时间内内存的分配情况,可以分析自己的程序哪里内存占用比较高,是否有大量的相同类型的 Object 被分配和释放。如果有,则其可能引起性能问题。
7、3 MAT

步骤:

  • 1生成mat文件

在android studio 生成dump文件,并转为标准dump。
如下图所示

%title插图%num
mat1.png
%title插图%num
mat2.png
  • 2使用mat分析
  • 以内部线程导致内存泄漏为例分析:
    1、多次打开该demo,生成dump文件
    2、打开MAT工具,选择“File”>>“open heap dump”,打开dump文件
    3、打开后在,“Action”里的“Histogram”,然后搜索SecondActivity
%title插图%num
mat3.png
  • 3猜测分析原因

    通过上面看到,存在11个SecondActivity的实例,有点诡异。
    选择SecondActivity这一项,然后右键“Merge Shortest Paths to GC Roots ”>>”exclude all phantom/weak/soft etc references..”

%title插图%num
mat4.png
%title插图%num
mat5.png
7、4LeakCanary 检测内存泄漏
leakcanary.png

直接可以通过通知栏看到内存泄露的地方

Android Studio运行Java代码在jvm中, 该怎么办?

Android Studio的app工程编译生成的apk运行在手机或者模拟器。  有时为了调试一些工具类, 我们想运行Java代码在jvm中, 那该怎么办呢?

目前有2种方法 :
1、在Java文件中添加main方法,  鼠标点击到main方法里任意地方,  使得光标停在main函数里。 然后点击鼠标右键, 选择Run ‘MainActivity main()’或者Debug ‘MainActivity main’就行了。 too easy!!!

%title插图%num

2、新建个Java  Library, 并设置运行方式。

%title插图%num %title插图%num %title插图%num

点击Edit Configuration

%title插图%num

选择Application后, 设置Name、Main class、Use class of Module并点击OK。

%title插图%num %title插图%num

选择运行方式为Java, 然后点击绿色运行按钮就行了。