文章目錄
  1. 1. 一、Java内存结构
    1. 1.1. 1.1 运行时数据区域
      1. 1.1.1. 1.1.1 程序计数器(Program Counter Register)
      2. 1.1.2. 1.1.2 Java虚拟机栈(Java Virtual Machine Stacks)
        1. 1.1.2.1. 1.1.2.1 虚拟机栈
        2. 1.1.2.2. 1.1.2.2 栈帧初略(局部变量表与操作数栈)
      3. 1.1.3. 1.1.3 本地方法栈(Native Method Stacks)
      4. 1.1.4. 1.1.3 Java堆(Java Heap)
        1. 1.1.4.1. 1.1.3.1 对象在堆中的内存结构
        2. 1.1.4.2. 1.1.3.2 数组在堆中的内存结构
      5. 1.1.5. 1.1.4 方法区(Method Area)
        1. 1.1.5.1. 1.1.4.1 运行时常量池(Runtime Constant Pool)
      6. 1.1.6. 1.1.5 直接内存(Direct Memory)
    2. 1.2. 1.2 Java对象
      1. 1.2.1. 1.2.1 对象的创建
      2. 1.2.2. 1.2.2 对象的内存布局
      3. 1.2.3. 1.2.3 对象访问定位
      4. 1.2.4. 1.2.4 Java对象生成方式
  2. 2. 二、内存溢出
    1. 2.1. 2.1 内存溢出与内存泄露
    2. 2.2. 2.2 Java中常见的内存溢出异常
      1. 2.2.1. 2.2.1 Java堆溢出
      2. 2.2.2. 2.2.2 虚拟机栈溢出与本地方法栈溢出
      3. 2.2.3. 2.2.3 方法区和运行时常量池溢出
  3. 3. 三、初略GC预览

摘要:
Java程序员把内存控制的权利交给了Java 虚拟机,一旦出现内存泄漏和溢出方面的问题,如果不了解虚拟是怎样使用内存的,那么排查错误将会成为一项异常艰难的工作。摘自:《深入理解Java虚拟机》

一、Java内存结构

1.1 运行时数据区域

Java虚拟机管理的内存如下图所示:
Alt text

1.1.1 程序计数器(Program Counter Register)

关键语句:

  • 线程私有
  • 较小的内存空间
  • 字节码的行号指示器
  • 每个线程都有一个独立的程序计数器
  • 唯一在Java 虚拟机规范中没有规定任何OutOfMemoryError区域。

 程序计数器是一块较小的内存空间,它的作用可以看做是当前线程所执行的字节码的行号指示器。
 字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
 由于Java 虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器(对于多核处理器来说是一个内核)只会执行一条线程中的指令。
 因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各条线程之间的计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存。

  • 执行Java方法时:计数器记录是虚拟机字节码指令地址
  • 执行Native方法时:计数器值为空(Undefined

1.1.2 Java虚拟机栈(Java Virtual Machine Stacks)

关键语句

  • 线程私有
  • 栈帧
  • 局部变量表-各种基本数据类型


1.1.2.1 虚拟机栈

 Java 虚拟机栈(Java Virtual Machine Stacks)是线程私有的,生命周期与线程相同。虚拟机只会直接对Java栈执行两种操作:以帧为单位的压栈和出栈。
虚拟机栈描述的是Java 方法执行的内存模型:

  • 每个方法被执行的时候都会同时创建一个栈帧(Stack Frame)用于存储局部变量表、操作栈、动态链接、方法出口等信息。
  • 每一个方法被调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
  • 当线程调用一个Java方法时,虚拟机压入一个新的栈帧到该线程的Java栈中,当该方法返回时,这个栈帧被从Java栈中弹出并抛弃。

 下图描绘了Java虚拟机为每一个线程创建的内存区,这些内存区域是私有的,任何线程都不能访问另一个线程的程序寄存器(PC Register)或者Java栈。
Alt text

在Java 虚拟机规范中,对这个区域规定了两种异常状况:

  • 如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError 异常;
  • 如果虚拟机栈可以动态扩展(当前大部分的Java 虚拟机都可动态扩展,只不过Java 虚拟机规范中也允许固定长度的虚拟机栈),当扩展时无法申请到足够的内存时会抛出OutOfMemoryError 异常。

1.1.2.2 栈帧初略(局部变量表与操作数栈)

栈帧由三部分组成:局部变量表,操作数栈和帧数据区。下图为栈帧结构图(摘自《深入理解Java虚拟机第2版》第8章):
Alt text

局部变量表:

  • 局部变量表和操作数栈要视对应的方法而定,它们是按照字长计算的。
  • 局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference 类型,它不等同于对象本身,根据不同的虚拟机实现,它可能是一个指向对象起始地址的引用指针,也可能指向一个代表对象的句柄或者其他与此对象相关的位置)和returnAddress 类型(指向了一条字节码指令的地址)。其中64 位长度的long 和double 类型的数据会占用2 个局部变量空间(Slot),其余的数据类型只占用1 个。
  • 局部变量表所需的内存空间在编译期间完成分配,当进入一个方法时,这个方法需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。

