java JVM内存管理物理内存与虚拟内存 内核空间与用户空间 在 Java 中哪些组件需要使用内存 JVM 内存结构 JVM 内存分配策略 JVM 内存回收策略 内存问题分析 实例 1 实例 2 实例 3 总结 

物理内存与虚拟内存 

    所谓物理内存就是我们通常所说的 RAM(随机存储器)。在计算机中,还有一个存储单元叫寄存器,它用于存储计算单元执行指令(如浮点、整数等运算时)的中间结果。寄存器的大小决定了一次计算可使用的最大数值。

    连接处理器和 RAM或者处理器和寄存器的是地址总线,这个地址总线的宽度影响了物理地址的索引范围,因为总线的宽度决定了处理器一次可以从寄存器或者内存中获取多少个bit。同时也决定了处理器最大可以寻址的地址空间,如32 位地址总线可以寻址的范围为 0x0000 0000~0xffff ffff。这个范围是232=4 294 967 296 个内存位置,每个地址会引用一个字节,所以32 位总线宽度可以有 4GB的内存空间。

    通常情况下,地址总线和寄存器或者RAM 有相同的位数,因为这样更容易传输数据,但是也有不一致的情况,如x86 的 32位寄存器宽度的物理地址可能有两种大小,分别是32位物理地址和 36位物理地址,拥有 36 位物理地址的是Pentium Pro和更高型号。

    除了在学校的编译原理的实践课或者要开发硬件程序的驱动程序时需要直接通过程序访问存储器外,我们大部分情况下都调用操作系统提供的接口来访问内存,在Java 中甚至不需要写和内存相关的代码。

    不管是在 Windows系统还是 Linux系统下,我们要运行程序,都要向操作系统先申请内存地址。通常操作系统管理内存的申请空间是按照进程来管理的,每个进程拥有一段独立的地址空间,每个进程之间不会相互重合,操作系统也会保证每个进程只能访问自己的内存空间。这主要是从程序的安全性来考虑的,也便于操作系统来管理物理内存。

    其实上面所说的进程的内存空间的独立主要是指逻辑上独立,也就是这个独立是由操作系统来保证的,但是真正的物理空间是不是只能由一个进程来使用就不一定了。因为随着程序越来越庞大和设计的多任务性,物理内存无法满足程序的需求,在这种情况下就有了虚拟内存的出现。

    虚拟内存的出现使得多个进程在同时运行时可以共享物理内存,这里的共享只是空间上共享,在逻辑上它们仍然是不能相互访问的。虚拟地址不但可以让进程共享物理内存、提高内存利用率,而且还能够扩展内存的地址空间,如一个虚拟地址可能被映射到一段物理内存、文件或者其他可以寻址的存储上。一个进程在不活动的情况下,操作系统将这个物理内存中的数据移到一个磁盘文件中(也就是通常Windows 系统上的页面文件,或者Linux系统上的交换分区),而真正高效的物理内存留给正在活动的程序使用。在这种情况下,在我们重新唤醒一个很长时间没有使用的程序时,磁盘会吱吱作响,并且会有一个短暂的停顿得到印证,这时操作系统又会把磁盘上的数据重新交互到物理内存中。但是我们必须要避免这种情况的经常出现,如果操作系统频繁地交互物理内存的数据和磁盘数据,则效率将会非常低,尤其是在Linux 服务器上,我们要关注Linux 中swap 的分区的活跃度。如果swap 分区被频繁使用,系统将会非常缓慢,很可能意味着物理内存已经严重不足或者某些程序没有及时释放内存。 

内核空间与用户空间 

线程 

        JVM运行实际程序的实体是线程,当然线程需要内存空间来存储一些必要的数据。每个线程创建时JVM 都会为它创建一个堆栈,堆栈的大小根据不同的 JVM 实现而不同,通常在256KB~756KB之间。

    线程所占空间相比堆空间来说比较小。但是如果线程过多,线程堆栈的总内存使用量可能也非常大。当前有很多应用程序根据CPU 的核数来分配创建的线程数, 如果运行的应用程序的线程数量比可用于处理它们的处理器数量多,效率通常很低,并且可能导致比较差的性能和更高的内存占用率。 

