文章目录
Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区,其中有一些会随着虚拟机启动而创建,随着虚拟机退出而销毁。
另外一些则是与线程一一对应的,这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。
运行时数据区域包括
- 程序计数寄存器
- 虚拟机栈
- 本地方法栈
- 堆
- 方法区
其中:方法区、堆为线程共享;程序计数寄存器、虚拟机栈、本地方法栈 为线程私有。
方法区
对于方法区的理解
尽管所有的方法区在逻辑上是属于堆的一部分,但一些简单的实现可能不会选择去进行垃圾收集或者进行压缩。
”但对于HotSpotJVM而言,方法区还有一个别名叫做Non-Heap(非堆),目的就是要和堆分开。
方法区看作是一块独立于Java堆的内存空间。下图说明了栈、堆、方法区的交互关系
- 方法区主要存放的是 class,而堆中主要存放的是实例化的对象.
- 方法区与Java堆一样,是各个线程共享的内存区域。
- 方法区在JVM启动的时候被创建,并且它的实际的物理内存空间中和Java堆区一样都可以是不连续的。
- 方法区的大小,跟堆空间一样,可以选择固定大小或者可扩展。
- 方法区的大小决定了系统可以保存多少个类,如果系统定义了太多的类,导致方法区溢出,
虚拟机同样会抛出内存溢出错误:java.lang.OuOfMemoryError:PermGen space
或者java.lang.OutOfMemoryError:Metaspace
- 关闭JVM就会释放这个区域的内存。
HotSpot中JDK7与JDK8
在JDK7及以前,习惯上把方法区,称为永久代。JDK8开始,使用元空间取代了永久代。
JDK 1.8后,元空间存放在直接内存中。
元空间的本质和永久代类似,都是对JVM规范中方法区的实现。不过元空间与永久代最大的区别在于:元空间不在虚拟机设置的内存中,而是使用本地内存。
永久代、元空间二者并不只是名字变了,内部结构也调整了。
根据《Java虚拟机规范》的规定,如果方法区无法满足新的内存分配需求时,将抛出OOM异常。
设置方法区大小
方法区的大小不必是固定的,JVM可以根据应用的需要动态调整。
JDK7及之前
通过参数-XX:Permsize=size
来设置永久代初始分配空间。默认值是20.75M;
通过参数-XX:MaxPermsize=size
来设定永久代最大可分配空间。32位机器默认是64M,64位机器模式是82M;
当JVM加载的类信息容量超过了这个值,会报OuOfMemoryError:PermGen space
异常。
JDK8及之后
元空间大小可以使用参数 -XX:MetaspaceSize=size
和 -XX:MaxMetaspaceSize=size
来指定。
默认值依赖于平台。windows下,-XX:MetaspaceSize
是21M,-XX:MaxMetaspaceSize
的值是-1,由于直接存放在直接内存中所以没有限制。
与永久代不同,如果不指定大小,默认情况下,虚拟机会耗尽所有的可用系统内存。如果元数据区发生溢出,虚拟机一样会抛出异常OutOfMemoryError:Metaspace
。
-XX:MetaspaceSize=size
设置初始的元空间大小。对于一个64位的服务器端JVM来说,其默认的-XX:MetaspaceSize
值为21MB。
这就是初始的高水位线,一旦触及这个水位线,Ful1GC将会被触发并卸载没用的类即这些类对应的类加载器不再存活然后这个高水位线将会重置。新的高水位线的值取决于GC后释放了多少元空间。
如果释放的空间不足,那么在不超过MaxMetaspaceSize
时,适当提高该值。如果释放空间过多,则适当降低该值。
如果初始化的高水位线设置过低,上述高水位线调整情况会发生很多次。
通过垃圾回收器的日志可以观察到FullGC多次调用。
为了避免频繁地GC,建议将-XX:MetaspaceSize=size
设置为一个相对较高的值。
OOM
JDK8 方法区/元空间 OOM代码演示
设置虚拟机参数
-XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m
public class MainTest extends ClassLoader{
public static void main(String[] args) {
MainTest mainTest = new MainTest();
int count = 0;
try {
for (int i = 0; i < 1000; i++) {
ClassWriter classWriter = new ClassWriter(0);
classWriter.visit(Opcodes.V1_8,Opcodes.ACC_PUBLIC ,"Class" + i,null,"java/lang/Object",null);
byte[] bytes = classWriter.toByteArray();
mainTest.defineClass("Class" + i, bytes, 0, bytes.length);
count ++;
}
}finally {
System.out.println(count);
}
}
}
如何解决OOM?
-
1.要解决ooM异常或heap space的异常,一般的手段是首先通过内存映像分析工具(如Ec1ipse Memory Analyzer)对dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏(Memory Leak)还是内存溢出(Memory Overflow).
-
2.如果是内存泄漏,可进一步通过工具查看泄漏对象到GC Roots的引用链。
于是就能找到泄漏对象是通过怎样的路径与GCRoots相关联并导致垃圾收集器无法自动回收它们的。
掌握了泄漏对象的类型信息,以及GCRoots引用链的信息,就可以比较准确地定位出泄漏代码的位置。内存泄漏: 有大量的引用指向某些对象,但是这些对象以后不会使用了,但是因为它们还和GC ROOT有关联,所以导致以后这些对象也不会被回收。
-
3.如果不存在内存泄漏,换句话说就是内存中的对象确实都还必须存活着,那就应当检查虚拟机的堆参数(-Xmx与-Xms),
与机器物理内存对比看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。
方法区的内部结构
方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
展示方法区内部结构,演示代码
public class MainTest {
private String string = "awsl";
public static void context() {
try {
int a = 0;
int b = 20/a;
}catch (Exception e) {
e.printStackTrace();
}
}
private String context2() {
return string;
}
public static void main(String[] args) {
new MainTest().context2();
context();
}
}
编译该类,找到该类的class文件,打开终端执行javap -v MainTest.class > test.txt
命令,在当前目录会生成test.txt
文件.
打开即可查看反编译后的字节码信息。
类型信息
对每个加载的类型(类class、接口interface、枚举enum、注解annotation),Jvm必须在方法区中存储以下类型信息:
- 这个类型的完整有效名称(包名.类名)
- 这个类型直接父类的完整有效名(对于interface或是java.lang.object,都没有父类)
- 这个类型的修饰符(public,abstract,final的某个子集)
- 这个类型直接接口的一个有序列表
// ...
public class content.posts.jvm.MainTest
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
//...
域信息
JVM必须在方法区中保存类型的所有域的相关信息以及域的声明顺序。
域的相关信息包括:域名称、域类型、域修饰符(public,private,protected,static,final,volatile,transient的某个子集)
// ...
Constant pool:
#1 = Methodref #10.#35 // java/lang/Object."<init>":()V
#2 = String #36 // awsl
#3 = Fieldref #6.#37 // content/posts/jvm/MainTest.string:Ljava/lang/String;
// ...
方法信息
JVM必须保存所有方法的以下信息,同域信息一样包括声明顺序:
- 方法名称
- 方法的返回类型(或void)
- 方法参数的数量和类型(按顺序)
- 方法的修饰符(
public,private,protected,static,final,synchronized,native,abstract
的一个子集) - 方法的字节码(
bytecodes
)、操作数栈、局部变量表及大小(abstract和native
方法除外) - 异常表(
abstract和native
方法除外)
每个异常处理的开始位置、结束位置、代码处理在程序计数器中的偏移地址、被捕获的异常类的常量池索引
public static void context();
descriptor: ()V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=2, args_size=0
0: iconst_0
1: istore_0
2: bipush 20
4: iload_0
5: idiv
6: istore_1
7: goto 15
10: astore_0
11: aload_0
12: invokevirtual #5 // Method java/lang/Exception.printStackTrace:()V
15: return
// 异常表
Exception table:
from to target type
0 7 10 Class java/lang/Exception
// 代码字节码指令行号对照表
LineNumberTable:
line 11: 0
line 12: 2
line 15: 7
line 13: 10
line 14: 11
line 16: 15
// 局部变量表
LocalVariableTable:
Start Length Slot Name Signature
2 5 0 a I
11 4 0 e Ljava/lang/Exception;
StackMapTable: number_of_entries = 2
frame_type = 74 /* same_locals_1_stack_item */
stack = [ class java/lang/Exception ]
frame_type = 4 /* same */
non-final的类变量
静态变量和类关联在一起,随着类的加载而加载,他们成为类数据在逻辑上的一部分。
类变量被类的所有实例共享,即使没有类实例时,也可以访问它:
public class MainTest {
public static void main(String[] args) {
Test test = null;
// 相当于 Test.hello();
test.hello();
// Test.count;
System.out.println(test.count);
}
}
class Test {
public static int count = 1;
public static final int number = 2;
public static void hello() {
System.out.println("hello!");
}
}
全局常量就是使用 static final 进行修饰
被声明为final的类变量的处理方法则不同,每个全局常量在编译的时候就会被分配了。
运行时常量池
字节码指令解析
代码如下
public class MethodAreaDemo {
public static void main(String args[]) {
int x = 500;
int y = 100;
int a = x / y;
int b = 50;
System.out.println(a+b);
}
}
反编译后该方法字节码指令
// ....
// 栈的最大深度为3 局部变量表长度为5 参数长度为1
stack=3, locals=5, args_size=1
// 将500压入操作数栈
0: sipush 500
// 在局部变量表里存放 500
3: istore_1
// 将100压入栈
4: bipush 100
// 在局部变量表里存放 100
6: istore_2
// 将 500 从局部变量表里边取出,并压入操作数栈
7: iload_1
// 将 100 从局部变量表里边取出,并压入操作数栈
8: iload_2
// 调用 CPU 执行除法 500/100=5
9: idiv
// 存储在局部变量表里
10: istore_3
// 将50压入栈中
11: bipush 50
// 将 50 存储在局部变量表中
13: istore 4
// 获取 #2 地址上类或接口字段的值并将其推入操作数栈
15: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
// 将 5 从本地变量表取出放到栈中
18: iload_3
// 将50从本地变量表,压入栈
19: iload 4
// 调用cpu执行加法 5 + 50=55
21: iadd
// 虚方法调用 #3 中的方法
// JVM会根据这个方法的描述,创建新的栈桢,方法的参数从操作数栈中弹出来,压入虚拟机栈,然后虚拟机会开始执行虚拟机栈上最上面的栈桢
22: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
// void 类型返回 main方法执行结束
25: return
// ...
方法区演进细节
要注意只有Hotspot
才有永久代(方法区具体实现)。BEA JRockit、IBMJ9
等来说,是不存在永久代的概念的。
Hotspot中方法区的变化
JDK版本 | 方法区变化 |
---|---|
JDK1.6及以前 | 有永久代,字符串常量池、静态变量存储在永久代上 |
JDK1.7 | 有永久代,但已经逐步 “去永久代”,字符串常量池,静态变量移除,保存在堆中 |
JDK1.8 | 无永久代,类型信息,字段,方法,常量保存在本地内存的元空间,但字符串常量池、静态变量仍然在堆中 |
为什么永久代要被元空间替代
根据官方的解释:替代是JRockit
和HotSpot
融合后的结果,因为JRockit
没有永久代,所以hotspot
用元空间替代了永久代。
由于类的元数据分配在本地内存中,元空间的最大可分配空间就是系统可用内存空间,这项改动是很有必要的,原因有:
-
1.为永久代设置空间大小是很难确定的。
在某些场景下,如果动态加载类过多,容易产生永久代的OOM。比如某个实际Web工程中,因为功能点比较多,在运行过程中,要不断动态加载很多类,经常出现致命错误。而元空间和永久代之间最大的区别在于:元空间并不在虚拟机中,而是使用本地内存。 因此,默认情况下,元空间的大小仅受本地内存限制。 -
2.对永久代进行调优是很困难的。
因为FullGC的花费时间是MinorGC的10倍左右,所以我们可以降低GC的频率,尽量不让方法区执行GC来提高效率。
方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不在使用的类型。
字符串常量池为什么要调整位置
JDK7中将StringTable
放到了堆空间中。因为对永久代的回收效率很低,只有在Full GC的时候才会触发。
Full GC 是老年代的空间不足、永久代不足时才会触发。
这就导致StringTable
回收效率不高。而我们开发中会有大量的字符串被创建,回收效率低,导致永久代内存不足。
所以JDK7之后将字符串常量池放到堆里,能及时回收内存,避免出现错误。
方法区的垃圾回收
有些人认为JVM的方法区(如 Hotspot 虚拟机中的元空间或者永久代)是没有垃圾收集行为的,其实不然。
《Java虚拟机规范》对方法区的约束是非常宽松的,提到过可以不要求虚拟机在方法区中实现垃圾收集。
事实上也确实有未实现或未能完整实现方法区类型卸载的收集器存在(如JDK11时期的ZGC收集器就不支持类卸载)。
一般来说这个区域的回收效果比较难令人满意,尤其是类型的卸载,条件相当苛刻。但是这部分区域的回收有时又确实是必要的。
以前sun公司的Bug列表中,曾出现过的若干个严重的Bug就是由于低版本的HotSpot虚拟机对此区域未完全回收而导致内存泄漏。
方法区的垃圾收集主要回收两部分内容:常量池中废弃的常量和不再使用的类型。
HotSpot虚拟机对常量池的回收策略是很明确的,只要常量池中的常量没有被任何地方引用,就可以被回收。
判定一个常量是否“废弃”还是相对简单,而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。
需要同时满足下面三个条件:
-
1.该类所有的实例都已经被回收,也就是Java堆中不存在该类及其任何派生子类的实例。
加载该类的类加载器已经被回收,这个条件除非是经过精心设计的可替换类加载器的场景,如osGi、JSP的重加载等,否则通常是很难达成的。 -
2.该类对应的
java.lang.C1ass
对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。 -
3.加载该类的类加载器已经被回收,这个条件除非是经过精心设计可替换类加载器的场景,如JSP、OSGi,否则通常很难达成。
Java虚拟机被允许对满足上述三个条件的无用类进行回收,这里说的仅仅是“被允许”,而并不是和对象一样,没有引用了就必然会回收。
关于是否要对类型进行回收,HotSpot虚拟机提供了-Xnoclassgc
参数进行控制,还可以使用-verbose:class
以及 -XX:+TraceClass-Loading、-XX:+TraceClassUnLoading
查看类加载和卸载信息。
在大量使用反射、动态代理、CGLib等字节码框架,动态生成JSP以及OSGi这类频繁自定义类加载器的场景中,
通常都需要Java虚拟机具备类型卸载的能力,以保证不会对方法区造成过大的内存压力。
符号引用
符号引用是编译原理中的概念,是相对于直接引用来说的。主要包括了以下三类常量:
- 类和接口的全限定名
- 字段的名称和描述符
- 方法的名称和描述符
符号引用 :符号引用以一组符号来描述所引用的目标。
符号引用可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可,符号引用和虚拟机的布局无关。
在编译的时候每个java类都会被编译成一个class文件,但在编译的时候虚拟机并不知道所引用类的地址,所以就用符号引用来代替,
而在这个解析阶段就是为了把这个符号引用转化成为真正的地址的阶段。
字面量
在计算机科学中,字面量(literal)是用于表达源代码中一个固定值的表示法(notation)。
几乎所有计算机编程语言都具有对基本值的字面量表示,诸如:整数、浮点数以及字符串;
而有很多也对布尔类型和字符类型的值也支持字面量表示;
还有一些甚至对枚举类型的元素以及像数组、记录和对象等复合类型的值也支持字面量表示法。