操作数栈:

  • 操作数栈也常被称为操作栈,它是一个后入先出栈。同局部变量表一样,操作数栈的最大深度也是编译的时候被写入到方法表的Code属性的max_stacks数据项中。操作数栈的每一个元素可以是任意Java数据类型,包括long和double。32位数据类型所占的栈容量为1,64位数据类型所占的栈容量为2。栈容量的单位为“字宽”,对于32位虚拟机来说,一个”字宽“占4个字节,对于64位虚拟机来说,一个”字宽“占8个字节。
  • 当一个方法刚刚执行的时候,这个方法的操作数栈是空的,在方法执行的过程中,会有各种字节码指向操作数栈中写入和提取值,也就是入栈与出栈操作。例如,在做算术运算的时候就是通过操作数栈来进行的,又或者调用其它方法的时候是通过操作数栈来行参数传递的。
  • 另外,在概念模型中,两个栈帧作为虚拟机栈的元素,相互之间是完全独立的,但是大多数虚拟机的实现里都会作一些优化处理,令两个栈帧出现一部分重叠。

1.1.3 本地方法栈(Native Method Stacks)

关键语句:

  • Native 方法

 本地方法栈(Native Method Stacks)与虚拟机栈所发挥的作用是非常相似的,其区别不过是虚拟机栈为虚拟机执行Java 方法(也就是字节码)服务,而本地方法栈则是为虚拟机使用到的Native 方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。
 甚至有的虚拟机(譬如Sun HotSpot 虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowErrorOutOfMemoryError异常。
 下图描绘了这样一个情景,就是当一个线程调用一个本地方法时,本地方法又回调虚拟机中的另一个Java方法。这幅图展示了JAVA虚拟机内部线程运行的全景图。一个线程可能在整个生命周期中都执行Java方法,操作它的Java栈;或者它可能毫无障碍地在Java栈和本地方法栈之间跳转。
Alt text
 该线程首先调用了两个Java方法,而第二个Java方法又调用了一个本地方法,这样导致虚拟机使用了一个本地方法栈。假设这是一个C语言栈,其间有两个C函数,第一个C函数被第二个Java方法当做本地方法调用,而这个C函数又调用了第二个C函数。之后第二个C函数又通过本地方法接口回调了一个Java方法(第三个Java方法),最终这个Java方法又调用了一个Java方法(它成为图中的当前方法)。 

1.1.3 Java堆(Java Heap)

关键语句

  • 所有线程都将共享
  • 虚拟机管理堆内存
  • 多个线程私有的分配缓冲区TLAB

 Java程序在运行时创建的所有类实例或数组都放在同一个堆中。而一个JAVA虚拟机实例中只存在一个堆空间,因此所有线程都将共享这个堆。又由于一个Java程序独占一个JAVA虚拟机实例,因而每个Java程序都有它自己的堆空间——它们不会彼此干扰。但是同一个Java程序的多个线程却共享着同一个堆空间,在这种情况下,就得考虑多线程访问对象(堆数据)的同步问题了。
 Java虚拟机有一条在堆中分配新对象的指令,却没有释放内存的指令,正如你无法用Java代码区明确释放一个对象一样。虚拟机自己负责决定如何以及何时释放不再被运行的程序引用的对象所占据的内存。通常,虚拟机把这个任务交给垃圾收集器。
 对于大多数应用来说,Java 堆(Java Heap)是Java 虚拟机所管理的内存中最大的一块。Java 堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存。
 Java 堆是垃圾收集器管理的主要区域。如果从内存回收的角度看,由于现在收集器基本都是采用的分代收集算法,所以Java 堆中还可以细分为:新生代和老年代;再细致一点的有Eden 空间、From Survivor 空间、To Survivor 空间等。
 如果从内存分配的角度看,线程共享的Java 堆中可能划分出多个线程私有的分配缓冲区(Thread LocalAllocation Buffer,TLAB)。不过,无论如何划分,都与存放内容无关,无论哪个区域,存储的都仍然是对象实例,进一步划分的目的是为了更好地回收内存,或者更快地分配内存。
 根据Java 虚拟机规范的规定,Java 堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可,就像我们的磁盘空间一样。在实现时,既可以实现成固定大小的,也可以是可扩展的,不过当前主流的虚拟机都是按照可扩展来实现的(通过-Xmx-Xms 控制)。如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,将会抛出OutOfMemoryError 异常。

1.1.3.1 对象在堆中的内存结构

http://www.programcreek.com/2011/11/what-do-java-objects-look-like-in-memory/

 一旦对象在堆中分配了空间,那本质上就是一系列的字节. 那么如何找到对象中某个特定的属性域呢? 编译器通过一个内部表来保存每个域的偏移量。
 子类对象和父类对象拥有同样的内存分布,当然,子类对象需要更多的空间来存放新的属性域.这种分配方式的好处在于,Base类型的指针如果指向了子类Derived的对象, 指针可以在Object开始处找到Base对象。
 因此, 子类对象(Derived)采用 父类引用(Base) 来进行的操作 保证是安全的,因此在运行时不需要动态地检查 Base 引用的实际类型。
 下图是 Base 类的一个对象内存分布图,Base(基类)没有定义任何方法:
Alt text
 如果还有另一个派生类 “Derived” 继承了基类”Base”.那么内存分布将如下图所示:
Alt text
 依据跟上述同样的道理,对象的方法也就可以放到Object空间的开始处,如下图所示:
Alt text
 然而这种实现方式是没有效率的.假若一个类有很多方法(例如20个),那么每个对象就要持有20个指针,相应的,每个对象都需要20个指针的内存空间,这会导致创建对象变慢,所占空间更大。
 优化手段是创建一个 虚拟函数表(vtable,虚表),虚表是一个指向特定类的成员函数的指针数组. 如下图所示: 
Alt text

1.1.3.2 数组在堆中的内存结构

 数组引用变量是存放在栈内存(Stack)中,数组元素是存放在堆内存(Heap)中,通过栈内存中的指针指向对应元素的在堆内存中的位置来实现访问,以下图来说明数组此时的存放形式。
Alt text
 当执行方法时,该方法都会建立自身的内存栈,以用来将该方法内部定义的变量逐个加入到内存栈中,当执行结束时方法的内存栈也随之销毁,我们说所有变量存放在栈内存中,即随着寄存主体的消亡而消亡;反之,当我们创建一个对象时,这个对象被保存到运行时数据区中,以便反复利用(因为创建成本很高),此时不会随着执行方法的结束而消亡,同时该对象还可被其他对象所引用,只有当这个对象没有被任何引用变量引用时,才会在垃圾回收在合适的时间点回收,我们说此时变量所指向的运行时数据区存在堆内存中。
 只有类型兼容(即属于同一数据类型体系且遵守优先级由低到高原则),才能将数组引用传递给另一数组引用,但仍然不能改变数组长度(仅仅只是调整数组引用指针的指向)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class TestArrayLength {
public static void main(String[] args) {
int[] numbers = { 3, 5, 12 };
int[] digits = new int[4];
System.out.println("digits数组长度:" + digits.length);//4
for(int number : numbers) {
System.out.print(number + ",");//3,5,12,
}
System.out.println("");
for(int digit : digits) {
System.out.print(digit + ",");//0,0,0,0,
}
System.out.println("");
digits = numbers;
System.out.println("digits数组长度:" + digits.length);//3
}
}

 虽然看似digits的数组长度看似由4变成3,其实只是numbers和digits指向同一个数组而已,而digits本身失去引用而变成垃圾,等待垃圾回收来回收(但其长度仍然为4),但其内部运行机制如下图所示。
Alt text
 因此当我们看一个数组时(或者其他引用变量),通常看成两部分:数组引用变量和数组元素本身,而数据元素是存放在堆内存中,只能通过数组引用变量来访问。
 对于数组元素为引用类型在内存中的存储与基本类型不一样,此时数组元素仍然存放引用,指向另一块内存,在其中存放有效的数据。

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
class Person {
public int age;
public String name;
public void display() {
System.out.println(name + "的年龄是: " + age);
}
}
public class TestReferenceArray {
public static void main(String[] args) {
//1.定义数组
Person[] persons;
//2.分配内存空间
persons = new Person[2];
//3.为数组元素指定值
Person p1 = new Person();
p1.age = 28;
p1.name = "Miracle";
Person p2 = new Person();
p2.age = 30;
p2.name = "Miracle He";
persons[0] = p1;
persons[1] = p2;
//输出元素的值
for(Person p : persons) {
p.display();
}
}
}

内存结构如下图所示:
Alt text

1.1.4 方法区(Method Area)

关键语句:

  • 线程共享
  • GC较少出现在这个区域
  • GC目标针对常量池与类型
  • 存储类信息、常量、静态变量、即使编译器编译后的代码等

 在Java虚拟机中,关于被装载类型的信息存储在一个逻辑上被称为方法区的内存中。当虚拟机装载某个类型时,它使用类装载器定位相应的.class文件,然后读入这个.class文件——1个线性二进制数据流,然后它传输到虚拟机中,紧接着虚拟机提取其中的类型信息,并将这些信息存储到方法区。该类型中的类(静态)变量同样也是存储在方法区中。
 Java虚拟机在内部如何存储类型信息,这是由具体实现的设计者来决定的。
 当虚拟机运行Java程序时,它会查找使用存储在方法区中的类型信息。由于所有线程都共享方法区,因此它们对方法区数据的访问必须被设计为是线程安全的。比如,假设同时有两个线程都企图访问一个名为A的类,而这个类还没有被装入虚拟机,那么,这时只应该有一个线程去装载它,而另一个线程则只能等待。

1.1.4.1 运行时常量池(Runtime Constant Pool)

 运行时常量池(Runtime Constant Pool)是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各种字面量*和符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。
 Java 虚拟机对Class 文件的每一部分(自然也包括常量池)的格式都有严格的规定,每一个字节用于存储哪种数据都必须符合规范上的要求,这样才会被虚拟机认可、装载和执行。但对于运行时常量池,Java 虚拟机规范没有做任何细节的要求,不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过,一般来说,除了保存Class 文件中描述的符号引用外,还会把翻译出来的直接引用也存储在运行时常量池中。
 运行时常量池相对于Class 文件常量池的另外一个重要特征是具备动态性,Java 语言并不要求常量一定只能在编译期产生,也就是并非预置入Class 文件中常量池的内容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中,这种特性被开发人员利用得比较多的便是String 类的intern()方法。
 既然运行时常量池是方法区的一部分,自然会受到方法区内存的限制,当常量池无法再申请到内存时会抛出OutOfMemoryError异常

注:字面量可以是任意的数字或字符,直接代表了一个值。
int i = 666 ; //666是一个数字字面量S
tring str = “Hello Java” ; //“Hello Java”是字符串字面量

1.1.5 直接内存(Direct Memory)

 直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域,但是这部分内存也被频繁地使用,而且也可能导致OutOfMemoryError 异常出现,十分注意NIO的内存影响。

1.2 Java对象

1.2.1 对象的创建

 虚拟机遇到一条new指令时,首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程。
 在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定,为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。

  •  假设Java堆中内存是绝对规整的,所有用过的内存都放在一边,空闲的内存放在另一边,中间放着一个指针作为分界点的指示器,那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离,这种分配方式称为“指针碰撞”(Bump the Pointer)。
  •  如果Java堆中的内存并不是规整的,已使用的内存和空闲的内存相互交错,那就没有办法简单地进行指针碰撞了,虚拟机就必须维护一个列表,记录上哪些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录,这种分配方式称为“空闲列表”(Free List)。
  •  选择哪种分配方式由Java堆是否规整决定,而Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定。因此,在使用Serial、ParNew等带Compact过程的收集器时,系统采用的分配算法是指针碰撞,而使用CMS这种基于Mark-Sweep算法的收集器时,通常采用空闲列表。

 对象创建在虚拟机中是非常频繁的行为,即使是仅仅修改一个指针所指向的位置,在并发情况下也并不是线程安全的,可能出现正在给对象A分配内存,指针还没来得及修改,对象B又同时使用了原来的指针来分配内存的情况。
 解决这个问题有两种方案,一种是对分配内存空间的动作进行同步处理——实际上虚拟机采用CAS配上失败重试的方式保证更新操作的原子性;另一种是把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在Java堆中预先分配一小块内存,称为本地线程分配缓冲(Thread Local Allocation Buffer,TLAB)。哪个线程要分配内存,就在哪个线程的TLAB上分配,只有TLAB用完并分配新的TLAB时,才需要同步锁定。虚拟机是否使用TLAB,可以通过-XX:+/-UseTLAB参数来设定。(补:-XX:TLABSize设置TLAB大小,为’0’时动态分配)
 内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头),如果使用TLAB,这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用,程序能访问到这些字段的数据类型所对应的零值。
 接下来,虚拟机要对对象进行必要的设置,例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头(Object Header)之中。根据虚拟机当前的运行状态的不同,如是否启用偏向锁等,对象头会有不同的设置方式。关于对象头的具体内容,稍后再做详细介绍。
 在上面工作都完成之后,从虚拟机的视角来看,一个新的对象已经产生了,但从Java程序的视角来看,对象创建才刚刚开始——方法还没有执行,所有的字段都还为零。所以,一般来说(由字节码中是否跟随invokespecial指令所决定),执行new指令之后会接着执行方法,把对象按照程序员的意愿进行初始化,这样一个真正可用的对象才算完全产生出来。

