栈、堆、办法区的关系



办法区在哪里?

https://docs.oracle.com/javas...

《Java虚拟机标准》中明确阐明: “只管所有的办法区在逻辑上是属于堆的一部分，但一些简略的实现可能不会抉择去进行垃圾收集或者进行压缩。” 但对于HotSpotJVM而言，办法区还有一个别名叫做Non-Heap(非堆)，目标就是要和堆离开。

所以，办法区看作是一块独立于Java 堆的内存空间。

办法区的了解

从线程共享与否的角度来看

  • 办法区（Method Area）与Java堆一样，是各个线程共享的内存区域。
  • 办法区在JVM启动的时候被创立，并且它的理论的物理内存空间中和Java堆区一样都能够是不间断的。
  • 办法区的大小，跟堆空间一样，能够抉择固定大小或者可扩大。
  • 办法区的大小决定了零碎能够保留多少个类，如果零碎定义了太多的类，导致办法区溢出，虚拟机同样会抛出内存溢出谬误：java.lang.OutOfMemoryError: PermGen space 或者 java.lang.OutOfMemoryError: Metaspace
  • 加载大量的第三方的jar包；Tomcat部署的工程过多（30-50个）；大量动静的生成反射类

  • 敞开JVM就会开释这个区域的内存。

    HotSpot中办法区的演进

    在jdk7及以前，习惯上把办法区，称为永恒代。jdk8开始，应用元空间取代了永恒代。

    实质上，办法区和永恒代并不等价。仅是对hotspot而言的。《Java虚拟机标准》对如何实现办法区，不做对立要求。例如：BEA JRockit/ IBM J9中不存在永恒代的概念。

当初来看，当年应用永恒代，不是好的idea。导致Java程序更容易OOM（超过-XX:MaxPermSize下限）


而到了JDK 8，终于齐全废除了永恒代的概念，改用与JRockit、J9一样在本地内存中实现的元空间（Metaspace）来代替

元空间的实质和永恒代相似，都是对JVM标准中办法区的实现。不过元空间与永恒代最大的区别在于：元空间不在虚拟机设置的内存中，而是应用本地内存。
永恒代、元空间二者并不只是名字变了，内部结构也调整了。
依据《Java虚拟机标准》的规定，如果办法区无奈满足新的内存调配需要时，将抛出OOM异样。

设置办法区的参数

设置办法区内存的大小

办法区的大小不用是固定的，jvm能够依据利用的须要动静调整。

jdk7及以前：

通过-XX:PermSize来设置永恒代初始调配空间。默认值是20.75M
-XX:MaxPermSize来设定永恒代最大可调配空间。32位机器默认是64M，64位机器模式是82M
当JVM加载的类信息容量超过了这个值，会报异样OutOfMemoryError:PermGen space 。

jdk8及当前：

元数据区大小能够应用参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定,代替上述原有的两个参数。

默认值依赖于平台。windows下，-XX:MetaspaceSize是21M，-XX:MaxMetaspaceSize 的值是-1，即没有限度。

与永恒代不同，如果不指定大小，默认状况下，虚构机会耗尽所有的可用零碎内存。如果元数据区产生溢出，虚拟机一样会抛出异样OutOfMemoryError: Metaspace
-XX:MetaspaceSize：设置初始的元空间大小。对于一个64位的服务器端JVM来说，其默认的-XX:MetaspaceSize值为21MB。

这就是初始的高水位线，一旦涉及这个水位线，Full GC将会被触发并卸载没用的类（即这些类对应的类加载器不再存活），而后这个高水位线将会重置。新的高水位线的值取决于GC后开释了多少元空间。如果开释的空间有余，那么在不超过MaxMetaspaceSize时，适当进步该值。如果开释空间过多，则适当升高该值。

如果初始化的高水位线设置过低，上述高水位线调整状况会产生很屡次。通过垃圾回收器的日志能够察看到Full GC屡次调用。为了防止频繁地GC ，倡议将-XX:MetaspaceSize设置为一个绝对较高的值。

办法区都存什么？


《深刻了解Java 虚拟机》书中对办法区（Method Area）存储内容形容如下：

它用于存储已被虚拟机加载的类型信息、常量、动态变量、即时编译器编译后的代码缓存等。

永恒代与元空间

1.首先明确：只有HotSpot才有永恒代。

BEA JRockit、IBM J9等来说，是不存在永恒代的概念的。原则上如何实现办法区属于虚拟机实现细节，不受《Java虚拟机标准》管教，并不要求对立。

  1. HotSpot中永恒代的变动

jdk1.6及之前：有永恒代(permanent generation)

jdk1.7：有永恒代，但曾经逐渐“去永恒代”，字符串常量池、动态变量移除，保留在堆中

jdk1.8及之后： 无永恒代，类型信息、字段、办法、常量保留在本地内存的元空间，但字符串常量池仍在堆



办法区会产生GC嘛?

有些人认为办法区（如HotSpot虚拟机中的元空间或者永恒代）是没有垃圾收集行为的，其实不然。《Java虚拟机标准》对办法区的束缚是十分宽松的，提到过能够不要求虚拟机在办法区中实现垃圾收集。事实上也的确有未实现或未能残缺实现办法区类型卸载的收集器存在（如JDK 11期间的ZGC收集器就不反对类卸载）。

一般来说这个区域的回收成果比拟难令人满意，尤其是类型的卸载，条件相当刻薄。然而这部分区域的回收有时又的确是必要的。以前Sun公司的Bug列表中，曾呈现过的若干个重大的Bug就是因为低版本的HotSpot虚拟机对此区域未齐全回收而导致内存透露。

办法区的垃圾收集次要回收两局部内容：常量池中废除的常量和不再应用的类型。

跪求三连

码字不易，还请点个赞和珍藏~