勿在流沙住高台, 出来混迟早要还的.
做一个积极的人
编码, 改 bug, 提升自己
我有一个乐园, 面向编程, 春暖花开!
上一篇分享了 JVM 及其启动流程, 今天介绍一下 JVM 内部的一些区域, 以及具体的区域在运行过程中会发生哪些异内存常! 其实也就对应了内存管理的第一篇中 JVM 的第三个阶段, 程序运行内存溢出.
知识地图:
一, 概述
Java 的内存管理采用 [自动内存管理] 机制, 因为这个自动管理机制, Java 程序员就不需要去写释放内存的代码, 而且不容易出现内存泄漏问题(比 C/C++ 程序员少一些烦恼). 但是由于内存的申请和释放都交给了 Java 虚拟机, 一旦出现内存泄漏和溢出问题时, 在不了解 Java 虚拟机内存结构和自动管理机制的情况下, 就很难排查问题的所在. 所以如果想要成为一个优秀的程序员或者进阶为一个牛逼的架构师, 掌握 Java 虚拟机的自动内存管理机制那是必须的.
二, JVM 运行时数据区域
根据《Java 虚拟机规范(Java SE 7 版)》的规定, Java 虚拟机所管理的内存将会包括以下几个运行时的数据区域: 程序计数器(Program Counter Register),Java 栈(VM Stack), 本地方法栈(Native Method Stack), 方法区(Method Area), 堆(Heap).
如图所示:
注: 上图的虚拟机运行时数据区是 Java 虚拟机规范所规定的区域, 不同的虚拟机有不同的实现.
上面图片有线程共享和线程隔离的区域, 下面在通过一张图片来进行简单说明, 让你更加清晰的理解什么是线程共享和什么是线程隔离.
通过上面的两个图, 大概对 JVM 的内存模型有个初步的认识, 下面我们在看一下具体的每一个区域到底是什么东东.
1, 程序计数器
程序计数器 (Program Counter Register) 是一块较小的内存空间, 它可以是看作当前线程所执行的字节码的行号指示器. 说简单一点就是一个计数器, 当字节码解释器工作是能够通过改变这个计数器的值来选取下一条需要执行的字节码指令. 在说明一点, 各条线程之间计数器互不影响, 独立存储, 程序计数器器内存区域为 线程私有 的.
类比汇编语言中的程序计数器: 在汇编语言中, 程序计数器是指 CPU 中的寄存器, 它保存的是程序当前执行的指令的地址(也可以说保存下一条指令的所在存储单元的地址), 当 CPU 需要执行指令时, 需要从程序计数器中得到当前需要执行的指令所在存储单元的地址, 然后根据得到的地址获取到指令, 在得到指令之后, 程序计数器便自动加 1 或者根据转移指针得到下一条指令的地址, 如此循环, 直至执行完所有的指令.
在 JVM 规范中规定, 如果线程执行的是非 native 方法, 则程序计数器中保存的是当前需要执行的指令的地址; 如果线程执行的是 native 方法, 则程序计数器中的值是 undefined. 由于程序计数器中存储的数据所占空间的大小不会随程序的执行而发生改变, 因此, 此内存区域是唯一一个在 JVM 规范中没有规定任何 OutOfMemoryError 情况的区域.
2. 本地方法栈
本地方法栈和虚拟机栈所发挥的作用是很相似的, 它们之间的区别不过是 虚拟机栈为虚拟机执行 Java 方法 (字节码) 服务, 而本地方法栈则为虚拟机使用到的 Native 方法服务. Sun HotSpot 直接就把本地方法栈和虚拟机栈合二为一. 本地方法栈也会抛出 StackOverflowError 和 OutOfMemoryError 异常.
3,Java 虚拟机栈
Java 栈也称作虚拟机栈 (Java Vitual Machine Stack), 也是常说的栈. Java 栈是 Java 方法执行的内存模型. Java 栈中存放的是一个个的栈帧, 每个栈帧对应一个被调用的方法, 在栈帧中包括局部变量表(Local Variables), 操作数栈(Operand Stack), 指向当前方法所属的类的运行时常量池(运行时常量池的概念在方法区部分会谈到) 的引用 (Reference to runtime constant pool), 方法返回地址(Return Address) 和一些额外的附加信息. 栈也是线程私有的.
下图表示了一个 Java 栈的模型
1), 局部变量表
就是用来存储方法中的局部变量(包括在方法中声明的非静态变量以及函数形参). 对于基本数据类型的变量, 则直接存储它的值, 对于引用类型的变量, 则存的是指向对象的引用. 局部变量表的大小在编译器就可以确定其大小了, 因此在程序执行期间局部变量表的大小是不会改变的.
2), 操作数栈
想必学过数据结构中的栈的朋友想必对表达式求值问题不会陌生, 栈最典型的一个应用就是用来对表达式求值. 想想一个线程执行方法的过程中, 实际上就是不断执行语句的过程, 而归根到底就是进行计算的过程. 因此可以这么说, 程序中的所有计算过程都是在借助于操作数栈来完成的.
3), 指向运行时常量池的引用
因为在方法执行的过程中有可能需要用到类中的常量, 所以必须要有一个引用指向运行时常量.
4), 方法返回地址
当一个方法执行完毕之后, 要返回之前调用它的地方, 因此在栈帧中必须保存一个方法返回地址. 由于每个线程正在执行的方法可能不同, 因此每个线程都会有一个自己的 Java 栈, 互不干扰. 也就解释了栈是线程私有的.
当线程执行一个方法时, 就会随之创建一个对应的栈帧, 并将建立的栈帧压栈. 当方法执行完毕之后, 便会将栈帧出栈. 因此可知, 线程当前执行的方法所对应的栈帧必定位于 Java 栈的顶部. 在这个区域规定了两种异常状况:
如果线程请求的栈深入大于虚拟机所允许的深度, 将抛出 StackOverFlowError 异常!
如果虚拟机栈可以动态扩展, 当扩展到无法申请内存到足够的内存, 就会抛出 OutOfMemoryError 异常!
4,Java 堆
堆是 jvm 内存管理的最大的一块区域, 此内存区域的唯一目的就是存放对象的实例, 所有对象实例与数组都要在堆上分配内存. 它也是垃圾收集器的主要管理区域. java 对可以处于物理上不连续的空间, 只要逻辑上是连续的即可. 线程共享的区域. 如果在堆中没有内存完成实例分配, 并且堆也无法再扩展时, 将抛出 OutOfMemoryError 异常.
为了支持垃圾收集, 堆被分为三个部分:
年轻代 : 常常又被划分为 Eden 区和 Survivor(From Survivor To Survivor)区(Eden 空间, From Survivor 空间, To Survivor 空间(空间分配比例是 8:1:1)
老年代
永久代 (jdk 8 已移除永久代, 下面会讲解)
1) 堆是 JVM 中所有线程共享的, 因此在其上进行对象内存的分配均需要进行加锁, 这也导致了 new 对象的开销是比较大的 (2) Sun Hotspot JVM 为了提升对象内存分配的效率, 对于所创建的线程都会分配一块独立的空间 TLAB(Thread Local Allocation Buffer), 其大小由 JVM 根据运行的情况计算而得, 在 TLAB 上分配对象时不需要加锁, 因此 JVM 在给线程的对象分配内存时会尽量的在 TLAB 上分配, 在这种情况下 JVM 中分配对象内存的性能和 C 基本是一样高效的, 但如果对象过大的话则仍然是直接使用堆空间分配 (3) TLAB 仅作用于新生代的 Eden Space, 因此在编写 Java 程序时, 通常多个小的对象比大的对象分配起来更加高效.
(4) 所有新创建的 Object 都将会存储在新生代 Yong Generation 中. 如果 Young Generation 的数据在一次或多次 GC 后存活下来, 那么将被转移到 OldGeneration. 新的 Object 总是创建在 Eden Space.
这些知识在后面学习 GC 和内存调优方面非常重要.
5, 方法区
方法区在 JVM 中也是一个非常重要的区域, 它与堆一样, 是被线程共享的区域. 在方法区中, 存储了每个类的信息(包括类的名称, 方法信息, 字段信息), 静态变量, 常量以及编译器编译后的代码等. 方法区是堆的一个逻辑部分, 为了区分 Java 堆, 它还有一个别名 Non-Heap(非堆). 相对而言, GC 对于这个区域的收集是很少出现的. 当方法区无法满足内存分配需求时, 将抛出 OutOfMemoryError 异常.
在 Java 7 及之前版本, 我们也习惯称方法区它为 "永久代"(Permanent Generation), 更确切来说, 应该是 "HotSpot 使用永久代实现了方法区"!
6, 运行时常量池
运行时常量池是方法区的一部分. Class 文件中除了有类的版本, 字段, 方法, 接口等描述信息外, 还有一项信息是常量池( Constant pool table), 用于存放编译期生成的各种字面量和符号引用, 这部分内容将在类加载后进入运行时常量池中存放. 运行时常量池相对于 class 文件常量池的另外一个特性是具备动态性, java 语言并不要求常量一定只有编译器才产生, 也就是并非预置入 class 文件中常量池的内容才能进入方法区运行时常量池, 运行期间也可能将新的常量放入池中.
7, 直接内存
直接内存 (Direct Memory) 并不是虚拟机运行时数据区的一部分, 也不是 JVM 规范中定义的内存区域. 但这部分内存也被频繁的使用, 而且也可能导致 OutOfMemoryError 异常出现.
JDK1.4 中新引入了 NIO 机制, 它是一种基于通道与缓冲区的新 I/O 方式, 可以直接从操作系统中分配直接内存, 即直接堆外分配内存, 这样能在一些场景中提高性能, 因为避免了在 Java 堆和 Native 堆中来回复制数据.
三, JDK7 和 JDK8 的 JVM 内存模型的总结
1, 方法区变化
这里介绍的是 JDK1.8 JVM 内存模型. 1.8 同 1.7 比, 最大的差别就是: 元数据区取代了永久代, 就是 JDK8 没有了 PermSize 相关的参数配置了. 元空间的本质和永久代类似, 都是对 JVM 规范中方法区的实现. 不过元空间与永久代之间最大的区别在于: 元数据空间并不在虚拟机中, 而是使用本地内存.
1)方法区与永久代的区别?
方法区只是 JVM 规范定义, 而永久代为具体的实现, 元空间也是方法区在 jdk1.8 中的一种实现.
2)为什么废除永久代?
1. 官方文档: 移除永久代是为融合 HotSpot JVM 与 JRockit VM 而做出的努力, 因为 JRockit 没有永久代, 不需要配置永久代
2..PermGen 很难调整, PermGen 中类的元数据信息在每次 FullGC 的时候可能被收集, 但成绩很难令人满意.
而且应该为 PermGen 分配多大的空间很难确定, 因为 PermSize 的大小依赖于很多因素, 比如 JVM 加载的 class 总数, 常量池的大小, 方法的大小等.
并且永久代内存经常不够用发生内存泄露.
2, 运行时常量池变化
在近三个 JDK 版本 (1.6,1.7,1.8) 中, 运行时常量池 (Runtime Constant Pool) 的所处区域一直在不断的变化, 在 JDK1.6 时它是方法区的一部分; 1.7 又把他放到了堆内存中; 1.8 之后出现了元空间, 它又回到了方法区. 其实, 这也说明了官方对 "永久代" 的优化从 1.7 就已经开始了.
贴一张 Java 8 的内存模型图:
四, 总结
运行时区域大概了解后, 我们在来总结一下:
| 运行时区域 | 异常 | 主要原因 | | -------------------- | ------------------------------------ | ------------------------------------------------------------ | | 虚拟机栈和本地方法栈 | StackOverflowError,OutOfMemoryError | StackOverflowError: 线程请求的栈深度大于虚拟机所允许的最大深度; OutOfMemoryError: 虚拟机在扩展栈时无法申请足够的内存空间 | | 程序计数器 | 无 | 无 | | 堆 | OutOfMemoryError | 对象数量到达最大堆的容量, 内存泄漏, 内存溢出 | | 方法区和运行时常量池 | OutOfMemoryError | 反射, 动态代理: CGLib,JSP,OSGI 等 |
最后在说两个概念:
内存泄露(Memory Leak): 程序在申请内存后, 对象没有被 GC 所回收, 它始终占用内存, 内存泄漏的堆积最终会造成内存溢出.
内存溢出(Memory Overflow): 程序运行过程中无法申请到足够的内存而导致的一种错误. 内存溢出通常发生于 OLD 段或 Perm 段垃圾回收后, 仍然无内存空间容纳新的 Java 对象的情况. 通常都是由于内存泄露导致堆栈内存不断增大, 从而引发内存溢出.
本文内容较多, 也比较重要, 因为本人也是在学习 JVM 中, 如果文中有不对的地方, 也请指出! 谢谢!
当我们了解了 JVM 和 JVM 里面有什么区域, 对后面学习和理解 JVM 的一些规范或者排查 JVM 相关的问题也更加容易一点, 当我们知道了 JVM 哪些地方报什么样的错误的时候, 在出现问题的时候, 能够快速的定位和解决, 这样对于我们的成长来说帮助也是非常大的, 继续学习 JVM, 深入对 JVM 的认识, 也了解更加有趣的 Java 世界.
五, 参考内容
《深入理解 Java 虚拟机》
JDK1.8 JVM 内存模型
Java 内存区域与内存溢出异常(jdk 6,7,8)
对于 JVM 内存模型的理解(对比 jdk1.7 与 1.8)
谢谢你的阅读, 如果您觉得这篇博文对你有帮助, 请点赞或者喜欢, 让更多的人看到! 祝你每天开心愉快!
不管做什么, 只要坚持下去就会看到不一样! 在路上, 不卑不亢!
博客首页 : http://blog.csdn.net/u010648555 http://blog.csdn.net/u010648555
愿你我在人生的路上能都变成最好的自己, 能够成为一个独挡一面的人
© 每天都在变得更好的阿飞云
Java 内存管理 - JVM 内存模型以及 JDK7 和 JDK8 内存模型对比总结(三)
来源: http://www.bubuko.com/infodetail-2995585.html