1.2.2 对象的内存布局

 在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。
对象头 分为两部分信息:

  • 第一部分用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等
  • 另外一部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。

实例数据部分
 实例数据部分是对象真正存储的有效信息,也是在程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的,还是在子类中定义的,都需要记录起来。HotSpot虚拟机默认的分配策略为longs/doubles、ints、shorts/chars、bytes/booleans、oops(Ordinary Object Pointers),从分配策略中可以看出,相同宽度的字段总是被分配到一起。在满足这个前提条件的情况下,在父类中定义的变量会出现在子类之前。
附:Java虚拟机中的数据类型
Alt text

对齐填充
仅仅起着占位符的作用

1.2.3 对象访问定位

 建立对象是为了使用对象,我们的Java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用,并没有定义这个引用应该通过何种方式去定位、访问堆中的对象的具体位置,所以对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式有使用句柄和直接指针两种。
 如Object objectRef = new Object();出现在方法体中,Object objectRef 这部分将会反映到Java栈的本地变量中,作为一个reference类型数据出现。而new Object()这部分将会反映到Java堆中,形成一块存储Object类型所有实例数据值的结构化内存,根据具体类型以及虚拟机实现的对象内存布局的不同,这块内存的长度是不固定。
reference类型在java虚拟机规范里面只规定了一个指向对象的引用地址,并没有定义这个引用应该通过那种方式去定位,访问到Java堆中的对象位置,因此不同的虚拟机实现的访问方式可能不同,主流的方式有两种:使用句柄和直接指针。

  • 如果使用句柄访问的话,那么Java堆中将会划分出一块内存来作为句柄池,reference中存储的就是对象的句柄地址,而句柄中包含了对象实例数据与类型数据各自的具体地址信息
    Alt text
  • 如果使用直接指针访问,那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息,而reference中存储的直接就是对象地址
    Alt text

