本文深入解析了HotSpot JVM的主要组成部分，包括程序计数器、JAVA虚拟机栈、JAVA堆、方法区、运行时常量池等，并详细阐述了它们的作用及相互关系。同时，文章还介绍了HotSpot JVM如何判断对象是否死亡，以及处理StackOverflowError和OutOfMemoryError异常的方法。
虚拟机——本文专门针对HotSpot JVM——的主要组成部分：
[img]http://dl.iteye.com/upload/attachment/0083/4006/c92cad27-b907-38f2-9bd3-5e664feee79b.jpg[/img]
[b]程序计数器：[/b]每一个线程都有一个是独立的私有程序计数器，它保存有该线程要执行的下一条指令的内存地址。
[b]JAVA 虚拟机栈：[/b] JVM Stack也是线程私有的，每一个线程都会在该栈中独占一块儿区域。它描述了JAVA方法执行的内存模型：每次线程调用一个方法的时候都会在自己的线程栈内创建一个栈帧(Stack Frame)，用于保存局部变量表、方法的出口等信息，每一个方法从调用到执行完成的过程，都对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
[b]程序员口中经常说的栈(Stack)就是指虚拟机栈。栈是JVM的运行时单位。[/b]
[b]JAVA 堆：[/b]对大多数应用来说，JAVA Heap是JAVA虚拟机所管理的内存中最大的一块儿区域，该区域为所有线程公用，程序在运行时产生的几乎所有对象都保存在堆中。
JAVA 虚拟机规范中是这样描述Heap的：所有的对象十里河数组都要在对上分配(The heap is rhe runtime data area from which memory for all class instances and arrays is allocated.)，但随着JIT编译器的发展和逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有对象都分配在堆上方也渐渐变得不那么“绝对”了。
[b]程序员口中经常说的堆就是指该部分，它是JVM的存储的单位。[/b]JAVA Heap是java 垃圾收集器管理的主要区域，很多时候也被称为“GC堆”。
[b]方法区：[/b]和Heap堆一样也是被各个线程共享的一块儿内存区，主要用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；虽然虚拟机规范将该区描述为堆的一个逻辑部分，但是它却有一个叫“非堆(non-Heap)”的别名，与Java Heap区分。
[b]对于很多使用HotSpot JVM做开发和部署的程序原来说，方法区被叫做“永久代”，实际上只是因为HotSpot JVM把GC的分代收集算法扩展至方法区，或者使用永久代来实现方法区而已。[/b]其他几个虚拟机产品并没有“永久代”这一说儿。
[b]运行时常量池：[/b]Runtime Constant Pool是方法去的一部分。Class文件中处了有累的字段、方法、接口、版本等描述信息外，还有一项信息是常量池Constant Pool Table，用于存放编译期生成的各种字面量和符号引用，这部分信息将在类加载后存放到方法区的运行时常量池中。
[b]OutOfMemoryError异常和StackOverflowError异常[/b]
首先说StackOverflowError，它是在JVM Stack内存不足时产生的异常。JVM规范是这样描述StackOverflowError异常的：当线程请求的栈的深度大于虚拟机所允许的最大深度时，将抛出StackOverflowError异常。当不能线程不能再在栈中压入新的栈帧(Stack Frame)时，就会产生StackOverflowError异常。
[b]当不能生成新的JAVA线程或不能向线程栈中压入新的栈帧(即JAVA线程不能再调用方法)时，就会产生StackOverflowError。[/b]
[b]对于OutOfMemoryError异常来说，以下几种情况可以导致OOM：
1、物理内存太小，如本机内存直接溢出；
2、堆大小设置不合理，如运行时常量池溢出、方法区溢出等；
3、代码逻辑有问题，使大量的对象不能正常释放；
以上三种情况都会引起OutOfMemoryError。[/b]
[u][b]Hotspot JVM怎么判断对象是否死亡[/b][/u]
我们都知道，JAVA垃圾收集器只会回收已“死亡”的对象。那么JVM是怎么知道一个对象是否已经“死亡”，换句话说JVM是通过什么算法来断定一个对象的状态？“生存还是死亡，这是个大问题”，判断错误，就会引起大灾难。
Hotspot JVM有两种算法来判断堆中的对象的状态的：
[i][b]1、引用计数法[/b]：[/i]每个对象中都有一个引用计数器，每当被引用时，计数器值就加1；当一个引进用失效时，计算器就减1；任何计数器值为0的对象就是不在被使用的，这样的对象就表示已“死亡”的对象，要被JVM垃圾收集器回收的。
引用计数法的优缺点：实现简单，效率很高；但是该算法有一个比较突出的问题：如两个对象除了互相引用外，没有其他对象对二者的引用，那么由于计算器的值都为1，那这连个对象就“永远”不会被垃圾收集器正常回收。如下图示：
[img]http://dl.iteye.com/upload/attachment/0083/8319/5a4ce9e1-d275-3c0d-a071-4a8ca35fa564.jpg[/img]
[i][b]2、根搜索算法[/b]：[/i]在主流的商用程序语言中，都是使用[b]根搜索算法[/b]来判断对象是否存活。该算法的基本思路就是：通过一系列的叫“GC Roots”的对象做起点，从这些节点开始搜索，搜索走过的路径将引用链，当一个对象没有和GC Roots的引用链有任何相连时，就可断定该对象不可用，可以被垃圾收集器回收。
在JAVA语言中，可作为GC Roots的对象有以下几种：
1、虚拟机栈中引用的变量；
2、方法区中的类静态属性引用的对象；
3、方法区中常量引用的对象；
4、本地方法栈中JNI的引用的对象。
[img]http://dl.iteye.com/upload/attachment/0083/4006/c92cad27-b907-38f2-9bd3-5e664feee79b.jpg[/img]
[b]程序计数器：[/b]每一个线程都有一个是独立的私有程序计数器，它保存有该线程要执行的下一条指令的内存地址。
[b]JAVA 虚拟机栈：[/b] JVM Stack也是线程私有的，每一个线程都会在该栈中独占一块儿区域。它描述了JAVA方法执行的内存模型：每次线程调用一个方法的时候都会在自己的线程栈内创建一个栈帧(Stack Frame)，用于保存局部变量表、方法的出口等信息，每一个方法从调用到执行完成的过程，都对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
[b]程序员口中经常说的栈(Stack)就是指虚拟机栈。栈是JVM的运行时单位。[/b]
[b]JAVA 堆：[/b]对大多数应用来说，JAVA Heap是JAVA虚拟机所管理的内存中最大的一块儿区域，该区域为所有线程公用，程序在运行时产生的几乎所有对象都保存在堆中。
JAVA 虚拟机规范中是这样描述Heap的：所有的对象十里河数组都要在对上分配(The heap is rhe runtime data area from which memory for all class instances and arrays is allocated.)，但随着JIT编译器的发展和逃逸分析技术的逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化发生，所有对象都分配在堆上方也渐渐变得不那么“绝对”了。
[b]程序员口中经常说的堆就是指该部分，它是JVM的存储的单位。[/b]JAVA Heap是java 垃圾收集器管理的主要区域，很多时候也被称为“GC堆”。
[b]方法区：[/b]和Heap堆一样也是被各个线程共享的一块儿内存区，主要用于存储已被JVM加载的类信息、常量、静态变量、即时编译器编译后的代码等数据；虽然虚拟机规范将该区描述为堆的一个逻辑部分，但是它却有一个叫“非堆(non-Heap)”的别名，与Java Heap区分。
[b]对于很多使用HotSpot JVM做开发和部署的程序原来说，方法区被叫做“永久代”，实际上只是因为HotSpot JVM把GC的分代收集算法扩展至方法区，或者使用永久代来实现方法区而已。[/b]其他几个虚拟机产品并没有“永久代”这一说儿。
[b]运行时常量池：[/b]Runtime Constant Pool是方法去的一部分。Class文件中处了有累的字段、方法、接口、版本等描述信息外，还有一项信息是常量池Constant Pool Table，用于存放编译期生成的各种字面量和符号引用，这部分信息将在类加载后存放到方法区的运行时常量池中。
[b]OutOfMemoryError异常和StackOverflowError异常[/b]
首先说StackOverflowError，它是在JVM Stack内存不足时产生的异常。JVM规范是这样描述StackOverflowError异常的：当线程请求的栈的深度大于虚拟机所允许的最大深度时，将抛出StackOverflowError异常。当不能线程不能再在栈中压入新的栈帧(Stack Frame)时，就会产生StackOverflowError异常。
[b]当不能生成新的JAVA线程或不能向线程栈中压入新的栈帧(即JAVA线程不能再调用方法)时，就会产生StackOverflowError。[/b]
[b]对于OutOfMemoryError异常来说，以下几种情况可以导致OOM：
1、物理内存太小，如本机内存直接溢出；
2、堆大小设置不合理，如运行时常量池溢出、方法区溢出等；
3、代码逻辑有问题，使大量的对象不能正常释放；
以上三种情况都会引起OutOfMemoryError。[/b]
[u][b]Hotspot JVM怎么判断对象是否死亡[/b][/u]
我们都知道，JAVA垃圾收集器只会回收已“死亡”的对象。那么JVM是怎么知道一个对象是否已经“死亡”，换句话说JVM是通过什么算法来断定一个对象的状态？“生存还是死亡，这是个大问题”，判断错误，就会引起大灾难。
Hotspot JVM有两种算法来判断堆中的对象的状态的：
[i][b]1、引用计数法[/b]：[/i]每个对象中都有一个引用计数器，每当被引用时，计数器值就加1；当一个引进用失效时，计算器就减1；任何计数器值为0的对象就是不在被使用的，这样的对象就表示已“死亡”的对象，要被JVM垃圾收集器回收的。
引用计数法的优缺点：实现简单，效率很高；但是该算法有一个比较突出的问题：如两个对象除了互相引用外，没有其他对象对二者的引用，那么由于计算器的值都为1，那这连个对象就“永远”不会被垃圾收集器正常回收。如下图示：
[img]http://dl.iteye.com/upload/attachment/0083/8319/5a4ce9e1-d275-3c0d-a071-4a8ca35fa564.jpg[/img]
[i][b]2、根搜索算法[/b]：[/i]在主流的商用程序语言中，都是使用[b]根搜索算法[/b]来判断对象是否存活。该算法的基本思路就是：通过一系列的叫“GC Roots”的对象做起点，从这些节点开始搜索，搜索走过的路径将引用链，当一个对象没有和GC Roots的引用链有任何相连时，就可断定该对象不可用，可以被垃圾收集器回收。
在JAVA语言中，可作为GC Roots的对象有以下几种：
1、虚拟机栈中引用的变量；
2、方法区中的类静态属性引用的对象；
3、方法区中常量引用的对象；
4、本地方法栈中JNI的引用的对象。
扫一扫
14万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
