方法区(上)
栈、堆、方法区的交互关系
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文件常量池的另一重要特征是:具备动态性。