《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》_求知之路漫漫_2.2.5 方法区

【摘要】 本书摘自《深入理解 Java 虚拟机 JVM 高级特性与最佳实践(第3版)》一书中第2章，第2节，周志明著。

2.2.5 方法区

方法区 (Method Area) 与 Java 堆一样，是各个线程共享的内存区域，它用于存储已 被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。虽然 《Java 虚拟机规范》中把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫作“非堆” (Non-Heap), 目的是与Java 堆区分开来。

说到方法区，不得不提一下“永久代”这个概念，尤其是在JDK8 以前，许多Java 程 序员都习惯在HotSpot 虚拟机上开发、部署程序，很多人都更愿意把方法区称呼为“永久 代”(Permanent Generation),或将两者混为一谈。本质上这两者并不是等价的，因为仅仅是 当时的 HotSpot 虚拟机设计团队选择把收集器的分代设计扩展至方法区，或者说使用永久 代来实现方法区而已，这样使得 HotSpot 的垃圾收集器能够像管理Java 堆一样管理这部分 内存，省去专门为方法区编写内存管理代码的工作。但是对于其他虚拟机实现，譬如BEA JRockit 、IBMJ9 等来说，是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实 现细节，不受《 Java 虚拟机规范》管束，并不要求统一。但现在回头来看，当年使用永久 代来实现方法区的决定并不是一个好主意，这种设计导致了Java 应用更容易遇到内存溢出 的问题(永久代有-XX:MaxPermSize的上限，即使不设置也有默认大小，而J9 和JRockit 只要没有触碰到进程可用内存的上限，例如32位系统中的4GB限制，就不会出问题),而 且有极少数方法(例如 String:intern()) 会因永久代的原因而导致不同虚拟机下有不同的表 现。当 Oracle 收购 BEA获得了JRockit 的所有权后，准备把JRockit 中的优秀功能，譬如 Java Mission Control管理工具，移植到 HotSpot 虚拟机时，但因为两者对方法区实现的差 异而面临诸多困难。考虑到 HotSpot 未来的发展，在JDK6 的时候 HotSpot 开发团队就有 放弃永久代，逐步改为采用本地内存 (Native Memory) 来实现方法区的计划了日，到了JDK 7 的 HotSpot, 已经把原本放在永久代的字符串常量池、静态变量等移出，而到了JDK 8,终 于完全废弃了永久代的概念，改用与JRockit 、J9 一样在本地内存中实现的元空间 (Meta- space) 来代替，把JDK7 中永久代还剩余的内容(主要是类型信息)全部移到元空间中。

《Java 虚拟机规范》对方法区的约束是非常宽松的，除了和Java 堆一样不需要连续的 内存和可以选择固定大小或者可扩展外，甚至还可以选择不实现垃圾收集。相对而言，垃 圾收集行为在这个区域的确是比较少出现的，但并非数据进入了方法区就如永久代的名字 一样“永久”存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载， 一般来说这个区域的回收效果比较难令人满意，尤其是类型的卸载，条件相当苛刻，但是 这部分区域的回收有时又确实是必要的。以前 Sun公司的Bug 列表中，曾出现过的若干个 严重的 Bug就是由于低版本的 HotSpot 虚拟机对此区域未完全回收而导致内存泄漏。

根据《 Java 虚拟机规范》的规定，如果方法区无法满足新的内存分配需求时，将抛出 OutOfMemoryError 异常。

2.2.6 运行时常量池

运行时常量池 (Runtime Constant Pool) 是方法区的一部分。Class 文件中除了有类的版 本、字段、方法、接口等描述信息外，还有一项信息是常量池表 (Constant Pool Table), 用 于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运 行时常量池中。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们 18664393530@aliyun.com 处理，核实后本网站将在24小时内删除侵权内容。