1.2.4 Java对象生成方式

 在java程序中,对象可以被显式地或者隐式地创建.四种显式的创建对象的方式:

  • 用new语句创建对象
  • 运用反射手段,调用java.lang.Class 或者 java.lang.reflect.Constructor 类的newInstance()实例方法
  • 调用对象的clone()方法
  • 运用序列化手段,调用java.io.ObjectInputStream 对象的 readObject()方法.

二、内存溢出

2.1 内存溢出与内存泄露

C++与Java语言对于内存泄露的概念似乎有所不同

  • 在C++/C中的内存泄露:传统的以C++的角度所谓的内存泄漏,是指一块内存不可达了,就是说这片内存你即引用不到也没办法重新分配,c和c++里的确很容易有这种情况,最简单的比如在一个局部域里int *a = malloc(10)* sizeof(int);,当走出这个局部域后*a不能使用了,但10*sizeof(int)这片内存也没有任何机制去回收。
  • 在Java中内存泄露:严格来说不是内存泄露,只要内存不可达了,就一定会被回收。即:当一个内存对象失去了所有的引用之后,GC 就可以将其回收。Java所谓的内存泄漏,应该是指程序员以为已经释放了内存,其实并没有。

     所以有没有内存泄漏,关键还是看说内存泄漏是以怎么样的一种标准来评判的。
     而内存溢出指的是:

    通俗理解就是内存不够,通常在运行大型软件或游戏时,软件或游戏所需要的内存远远超出了你主机内安装的内存所承受大小,就叫内存溢出。此时软件或游戏就运行不了,系统会提示内存溢出,有时候会自动关闭软件,重启电脑或者软件后释放掉一部分内存又可以正常运行该软件或游戏一段时间。—-百度百科

