JVM运行时内存

本文来说下JVM运行时内存

---

概述

Java堆是线程共享的一块内存区域，几乎所有的对象实例在这里分配内存，也是垃圾收集器进行垃圾收集的最重要的内存区域。因此很多时候也叫GC堆。Java堆从GC的角度还可以细分为：新生代(Eden区、From Survivor区和To Survivor区)和老年代。JDK8的版本，因使用元空间代替永久代，字符串常量池和类的静态变量也放入java堆中。

---

新生代

是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象，所以新生代会频繁触发MinorGC进行垃圾回收。新生代又分为Eden区、ServivorFrom、ServivorTo三个区。

Eden区

Java新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代）。当Eden区内存不够的时候就会触发MinorGC，对新生代区进行一次垃圾回收。

ServivorFrom

上一次GC的幸存者，作为这一次GC的被扫描者。

ServivorTo

保留了一次MinorGC过程中的幸存者。

MinorGC的过程（复制->清空->互换）

MinorGC采用复制算法。

1.、eden、servicorFrom 复制到ServicorTo，年龄+1

首先，把Eden和ServivorFrom区域中存活的对象复制到ServicorTo区域（如果有对象的年龄以及达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1（如果ServicorTo不够位置了就放到老年区）；

2、清空eden、servicorFrom

然后，清空Eden和ServicorFrom中的对象；

3、ServicorTo和ServicorFrom互换

最后，ServicorTo和ServicorFrom互换，原ServicorTo成为下一次GC时的ServicorFrom 区。

---

老年代

主要存放应用程序中生命周期长的内存对象。

老年代的对象比较稳定，所以MajorGC不会频繁执行。在进行MajorGC前一般都先进行了一次MinorGC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次MajorGC进行垃圾回收腾出空间。

MajorGC采用标记清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没有标记的对象。MajorGC的耗时比较长，因为要扫描再回收。MajorGC会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配。当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）异常。

---

永久代

指内存的永久保存区域，主要存放Class和Meta（元数据）的信息,Class在被加载的时候被放入永久区域，它和存放实例的区域不同,GC不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的Class的增多而胀满，最终抛出OOM异常。

---

JAVA8与元数据

在Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。元空间的本质和永久代类似，元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入native memory, 字符串池和类的静态变量放入java堆中，这样可以加载多少类的元数据就不再由MaxPermSize控制, 而由系统的实际可用空间来控制。

1. 主要存储类的元数据，比如类的各种描述信息，类名、方法、字段、访问限制等，既编译器编译后的代码等数据
2. 运行时常量池：Class文件中除了有类的版本、字段、方法等描述等信息外；还有一项信息是常量池，用于存放编译期生成的各种字面量和符号引用，这部分将在类加载后存放到元空间的运行时常量池中

---

使用元空间代替永久代原因

1. 永久代的大小是在启动时固定好的，很难进行调优；太大则容易导致永久代溢出；太小在运行时，容易抛出OutOfMemeryError
2. 字符串存在永久代中，使用时易出问题，由于永久代内存经常不够用，爆出异常OutOfMemoryError: PermGen

方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java堆区分开来。
 
对于习惯在HotSpot虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“永久代”（Permanent Generation），本质上两者并不等价，仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9等）来说是不存在永久代的概念的。即使是HotSpot虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory来实现方法区的规划了。
 
Java虚拟机规范对这个区域的限制非常宽松，除了和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。在Sun公司的BUG列表中，曾出现过的若干个严重的BUG就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
 
根据Java虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。

以上描述截取自：《深入理解Java虚拟机》 作者： 周志明

---

本文小结

本文详细介绍了JVM运行内存相关的知识。