JNI 

        JNI技术使得本机代码(如 C 语言程序)可以调用Java 方法,也就是通常所说的 nativememory。实际上Java 运行时本身也依赖于 JNI代码来实现类库功能,如文件操作、网络I/O操作或者其他系统调用。所以 JNI 也会增加Java 运行时的本机内存占用。 

JVM 内存结构 

    前面介绍了内存的不同形态:物理内存和虚拟内存。介绍了内存的使用形式:内核空间和用户空间。接着又介绍了Java 有哪些组件需要使用内存。下面着重介绍在 JVM 中是如何使用内存的。

        JVM是按照运行时数据的存储结构来划分内存结构的,JVM在运行 Java程序时,将它们划分成几种不同格式的数据,分别存储在不同的区域,这些数据统一称为运行时数据(Runtime Data)。运行时数据包括Java 程序本身的数据信息和 JVM运行 Java程序需要的

    额外数据信息,如要记录当前程序指令执行的指针(又称为PC 指针)等。在 Java虚拟机规范中将 Java运行时数据划分为 6 种,分别为:

PC 寄存器 

        PC寄存器严格来说是一个数据结构,它用于保存当前正常执行的程序的内存地址。同时Java 程序是多线程执行的,所以不可能一直都按照线性执行下去,当有多个线程交叉执行时,被中断线程的程序当前执行到哪条的内存地址必然要保存下来,以便于它被恢复执行时再按照被中断时的指令地址继续执行下去。这很好理解,它就像一个记事员一样记录下哪个线程当前执行到哪条指令了。

    但是 JVM规范只定义了 Java方法需要记录指针信息,而对于 Native 方法,并没有要求记录执行的指针地址。 

方法区 

        JVM方法区是用于存储类结构信息的地方,如在第7 章介绍的将一个 class文件解析成 JVM能识别的几个部分,这些不同的部分在这个class被加载到 JVM时,会被存储在不同的数据结构中,其中的常量池、域、方法数据、方法体、构造函数,包括类中的专用方法、实例初始化、接口初始化都存储在这个区域。

方法区这个存储区域也属于后面介绍的 Java 堆中的一部分,也就是我们通常所说的Java堆中的永久区。这个区域可以被所有的线程共享,并且它的大小可以通过参数来设置。

    这个方法区存储区域的大小一般在程序启动后的一段时间内就是固定的了,JVM运行一段时间后,需要加载的类通常都已经加载到JVM 中了。但是有一种情况是需要注意的,那就是在项目中如果存在对类的动态编译,而且是同样一个类的多次编译,那么需要观察方法区的大小是否能满足类存储。

    方法区这个区域有点特殊,由于它不像其他Java 堆一样会频繁地被 GC回收器回收,它存储的信息相对比较稳定,但是它仍然占用了Java 堆的空间,所以仍然会被 JVM的 GC回收器来管理。在一些特殊的场合下,有时通常需要缓存一块内容,这个内容也很少变动,但是如果把它置于Java 堆中它会不停地被 GC回收器扫描,直到经过很长的时间后会进入Old区。在这种情况下,通常是能控制这个缓存区域中数据的生命周期的,我们不希望它被JVM 内存管理,但是又希望它在内存中。面对这种情况,淘宝正在开发一种技术用于在JVM 中分配另外一个内存存储区域,它不需要GC 回收器来回收,但是可以和其他内存中对象一样来使用。 

运行时常量池 

    在 JVM规范中是这样定义运行时常量池这个数据结构的:Runtime Constant Pool代表运行时每个 class文件中的常量表。它包括几种常量:编译期的数字常量、方法或者域的引用(在运行时解析)。Runtime Constant Pool的功能类似于传统编程语言的符号表,尽管它包含的数据比典型的符号表要丰富得多。每个Runtime Constant pool都是在 JVM的 Method area中分配的,每个Class 或者Interface 的 Constant Pool都是在 JVM创建 class或接口时创建的。

    上面的描述可能使你有点迷惑,这个常量池与前面方法区的常量池是否是一回事?答案是肯定的。它是方法区的一部分,所以它的存储也受方法区的规范约束,如果常量池无法分配,同样会抛出OutOfMemoryError。 

