JVM理论（四）运行时数据区--堆／方法区
堆(heap)
堆内存逻辑上分为三部分
- 一个JVM实例只存在一个堆内存,JVM启动时创建堆区，通常情况下也是最大的内存空间，几乎所有的对象实例都要在堆中分配内存，所以堆也是垃圾回收的重点区域
- 堆是被所有线程共享的,在堆里面也可以划分线程私有的缓冲区(TLAB-Thread Local Allocation Buffer)
- 栈是JVM运行时的单位，堆是存储单位，当栈中方法结束，相关对象失去所有引用后，不会马上被移除堆空间，必须等到垃圾收集器执行的时候才会被移除
- JVM中的java对象可以划分两类
- 生命周期较短的瞬时对象,这类对象创建和消亡非常迅速(称为新生代)
- 生命周期比较长,有时可能与JVM的生命周期一致(称为老年代)
新生代
新生代用来存放新生的对象，而且80%的对象都谁朝生夕死。由于频繁创建对象，所以新生代会频繁触发MinorGC 进行垃圾回收(默认内存大小是新生代:老年代=1:2);新生代又分为 Eden 区、Survivor From、SurvivorTo三个区域(三者内存大小默认是8:1:1)
Eden 区
Java 新对象的出生地.当 Eden 区内存不足时会触发 MinorGC/YGC,然后对新生代区进行一次垃圾回收
Survivor区
Survivor From用于存储上一次MinorGC的幸存者，作为下一次 GC 的被扫描者。而Survivor To则是为了保留下一次 MinorGC 过程中的幸存者
老年代
老年代主要存放应用程序中生命周期长的内存对象,老年代的对象比较稳定，所以不会频繁执行MajorGC/FGC
Java对象在JVM堆内存分配
一般分配过程
- 新new的对象首先进入Eden区,Eden区有大小限制;
- 当Eden的空间不足存放新创建的对象时,JVM会进行垃圾回收(即Minor GC/YGC),将不再被引用的对象进行回收销毁,并将未被回收的对象放到Survivor From区;
- 若再次触发Minor GC,在回收Eden区的同时,也会对Survivor From区进行回收,如果Survivor From中幸存下来的仍然没有回收,会同Eden未被回收的对象一同放到Survivor To区(此后作为Survivor From区),并清空Eden和Survivor From区;
- 若再进行YGC,则会再次回收Eden和Survivor From区,将幸存对象放到Survivor To区
- 正常来说,当Survivor 区的对象年龄达到默认15时,会晋升到老年代
- 当老年代内存空间不足时,会触发Major GC/FGC进行老年代区域的垃圾回收
- 若Major GC之后仍然无法存放新创建的对象,就会产生OOM异常(java.lang.OutOfMemoryError:Java Heap Spece)
特殊分配过程
- 当新创建的对象无法存放在已经经过YGC的Eden区时，直接存放到老年代
- 当经过YGC后Survivor 区也无法存放幸存的对象,也会直接放到老年代
总结
- survivor区在复制后进行交换，谁空间为空谁就是survivor To;
- 新生代会频繁进行垃圾回收,老年代很少进行垃圾回收,方法区/永久代几乎不进行垃圾回收
扩展
1.查看堆内存设置的参数情况
- jps -l => jstat -gc 进程id
- -XX:+PrintGCDetails
2.空间分配担保
JDK7规定在发生YGC之前,虚拟机会检查老年代最大可用连续空间是否大于新生代所有对象的总空间,只要老年代的连续空间大于新生代对象总大小或者历次晋升的对象平均大小就会进行YGC，否则就进行FGC
3.逃逸分析(堆不再是分配对象存储的唯一选择）
不是;在JVM中,对象是在java堆中分配内存是普遍的常识,但是有一种特殊情况就是如果经过逃逸分析后发现,一个对象没有逃逸出方法的话,那么会被优先分配在栈上,这样就无需分配在堆上以至于垃圾回收,这也是最常见的堆外存储技术。
逃逸分析就是分析对象动态作用域
- 当对象在方法中被定义后,只在方法内部使用,则认为没有发生逃逸,则可以被分配到栈上,随着方法执行结束,栈空间被移除。
- 当对象在方法中被定义后,被外部方法所引用,则认为发生了逃逸,例如作为调用参数传递到其他地方使用。
所以在开发过程中,在方法内部定义的局部变量,不要在方法外定义;目前在JDK7后,Hotspot已经默认开启了逃逸分析。
方法区
堆栈方法区关系
概述
- 方法区也称为Non-heap非堆,目的就是和堆分开;所以方法区也可以看作一块独立于Java堆的内存空间
- 方法区和堆一样,是各个线程共享的内存区域
- 方法区在JVM启动被创建，在JVM关闭时释放
- 方法区大小决定系统可以保存多少类,类过多可能导致方法区溢出，虚拟机会报内存溢出错误，如：java.lang.OutOfMemoryError:PermGen/Metaspace
- 方法区演进：JVM规范定义了方法区,针对Hotspot的实现,Jdk7以及以前,方法区被称为永久代;JDK8开始,改用和JRocket,J9一样在本地内存中实现的元空间来代替永久代;
- 方法区的垃圾回收的主要内容:常量池中废弃的常量和不再使用的类型信息
内部结构
JVM虚拟机规范中规定方法区中用于存储被JVM虚拟机加载的类型信息、常量、静态变量、JIT编译后的代码缓存等
对于每个加载的类型(类、接口、枚举、注解),JVM必须在方法区中存储以下类型信息、域信息、方法信息
-
类型信息
- 类型的完整有效名称(包名.类名);
- 类型的直接父类的完整有效名;
- 类型的修饰符(Public,abstract,final);
- 类型直接接口的一个有序列表
-
域(Field)/属性信息
- 域名称
- 域类型
- 域修饰符(Public、private、protected等)
-
方法信息
-
方法名称
-
方法返回类型
-
方法参数数量和类型
-
方法修饰符
-
方法字节码、操作数栈、局部变量表及大小
-
异常表
-
运行时常量池
首先被编译后的class字节码文件中存在常量池的引用,当字节码被加载到内存的方法区后,被称为运行时常量池，它的作用就是将经常使用到的数据存储在常量池，方便取用,动态链接会使用到运行时常量池,其中存储内容包括
- 数量值
- 字符串值
- 类引用
- 字段引用
- 方法引用
方法区实现的演进过程
- JDK1.6及以前：存在永久代,静态变量存放在永久代之中
- JDK1.7: 有永久代,但逐步"去永久代",其中字符串常量池和静态变量已经从永久代移除,并将其保存在堆中
- 字符串常量池StringTable为什么要从方法区中调整到堆中？
JDK7将StringTable放到了堆空间中,因为永久代的回收效率很低;只有在老年代空间不足或者永久代空间不足时发生FGC时才会回收StringTable,就导致StringTable回收效率低,而我们开发中会有大量的字符串被创建,回收效率低最终导致永久代内存不足,而放到堆里则能及时回收内存
- 字符串常量池StringTable为什么要从方法区中调整到堆中？
- JDK1.8及以后：无永久代,元空间代替永久代(元空间本质和永久代类似,都是JVM规范中方法区的实现,区别在于元空间不在虚拟机设置的内存中,而是使用本地内存),且字符串常量池和静态变量仍在堆中
常见的JVM参数设置
-X是JVM的运行参数
-Xms：设置堆内存初始大小(新生代+老年代),默认电脑物理内存/64
-Xmx：设置堆内存最大内存大小,默认电脑物理内存/4
-XX:SurvivorRation=8,作用是将新生代的Eden与另两个Survivor区域占比比例设置为8:1:1
-Xmn:设置新生代空间大小(一般优先级高于NewRatio,但通常开发中不作设置)
-XX:NewRatio=2,堆内存中年轻代:老年代=1:2(开发中通常不作调整)
-XX: MaxTenuringThreshold=
-XX:+PrintFlagsInitial 启用查看所有参数的默认初始值
-XX:+PrintFlagsFinal 启用查看所有参数的最终值
-XX:+PrintGCDetails 输出详细的GC处理日志
-XX:HandlePromotionFailure 是否设置空间分配担保
-XX: PermSize 用于JDK8以前设置永久代初始分配空间,默认20.75M
-XX: MaxPermSize 用于JDK8以前设置永久代最大可分配空间,32位默认64M,64位默认82M
-XX: MetaspaceSize 用于JDK8及以后设置永久代初始分配空间,默认21M(实际开发中我们会设置一个值,并且初始最大值是相同的)
-XX: MaxMetaspaceSize 用于JDK8及以后设置元空间最大空间,默认-1,表示无限制(实际开发中我们会设置一个值,并且初始最大值是相同的)
常见问题
堆空间大小设置时，为何-Xms和-Xmx两个参数要设置相同的值？
目的是为了能够在GC清理完堆内存后不需要重新分隔计算堆区大小，减少系统压力从而提高性能
为什么需要把Java堆分代,不分带就不能正常工作了吗？
完全可以不分代,分代的唯一理由就是优化GC性能;
如果没有分代,所有的对象都在一起,GC的时候需要分析哪些对象没用,此时就需要对堆的所有区域进行扫描,占用资源且时间长;而我们知道,其实很多对象都是朝生夕死的,
如果分代的话,把新创建的对象放到一个区域,当GC时会首先对此区域进行回收,释放空间。而长期存活的对象放到另一个区域,且不会频繁进行回收,这样各个区域各司其职,提高资源利用.
为什么在堆里面设置线程私有的缓冲区TLAB？
首先堆区是线程共享区域,任何线程都可以访问到堆区中的共享数据,所以会产生线程安全问题.为了避免多个线程操作同一地址,需要使用加锁等机制，但加锁又会影响分配进度;
所以出现了TLAB,JVM会为每个线程分配一个私有缓存区域TLAB,它被分配在Eden区域;这样多线程在运行时会避免线程安全问题;
- OpenJDK目前都提供了对TLAB的设计
- TLAB空间内存非常小,仅占整个Eden空间的1%;
- 不是所有对象都可以在TLAB中成功分配内存,一旦分配失败,JVM就会尝试通过使用加锁机制确保操作原子性,从而在Eden中分配内存