方法区（上）

栈、堆、方法区的交互关系

new出来的那个 new XX都是存放在堆中。
Person这个类则被存放到方法区中
person这个对象则放在栈中。

---

方法区的理解

方法区看作是一块独立于堆的内存空间

方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区
溢出,虚拟机同样会抛出内存溢出错误:java.lang. OutofMemoryError:PermGen space 或者 java. lang. OutofMemoryError: Metaspace

• 加载大量的第三方的jar包; Tomcat部署的工程过多(30-50个)大量动态的
  生成反射类就可能会导致OOM
• 关闭JVM就会释放这个区域的内存。

Hotspot中方法区的演进
JDK7之前把方法区称为永久代，JDK8开始就使用元空间 替代了永久代。
本质上 永久代和方法区并不是等价的，只是在Hotspot中这么说。
例如 IBM J9中不存在永久代的概念

元空间和永久代的区别

元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久
代最大的区别在于元空间不在虚拟机设置的内存中,而是使用本地内存。
永久代、元空间二者并不只是名字变了,内部结构也调整了。
根据《Java虚拟机规范》的规定,如果方法区无法满足新的內存分配需求时,将
抛出OOM异常。

设置方法区大小与OOM

设置方法区大小

JDK7以及之前：


JDK8及以后：


与永久代不同,如果不指定大小,默认情况下,虚拟机会耗尽所有的可用系统内存。
如果元数据区发生溢出,虚拟机一样会抛出异常 OutofmemoryError: Metaspace

如何解决OOM

1、要解决OOM异常或 heap space的异常,一般的手段是首先通过内存映像分析工具
对dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏( Memory Leak)还是内存溢出( Memory OverfloW)。

内存泄露：存在引用指向堆中的对象，但是后续却用不上这个对象了，导致GC无法回收该对象。
内存溢出：指程序运行过程中无法申请到足够的内存而导致的一种错误

2、如果是内存泄漏,可进一步通过工具查看泄漏对象到 GC Roots的引用链(即指向关系)。
掌握了泄漏对象的类型信息,以及 GC Roots引用链的信息,就可以比较准确地定位出泄漏代码的位置。

3、如果不存在内存泄漏,换句话说就是内存中的对象确实都还必须存活着,那就应当
检查虚拟机的堆参数(-Xmx与-Xms),与机器物理内存对比看是否还可以调大,从代码上检査是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。

方法区的内部结构

存储的东西

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

类型信息：

域信息

方法信息

non-final的类变量

常量池和运行时常量池

字节码文件内部包含了常量池，方法区内部包含了运行时常量池。

一个有效的字节码文件中除了包含类的版本信息、字段、方法以及接口等描述信息外,还包含一项信息那就是常量池表( Constant poo1 Table),包括各种字面量和对类型、域和方法的符号引用

为什么需要常量池？

一个java源文件中的类、接口,编译后产生一个字节码文件。而Java中的字节码需要数据
支持,通常这种数据会很大以至于不能直接存到字节码里,换另一种方式,可以存到常量池
这个字节码包含了指向常量池的引用。在动态链接的时候会用到运行时常量池。

比如：

public class hi{
public void hi(){
System.out.Println("nihao");
}

}

虽然只有短短几行代码但是却用到了很多结构，代码量大一点这些结构会更复杂，更多，这个时候就需要用到常量池了。

---

小结:
常量池,可以看做是一张表,虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等类型。

运行时常量池

• 运行时常量池是方法区的一部分。
• 常量池表( Constant pool Table)是class文件的一部分,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。
• 在加载类和接口到虚拟机后,就会创建对应的运行时常量池。
• JVM为每个已加载的类型(类或接口)都维护一个常量池。池中的数据项像数组项一样,是通过索引访问的。
• 运行时常量池中包含多种不同的常量,包括编译期就已经明确的数值字面量,也包括到运行期解析后才能够获得的方法或者字段引用。
• 运行时常量池,相对于 Class文件常量池的另一重要特征是:具备动态性。