2.2 Java中常见的内存溢出异常

2.2.1 Java堆溢出

Full GCjava.lang.OutOfMemoryError: Java heap space

 Java堆用于存储对象实例,只要不断地创建对象,并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象,那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。
 通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。

1
2
3
4
5
6
7
8
9
10
public class HeapOOM {
static class OOMObject {
}
public static void main(String[] args) {
List<UserBean> users = new ArrayList<UserBean>();
while (true) {
users.add(new UserBean());
}
}
}

2.2.2 虚拟机栈溢出与本地方法栈溢出

java.lang.StackOverflowError

 由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,因此,对于HotSpot来说,虽然-Xoss参数(设置本地方法栈大小)存在,但实际上是无效的,栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈,在Java虚拟机规范中描述了两种异常:

  • 如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常。
  • 如果虚拟机在扩展栈时无法申请到足够的内存空间,则抛出OutOfMemoryError异常。

     这里把异常分成两种情况,看似更加严谨,但却存在着一些互相重叠的地方:当栈空间无法继续分配时,到底是内存太小,还是已使用的栈空间太大,其本质上只是对同一件事情的两种描述而已。
     使用-Xss参数减少栈内存容量。结果:抛出StackOverflowError异常,异常出现时输出的堆栈深度相应缩小。
     定义了大量的本地变量,增大此方法帧中本地变量表的长度。结果:抛出StackOverflowError异常时输出的堆栈深度相应缩小。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    public class VMStackOOM { 
    class Recursion {
    public int currentValue = 0;
    public void recursionself() {
    currentValue += 1;
    recursionself();
    }
    public static void main(String[] args) {
    Recursion recursion = new Recursion();
    try {
    recursion.recursionself();
    } catch (Throwable e) {
    System.out.println("current value :" + recursion.currentValue);
    throw e;
    }
    }
    }

2.2.3 方法区和运行时常量池溢出

java.lang.OutOfMemoryError: PermGen space

 由于运行时常量池是方法区的一部分,因此这两个区域的溢出测试就放在一起进行。前面提到JDK 1.7开始逐步“去永久代”的事情,在此就以测试代码观察一下这件事对程序的实际影响。我们可以通过-XX:PermSize-XX:MaxPermSize限制方法区大小,从而间接限制其中常量池的容量。
 这样的应用经常会出现在实际应用中:当前的很多主流框架,如Spring、Hibernate,在对类进行增强时,都会使用到CGLib这类字节码技术,增强的类越多,就需要越大的方法区来保证动态生成的Class可以加载入内存。我们借助CGLib使方法区出现内存溢出异常.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class JavaMethodAreaOOM {
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create();
}
}
static class OOMObject {
}
}

