堆栈和方法区的交互关系
从线程是否共享的角度来看
方法区在哪里?
Java 虚拟机规范中明确说明: 尽管所有的方法区在逻辑上是属于堆的一部分,但是一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。 但是对于HotSpotJVM而言,方法区还有一个别名叫做 Non-Heap (非堆),目的就是要和堆分开
方法区的基本理解
- 方法区(Method Area) 与Java 堆一样,是各个线程共享的内存区域
- 方法区在JVM启动的时候被创建,并且他的实际物理内存和JAVA堆区一样都可以是不连续的
- 方法区的大小,跟堆空间一样,可以选择固定大小或者可拓展
- 方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区溢出,虚拟机同样会抛出内存溢出错误: java.lang.OutOfMemoryuError:PereGen space 或者 java.lang.OutOfMemoryError: Metaspcae
- 关闭JVM 就会释放这个区域的内存
- 在jdk7及以前,习惯上把方法区称为永久代,jdk8开始,使用了元空间取代了永久代。
- 本质上,方法区和永久代并不等价,仅仅是对Hotspot而言的。Java虚拟机规范对如何实现方法区,不做统一要求。比如 JRockit 和 J9 中不存在永久代的概念。
- 现在来看,当年使用永久代,不是好的idea。导致了JAVA程序更容易OOM。超出 -XX:MaxPermSize
- 而到了JDK8,终于完全废弃了永久代的概念,改用JRockit 和 J9一样在本地内存中实现的元空间(Metaspace) 来代替
- 元空间的本质和永久代类似,都是对JVM规范中方法区的实现,不过元空间与永久代的最大区别在于,元空间不在虚拟机设置的内存中,而是使用了物理机的本地内存
- 永久代和元空间二者并不只是名字改变了,而是内部结构也做了调整
- 根据JAVA虚拟机规范的规定,如果方法区无法满足新的内存分配的需求时,将抛出OOM异常
设置方法区内存的大小
- 方法区的大小不必是固定的,jvm可以根据应用需要动态调整
- jdk7 以前:
通过-XX:PermSize来设置永久代初始分配空间。默认值是 20.75M
-XX:MaxPermSize来设定永久代最大可分配空间。32位机器默认是64M,64位机器默认是82M
- 当JVM加载的类信息容量超过了这个值,会报 OutOfMemoryError:PermGenspace
- jdk8 之后:
- 元数据区大小可以使用参数
-XX:MetaspcaeSize和-XX:MaxMetaspaceSize
指定,替代上述原有的两个参数 - 默认值依赖于windows下,-XX:MetaspaceSize是 21M, -XX:MaxMetaspaceSize是 -1, 即使没有限制
- 与永久代不同,如果不指定大小,默认情况下,虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出,虚拟机会抛出异常OutOfMemoryError:Metaspace
- -XX:MetaspaceSize: 设置初始的元空间大小,对于一个64位的服务器端JVM来说,某默认的-XX:MetaspaceSize值为21MB,这就是初始的高水位线,一旦触及这个水位线,FullGC会被触发并卸载所有没用的类,(即这些类对应的类加载器不在存活),然后这个高水位线会被将至,新的高水位线的值取决于GC之后释放了多少元空间。,如果释放的空间不足,那么在不超过MaxMetaspaceSize时,适当提高该值,如果释放的空间过多,则适当降低该值。
- 如果初始化的高水位线设置过低,上述高水位线调整情况会发生很多次,通过垃圾回收期的日志可以观察到FullGC多次调用。为了频繁的GC,建议将-XX:MetaspaceSize设置一个相对较高的值。
- 元数据区大小可以使用参数
方法区的内部结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ovaxtY8A-1591362854790)(D:/Backup/%E6%88%91%E7%9A%84%E6%96%87%E6%A1%A3/My%20Pictures/Saved%20Pictures/方法区结构.png)]
<<深入理解JAVA虚拟机>>书中堆方法区 存储内容描述如下: 它用于存储已经被虚拟机加载的类型信息,常量,静态变量,及时编译器编译后的代码缓存等等。
类型信息
对每个加载的类型(类 class, 接口 interface, 枚举 enum, 注解 annotation) JVM必须在方法区中存储一下类型信息
- 这个类型的完整有效名称(全名= 包名.类名)
- 这个类型直接父类的完整有效名(对于 interface 或者是java.lang.Object, 都没有父类)、
- 这个类型的修饰符 (public , abstract, final 的某个子集)
- 这个类型直接接口的一个有序列表
域(Field)信息
- JVM 必须在方法区中保存类型的所有域的相关信息以及域的声明顺序
- 域的相关信息包括: 域名称,域类型,域修饰符(public , private , protected, static, fianl, volatile, transient的某个子集)
方法(Method)信息
JVM必须保存所有方法的以下信息,同域信息一样包括声明顺序:
- 方法名称
- 方法的返回类型(或者 void)
- 方法参数的数量和类型(按 顺序)
- 方法的修饰符 (public , private , protected, static, fianl, synchronized, native , abstract 的某个子集)
- 方法的字节码(bytecodes), 操作数栈, 局部变量表大小 (abstract 和 native 除外)
- 异常表 (abstract 和 native 除外)
- 每个异常处理开始的位置,结束位置,代码处理在程序计数器中偏移地址,被捕获的异常类的常量池索引
测试保存信息
需要测试的JAVA类
package cn.fllday.my.utils;
import java.io.Serializable;
/**
* @author gssznb
* @Date 2020/6/2
* @Descript:
*/
public class MethodInnerStruct extends Object implements Comparable<String>, Serializable {
private int num = 10;
private static String str = "测试方法的内部结构";
public void test1() {
int count = 20;
System.out.println("count = " + count);
}
public static int test2(int cal) {
int result = 0;
try {
int value = 30;
result = value / cal;
}catch (Exception e) {
e.printStackTrace();
}
return cal;
}
@Override
public int compareTo(String o) {
return 0;
}
}
通过javap -v -p MethodInnerStruct.class 文件得到 反编译的文件
Classfile /D:/study/my/my-admin/target/classes/cn/fllday/my/utils/MethodInnerStruct.class
Last modified 2020-6-2; size 1673 bytes
MD5 checksum 3323e989588fa83a89e3c703646dcf92
Compiled from "MethodInnerStruct.java"
public class cn.fllday.my.utils.MethodInnerStruct extends java.lang.Object implements java.lang.Comparable<java.lang.String>, java.io.Serializable
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Methodref #18.#53 // java/lang/Object."<init>":()V
#2 = Fieldref #17.#54 // cn/fllday/my/utils/MethodInnerStruct.num:I
#3 = Fieldref #55.#56 // java/lang/System.out:Ljava/io/PrintStream;
#4 = Class #57 // java/lang/StringBuilder
#5 = Methodref #4.#53 // java/lang/StringBuilder."<init>":()V
#6 = String #58 // count =
#7 = Methodref #4.#59 // java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
#8 = Methodref #4.#60 // java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
#9 = Methodref #4.#61 // java/lang/StringBuilder.toString:()Ljava/lang/String;
#10 = Methodref #62.#63 // java/io/PrintStream.println:(Ljava/lang/String;)V
#11 = Class #64 // java/lang/Exception
#12 = Methodref #11.#65 // java/lang/Exception.printStackTrace:()V
#13 = Class #66 // java/lang/String
#14 = Methodref #17.#67 // cn/fllday/my/utils/MethodInnerStruct.compareTo:(Ljava/lang/String;)I
#15 = String #68 // 测试方法的内部结构
#16 = Fieldref #17.#69 // cn/fllday/my/utils/MethodInnerStruct.str:Ljava/lang/String;
#17 = Class #70 // cn/fllday/my/utils/MethodInnerStruct
#18 = Class #71 // java/lang/Object
#19 = Class #72 // java/lang/Comparable
#20 = Class #73 // java/io/Serializable
#21 = Utf8 num
#22 = Utf8 I
#23 = Utf8 str
#24 = Utf8 Ljava/lang/String;
#25 = Utf8 <init>
#26 = Utf8 ()V
#27 = Utf8 Code
#28 = Utf8 LineNumberTable
#29 = Utf8 LocalVariableTable
#30 = Utf8 this
#31 = Utf8 Lcn/fllday/my/utils/MethodInnerStruct;
#32 = Utf8 test1
#33 = Utf8 count
#34 = Utf8 test2
#35 = Utf8 (I)I
#36 = Utf8 value
#37 = Utf8 e
#38 = Utf8 Ljava/lang/Exception;
#39 = Utf8 cal
#40 = Utf8 result
#41 = Utf8 StackMapTable
#42 = Class #64 // java/lang/Exception
#43 = Utf8 MethodParameters
#44 = Utf8 compareTo
#45 = Utf8 (Ljava/lang/String;)I
#46 = Utf8 o
#47 = Utf8 (Ljava/lang/Object;)I
#48 = Utf8 <clinit>
#49 = Utf8 Signature
#50 = Utf8 Ljava/lang/Object;Ljava/lang/Comparable<Ljava/lang/String;>;Ljava/io/Serializable;
#51 = Utf8 SourceFile
#52 = Utf8 MethodInnerStruct.java
#53 = NameAndType #25:#26 // "<init>":()V
#54 = NameAndType #21:#22 // num:I
#55 = Class #74 // java/lang/System
#56 = NameAndType #75:#76 // out:Ljava/io/PrintStream;
#57 = Utf8 java/lang/StringBuilder
#58 = Utf8 count =
#59 = NameAndType #77:#78 // append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
#60 = NameAndType #77:#79 // append:(I)Ljava/lang/StringBuilder;
#61 = NameAndType #80:#81 // toString:()Ljava/lang/String;
#62 = Class #82 // java/io/PrintStream
#63 = NameAndType #83:#84 // println:(Ljava/lang/String;)V
#64 = Utf8 java/lang/Exception
#65 = NameAndType #85:#26 // printStackTrace:()V
#66 = Utf8 java/lang/String
#67 = NameAndType #44:#45 // compareTo:(Ljava/lang/String;)I
#68 = Utf8 测试方法的内部结构
#69 = NameAndType #23:#24 // str:Ljava/lang/String;
#70 = Utf8 cn/fllday/my/utils/MethodInnerStruct
#71 = Utf8 java/lang/Object
#72 = Utf8 java/lang/Comparable
#73 = Utf8 java/io/Serializable
#74 = Utf8 java/lang/System
#75 = Utf8 out
#76 = Utf8 Ljava/io/PrintStream;
#77 = Utf8 append
#78 = Utf8 (Ljava/lang/String;)Ljava/lang/StringBuilder;
#79 = Utf8 (I)Ljava/lang/StringBuilder;
#80 = Utf8 toString
#81 = Utf8 ()Ljava/lang/String;
#82 = Utf8 java/io/PrintStream
#83 = Utf8 println
#84 = Utf8 (Ljava/lang/String;)V
#85 = Utf8 printStackTrace
{
private int num;
descriptor: I
flags: ACC_PRIVATE
private static java.lang.String str;
descriptor: Ljava/lang/String;
flags: ACC_PRIVATE, ACC_STATIC
public cn.fllday.my.utils.MethodInnerStruct();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=2, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: bipush 10
7: putfield #2 // Field num:I
10: return
LineNumberTable:
line 10: 0
line 12: 4
LocalVariableTable:
Start Length Slot Name Signature
0 11 0 this Lcn/fllday/my/utils/MethodInnerStruct;
public void test1();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=3, locals=2, args_size=1
0: bipush 20
2: istore_1
3: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
6: new #4 // class java/lang/StringBuilder
9: dup
10: invokespecial #5 // Method java/lang/StringBuilder."<init>":()V
13: ldc #6 // String count =
15: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
18: iload_1
19: invokevirtual #8 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
22: invokevirtual #9 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
25: invokevirtual #10 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
28: return
LineNumberTable:
line 16: 0
line 17: 3
line 18: 28
LocalVariableTable:
Start Length Slot Name Signature
0 29 0 this Lcn/fllday/my/utils/MethodInnerStruct;
3 26 1 count I
public static int test2(int);
descriptor: (I)I
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: iconst_0
1: istore_1
2: bipush 30
4: istore_2
5: iload_2
6: iload_0
7: idiv
8: istore_1
9: goto 17
12: astore_2
13: aload_2
14: invokevirtual #12 // Method java/lang/Exception.printStackTrace:()V
17: iload_0
18: ireturn
Exception table:
from to target type
2 9 12 Class java/lang/Exception
LineNumberTable:
line 21: 0
line 23: 2
line 24: 5
line 27: 9
line 25: 12
line 26: 13
line 28: 17
LocalVariableTable:
Start Length Slot Name Signature
5 4 2 value I
13 4 2 e Ljava/lang/Exception;
0 19 0 cal I
2 17 1 result I
StackMapTable: number_of_entries = 2
frame_type = 255 /* full_frame */
offset_delta = 12
locals = [ int, int ]
stack = [ class java/lang/Exception ]
frame_type = 4 /* same */
MethodParameters:
Name Flags
cal
public int compareTo(java.lang.String);
descriptor: (Ljava/lang/String;)I
flags: ACC_PUBLIC
Code:
stack=1, locals=2, args_size=2
0: iconst_0
1: ireturn
LineNumberTable:
line 33: 0
LocalVariableTable:
Start Length Slot Name Signature
0 2 0 this Lcn/fllday/my/utils/MethodInnerStruct;
0 2 1 o Ljava/lang/String;
MethodParameters:
Name Flags
o
public int compareTo(java.lang.Object);
descriptor: (Ljava/lang/Object;)I
flags: ACC_PUBLIC, ACC_BRIDGE, ACC_SYNTHETIC
Code:
stack=2, locals=2, args_size=2
0: aload_0
1: aload_1
2: checkcast #13 // class java/lang/String
5: invokevirtual #14 // Method compareTo:(Ljava/lang/String;)I
8: ireturn
LineNumberTable:
line 10: 0
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 this Lcn/fllday/my/utils/MethodInnerStruct;
MethodParameters:
Name Flags
o synthetic
static {};
descriptor: ()V
flags: ACC_STATIC
Code:
stack=1, locals=0, args_size=0
0: ldc #15 // String 测试方法的内部结构
2: putstatic #16 // Field str:Ljava/lang/String;
5: return
LineNumberTable:
line 13: 0
}
Signature: #50 // Ljava/lang/Object;Ljava/lang/Comparable<Ljava/lang/String;>;Ljava/io/Serializable;
SourceFile: "MethodInnerStruct.java"
当我们的.class 文件加载到方法区的时候,加载该.class文件的类加载器也会加载到方法区当中。也就是说,加载到方法区的.class 文件 会记录是哪个类加载器加载的自己,而对应的类加载器也会记录自己加载了.class 文件。
non-final 的类变量
- 静态变量和类关联在一起,随着类的加载而加载,它们成为类数据在逻辑上的一部分
- 类变量被类的所有实例共享,即使没有类实例时你也可以访问他。
补充说明:全局常量: static final
被声明为final 的类变量处理方式则不同,每个全局常量在编译的时候就会进行分配。
我们根据字节码文件来查看两种方式的区别
源Java 文件
public class FieldStaticFinal {
public static final int num1 = 10;
public static int num2 = 20;
}
仅仅只是声明了两个变量,是个使用static 声明,一个使用static final 声明,那么我们来查看字节码文件有什么不同吧
{
public static final int num1;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC, ACC_FINAL
ConstantValue: int 10
public static int num2;
descriptor: I
flags: ACC_PUBLIC, ACC_STATIC
public cn.fllday.my.utils.FieldStaticFinal();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 8: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Lcn/fllday/my/utils/FieldStaticFinal;
static {};
descriptor: ()V
flags: ACC_STATIC
Code:
stack=1, locals=0, args_size=0
0: bipush 20
2: putstatic #2 // Field num2:I
5: return
LineNumberTable:
line 12: 0
}
SourceFile: "FieldStaticFinal.java"
可以看到 num1 在编译期间就已经 赋值ConstantValue: int 10
而 num2 实在 static {} 后面进行赋值的,可以看做是一个静态代码块吧。
运行时常量池
- 方法区,内部包含了运行时常量池
- 字节码文件,结构中有一个 Constant pool 常量池。
- 要弄清楚方法区,需要理解清楚 ClassFile,因为加载类的信息都在方法区
- 要弄清楚方法区的运行时常量池,需要理解清楚ClassFile中的常量池。
- 一个有效的字节码文件中除了包含类的版本信息,字段,方法以及接口描述信息外,还包含一项信息,那就是常量表(Constant Pool Table), 包括各种字面量和对类型,域和方法的符号引用
- 可以将常量池看做一个表。虚拟机指令根据这张常量表找到需要执行的类名,方法名,参数类型,字面量等类型
几种在常量池内存储的数据类型结构包括
数量值,字符串值,类引用,方法引用,字段引用
- 运行时常量池(Runtime Constant Pool ) 是方法区的一部分
- 常量池表(Constant Pool Table) 是Class 文件的一部分,用于存放编译期生成的各种字面量与符号引用,这部分内容将在类加载后,存放到方法区的运行时常量池中。
- 运行时常量池在加载类和接口到虚拟机后,就会创建对应的运行时常量池。
- JVM 为每个已经加载的类型(类或接口)都维护一个常量池,池中的数据项像数组项一样,通过索引访问的
- 运行时常量池中包含多种不同的常量,包括编译器就已经明确的数值字面量,也包括到运行期解析后才能获得的方法或者字段引用,此时不再是常量池中的符号引用了,这里转换为真实地址。
- 运行时常量池,相对于Class文件常量池的另一重要特征是:具备动态性
- String.intern()
- 运行时常量池,相对于Class文件常量池的另一重要特征是:具备动态性
- 运行时常量池类似于传统变成语言中的符号表(Symbo table), 但是它所包含的数据却比符号表要更加丰富一些
- 当创建类或接口的运行时常量池。如果构造运行时常量池所需要的内存空间超出了方法区所能提供的最大值。则JVM会抛出OutOfMemoryError 异常。
方法区的演进细节
- 首先明确: 只有HotSpot才有永久代,JRokit,J9 来说,是不存在永久代的概念的。原则上如何实现方法区属于虚拟机实现细节。不收到Java虚拟机规范管束,并不要求统一。
- HotSpot 中方法区的变量、
- JDK1.6及以前: 有永久代,静态变量存放在永久代上
- JDK1.7: 有永久代,但已经逐步 去永久代,字符串常量池,静态变量移除,保存在堆中
- JDK1.8之后:无永久代,类型信息,字段,方法,常量保存在本地内存的元空间,但是字符串常量池静态变量仍放在堆中。
- 随着Java8的到来,HotSpot VM中再也见不到永久代了,但是这并不意味着元数据信息也消失了,这些数据被迁移到了与堆不相关的本地内存区域,这个区域叫做元空间。
- 由于类的元数据被分配到本地内存中,元空间的最大可分配空间就是系统的可用内存空间
- 这项改动的原因大概就是:
- 为永久代设置空间大小是很难确定的。
2. 在某些场景下,如果动态加载类过多,容易产生Perm的OOM,比如某个实际wweb 工程中,因为功能点比较多,在运行过程中,要不断动态加载很多类,经常出现致命错误OutOfMemoryError:PermGen space
, 而元空间和永久代最大的区别在于,元空间并不在虚拟机中,而是使用本地内存,因此在默认情况下。。元空间的大小仅受到本地内存限制。 - 对永久代进行调优是非常困难的。
- 为永久代设置空间大小是很难确定的。
- StringTable 为什么要调整。
- 因为JDK中,永久代的回收效率很低,在FullGC 的时候才会触发,而FullGC 是老年代的空间不足,了永久代不足的时候才会触发,这就导致了StringTable 回收效率不高,而我们开发中会有大量的字符串被创建,回收效率低,导致永久代内存不足,放到堆中,能及时回收内存。
方法区的垃圾回收
- 方法区内常量池中主要存放的两大常量:字面量和符号引用。字面量比较接近Java语言层次的常量概念:如文本覅穿,被声明为Final 的常量值等,而符号引用则属于编译原理纺面的概念,包括下面三种常量:
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
- HotSpot 虚拟机对常量池的回收策略是很明确的。 只要常量池中的常量没有被任何地方引用,就可以被回收
- 回收废弃常量与回收Java堆中的对象非常类似
- 判断一个常量是否废弃,还是相对比较简单,而判定一个类型是否属于“不再使用的类”的条件就比较苛刻了,需要同时满足以下三个条件
- 该类所有的实例都已经被回收,也就是Java堆中不存在该类及其任何派生子类的实例
- 加载该类的类加载器已经被回收,这个条件除非是经过精心设计的可替换类加载器的场景,如OSGi, JSP的重加载,否则通常是很难达成的。
- 该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法
- Java虚拟机被允许对满足上述三个条件的无用类进行回收,这里说仅仅是被允许,而并不是和对象一样,没有引用就必然被回收,关于是否要对类型进行回收,HotSpot虚拟机提供了 -Xnoclassgc 参数进行控制,还可以使用 -verbose:class 以及 -XX:+TraceClass-Loading , -XX:+TraceClassUnLoading 查看类加载和卸载信息
- 在大量使用反射,动态代理,CGLib等字节码框架,动态生成JSP以及OSGi这类频繁自定义类加载器的场景中,
通常都需要JAVA虚拟机具备类型卸载的能力,以保证不会对方法区造成过大的内存压力