本地方法栈 

    本地方法栈是为 JVM运行 Native方法准备的空间,它和前面介绍的 Java 栈的作用是类似的,由于很多 Native方法都是用 C语言实现的,所以它通常又叫 C 栈,除了在我们的代码中包含的常规的Native方法会使用这个存储空间,在 JVM 利用JIT 技术时会将一些 Java方法重新编译为 Native Code代码,这些编译后的本地代码通常也是利用这个栈来跟踪方法的执行状态的。

    在 JVM规范中没有对这个区域的严格限制,它可以由不同的JVM 实现者自由实现,但是它和其他存储区一样也会抛出OutOfMemoryError和 StackOverflowError。 

JVM 内存分配策略 

    在分析 JVM内存分配策略之前我们先介绍一下通常情况下操作系统都是采用哪些策略来分配内存的。 

通常的内存分配策略 

    我想大家都学过操作系统,在操作系统中将内存分配策略分为三种,分别是:

    静态内存分配是指在程序编译时就能确定每个数据在运行时的存储空间需求,因此在编译时就可以给它们分配固定的内存空间。这种分配策略不允许在程序代码中有可变数据结构(如可变数组)的存在,也不允许有嵌套或者递归的结构出现,因为它们都会导致编译程序无法计算准确的存储空间需求。

    栈式内存分配也可称为动态存储分配,是由一个类似于堆栈的运行栈来实现的。和静态内存分配相反,在栈式内存方案中,程序对数据区的需求在编译时是完全未知的,只有到运行时才能知道,但是规定在运行中进入一个程序模块时,必须知道该程序模块所需的数据区大小才能够为其分配内存。和我们所熟知的数据结构中的栈一样,栈式内存分配按照先进后出的原则进行分配。

    在编写程序时除了在编译时能确定数据的存储空间和在程序入口处能知道存储空间外,还有一种情况就是当程序真正运行到相应代码时才会知道空间大小,在这种情况下我们就需要堆这种分配策略。

    这几种内存分配策略中,很明显堆分配策略是最自由的,但是这种分配策略对操作系统和内存管理程序来说是一种挑战。另外,这个动态的内存分配是在程序运行时才执行的,它的运行效率也是比较差的。 