三、初略GC预览

文章目錄
  1. 1. 一、Java内存结构
    1. 1.1. 1.1 运行时数据区域
      1. 1.1.1. 1.1.1 程序计数器(Program Counter Register)
      2. 1.1.2. 1.1.2 Java虚拟机栈(Java Virtual Machine Stacks)
        1. 1.1.2.1. 1.1.2.1 虚拟机栈
        2. 1.1.2.2. 1.1.2.2 栈帧初略(局部变量表与操作数栈)
      3. 1.1.3. 1.1.3 本地方法栈(Native Method Stacks)
      4. 1.1.4. 1.1.3 Java堆(Java Heap)
        1. 1.1.4.1. 1.1.3.1 对象在堆中的内存结构
        2. 1.1.4.2. 1.1.3.2 数组在堆中的内存结构
      5. 1.1.5. 1.1.4 方法区(Method Area)
        1. 1.1.5.1. 1.1.4.1 运行时常量池(Runtime Constant Pool)
      6. 1.1.6. 1.1.5 直接内存(Direct Memory)
    2. 1.2. 1.2 Java对象
      1. 1.2.1. 1.2.1 对象的创建
      2. 1.2.2. 1.2.2 对象的内存布局
      3. 1.2.3. 1.2.3 对象访问定位
      4. 1.2.4. 1.2.4 Java对象生成方式
  2. 2. 二、内存溢出
    1. 2.1. 2.1 内存溢出与内存泄露
    2. 2.2. 2.2 Java中常见的内存溢出异常
      1. 2.2.1. 2.2.1 Java堆溢出
      2. 2.2.2. 2.2.2 虚拟机栈溢出与本地方法栈溢出
      3. 2.2.3. 2.2.3 方法区和运行时常量池溢出
  3. 3. 三、初略GC预览