Java 中的内存分配详解

    从前面的 JVM内存结构的分析我们可知,JVM内存分配主要基于两种,分别是堆和栈。先来说说Java 栈是如何分配的。

        Java栈的分配是和线程绑定在一起的,当我们创建一个线程时,很显然,JVM就会为这个线程创建一个新的Java 栈,一个线程的方法的调用和返回对应于这个Java 栈的压栈和出栈。当线程激活一个Java 方法时,JVM就会在线程的 Java堆栈里新压入一个帧,这个帧自然成了当前帧。在此方法执行期间,这个帧将用来保存参数、局部变量、中间计算过程和其他数据。

    这段代码的 stack方法中定义了多个变量,这些变量在运行时需要存储空间,同时在执行指令时JVM 也需要知道操作栈的大小,这些数据都会在 Javac 编译这段代码时就已经确定,下面是这个方法对应的class字节码: 

    public void stack(java.lang.String[]);
      Code:
		Stack=2, Locals=6, Args_size=2 0: ldc #3; //String junshan
		2: astore_2
		3: aload_2
		4: ldc #3; //String junshan
		6: invokevirtual #4; //Method java/lang/String.equals:(Ljava/lang/ Object;)Z
		9: ifeq 30
		12: iconst_3
		13: istore_3
		14: iload_3
		15: ifle 27
		18: lconst_1
		19: lstore 4
		21: iinc 3,-1 24: goto 14 27: goto 40 30: bipush 97 32: istore_3
		33: getstatic
		36: iload_3
		37: invokevirtual
		40: return
		#5; //Field java/lang/System.out:Ljava/io/PrintStream; #6; //Method java/io/PrintStream.println:(C)V
		LineNumberTable:
		 line 15: 0
		 line 16: 3
		 line 17: 12
		 line 18: 14
		 line 19: 18
		 line 20: 21
		 line 21: 24
		 line 22: 27
		 line 23: 30
		 line 24: 33
		 line 26: 40
		LocalVariableTable:
		Start Length Slot Name Signature
		21 3 4 j J
		14 13 3 i I
		33 7 3 b C
		0 41 0 this Lheap/StackSize; 0 41 1 arg [Ljava/lang/String; 3 38 2 str Ljava/lang/String;

    在这个方法的 attribute中就已经知道了 stack和 local variable的大小,分别是 2和 6。还有一点不得不提,就是这里的大小指定的是最大值,为什么是最大值呢?因为JVM 在真正执行时分配的stack 和local variable的空间是可以共用的。举例来说,上面的 6 个localvariable 除去变量 0是 this指针外,其他 5个都是在这个方法中定义的,这 6个变量需要的 Slot是 1+1+1+1+2+1=7,但是实际上使用的Slot 只有4 个,这是因为不同的变量作用范围如果没有重合,Slot则可以重复使用。

public static void main(String[] args) {
    String str = new String("hello world!") ;
}

    public static void main(java.lang.String[]);
      Code:
		Stack=3, Locals=2, Args_size=1
		0: new #7; //class java/lang/String
		3: dup
		4: ldc #8; //String hello world!
		6: invokespecial #9; //Method java/lang/String."<init>":(Ljava/lang/
		String;)V
		9: astore_1
		10: return
	  LineNumberTable:
		  line 29: 0
		  line 35: 10
	  LocalVariableTable:
		 Start Length Slot Name Signature
		 0 11 0 args [Ljava/lang/String; 10 1 1 str Ljava/lang/String;

public void staticData(int arg){
	String s="String";
	long l=1;
	Long lg=1L;
	Object o = new Object();
	Integer i = 0;
}

动态内存分配和回收 

    在前面的例子中变量 lg 和i 存储与值虽然与 l和 arg变量一样,但是它们存储的位置是不一样的,后者是原生数据类型,它们存储在Java 栈中,方法执行结束就会消失,而前者是对象类型,它们存储在Java 堆中,它们是可以被共享的,也不一定随着方法执行结束而消失。变量l 和 lg的内存空间大小显然也是不一样的,l在 Java栈中被分配 8个字节空间,而 lg被分配 4个字节的地址指针空间,这个地址指针指向这个对象在堆中的地址。很显然在堆中long 类型数字 1肯定不只 8个字节,所以 Long代表的数字肯定比 long类型占用的空间要大很多。

    在 Java中对象的内存空间是动态分配的,所谓的动态分配就是在程序执行时才知道要分配的存储空间大小,而不是在编译时就能够确定的。lg代表的 Long对象,只有 JVM在解析Long 类时才知道在这个类中有哪些信息,这些信息都是哪些类型,然后再为这些信息分配相应的存储空间存储相应的值。而这个对象什么时候被回收也是不确定的,只有等到这个对象不再使用时才会被回收。

    从前面的分析可知内存的分配是在对象创建时发生的,而内存的回收是以对象不再引用为前提的。这种动态内存的分配和回收是和Java 中一些数据类型关联的,Java程序员根本不需要关注内存的分配和回收,只需关注这些数据类型的使用就行了。

    那么如何确定这个对象什么时候不被使用,又如何来回收它们,这正是JVM 的一个很重要的组件——垃圾收集器要解决的问题。 

如何检测垃圾 

    垃圾收集器必须能够完成两件事情:一件是能够正确地检测出垃圾对象,另一件是能够释放垃圾对象占用的内存空间。其中如何检测出垃圾是垃圾收集器的关键所在。 

    从前面的分析已经知道,只要是某个对象不再被其他活动对象引用,那么这个对象就可以被回收了。这里的活动对象指的是能够被一个根对象集合到达的对象,如图8-1 所示。

    在图 8-1中除了 f和 h对象之外,其他都可以称为活动对象,因为它们都可以被根对象集合到达。h对象虽然也被 f对象引用,但是 h对象不能够被根对象集合达到,所以它们都是非活动对象,可以被垃圾收集器回收。 

基于分代的垃圾收集算法 

    经过这么长时间的发展,垃圾收集算法已经有很多种,算法各有优缺点,这里将主要介绍在hotspot 中使用的基于分代的垃圾收集方式。

    该算法的设计思路是:把对象按照寿命长短来分组,分为年轻代和年老代,新创建的对象被分在年轻代,如果对象经过几次回收后仍然存活,那么再把这个对象划分到年老代。年老代的收集频度不像年轻代那么频繁,这样就减少了每次垃圾收集时所要扫描的对象的数量,从而提高了垃圾回收效率。

    这种设计的思路是把堆划分成若干个子堆,每个子堆对应一个年龄代,如图8-2 所示。