文章目录
1. 核心概述
一个进程对应一个JVM实例,一个运行时数据区,又包含多个线程,这些线程共享了方法区和堆,每个线程包含了程序计数器,本地方法栈和虚拟机栈;
- 一个JVM实力只存在一个堆内存,堆也是Java内存管理的核心区域;
- Java堆区在JVM启动的时候即被创建,期空间大小也就确定了;堆可以说是JVM管理的最大的一块内存空间(堆的大小事可以调节的);
- 《Java虚拟机规范》规定,堆可以处于物理上不连续的空间,但是在逻辑上它应该被视为是连续的;
- 所有的线程共享Java堆,在这里还可以划分线程私有的缓冲区(TLAB:Thread Local Allocation Buffer,是线程在堆中所独有的,所以说堆空间不一定是所有线程所共享的);
- 《Java虚拟机规范》中对Java堆的描述是:所有的对象实例以及数组都应当在运行时分配在堆上;但是从实际的角度来看,“几乎”所有的对象的实例以及数组都在这里分配内存,因为它们也可能会存储在栈上;
- 数组和对象本身永远不会存储在栈上,因为栈桢中保存的是指向对象或者是数组在堆中的位置的引用;
- 在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除;
- 堆是GC(垃圾回收器)执行垃圾回收的重点区域;
1.1 配置JVM及查看JVM进程
- HeapDemo
public class HeapDemo {
public static void main(String[] args) {
System.out.println("start...");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("end...");
}
}
- 对虚拟机进行相关的配置
- 在JDK的安装目录中找到并启动jvisualvm,查看相应的进程
- 可以看到当HeapDemo的配置参数为-Xms10m时,新生代分得3M,老年代分得7M;
1.2 分析SimpleHeap的JVM情况
public class SimpleHeap {
private int id;//属性、成员变量
public SimpleHeap(int id) {
this.id = id;
}
public void show() {
System.out.println("My ID is " + id);
}
public static void main(String[] args) {
SimpleHeap sl = new SimpleHeap(1);
SimpleHeap s2 = new SimpleHeap(2);
int[] arr = new int[10];
Object[] arr1 = new Object[10];
}
}
1.3 堆的细分内存结构
- 在JDK1.7之前,堆由新生区,养老区以及永久区构成,而新生区又被分为Eden区以及Survior区;
- 在JDK1.8及之后,堆由新生区,养老区以及元空间构成,而新生区又被分为Eden区以及Survior区
2. 设置堆内存大小与OOM
-
Java堆区用于存储Java对象实例,堆的大小在JVM启动的时候就已经设定好了,可以通过 "-Xmx"和 “-Xms” 来设置
- -Xms用于表示堆空间(年轻代 + 老年代)的起始内存,等价于 -XX:InitialHeapSize:-X是JVM的运行参数,ms是memory start
- -Xmx用来设置堆空间的最大内存,等价于 -XX:MaxHeapSize
-
一旦堆区中的内存大小超过 -Xmx所指定的最大内存时,就会抛出OOM异常;
-
通常会将 -Xms 和 -Xmx 两个参数配置为相同的值,其目的就是能够在Java垃圾回收机制清理完堆区后不需要重新分割计算堆区的大小,从而提升性能;
-
默认情况下,初始内存大小为:物理内存大小/64;最大内存大小为:物理内存大小/4
- 手动设置:-Xms999m -Xmx999m
-
查看设置的参数:
- 方式一:终端输入jps,然后键入jstat -gc 进程id
- 方式二:(控制台打印)Edit Configurations -> VM Options 添加 -XX:+PrintGCDetails
2.1 查看堆内存大小
public class HeapSpaceInitial {
public static void main(String[] args) {
//返回Java虚拟机中的堆内存总量
long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
//返回Java虚拟机试图使用的最大堆内存量
long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;
System.out.println("-Xms : " + initialMemory + "M");//-Xms : 245M
System.out.println("-Xmx : " + maxMemory + "M");//-Xmx : 3641M
System.out.println("系统内存大小为:" + initialMemory * 64.0 / 1024 + "G");//系统内存大小为:15.3125G
System.out.println("系统内存大小为:" + maxMemory * 4.0 / 1024 + "G");//系统内存大小为:14.22265625G
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
2.2 堆大小分析
- 如果设置堆的大小为600m,打印出的结果为575m,这是因为幸存者区S0和S1各占据了25m,但他们始终有一个是空的,存放对象的是Eden区和一个幸存者区
2.3 OOM
- java.lang.OutOfMemoryError:Java heap space 代码示例:
/**
* -Xms600m -Xmx600m
*/
public class OOMTest {
public static void main(String[] args) {
ArrayList<Picture> list = new ArrayList<>();
while(true){
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
list.add(new Picture(new Random().nextInt(1024 * 1024)));
}
}
}
class Picture{
private byte[] pixels;
public Picture(int length) {
this.pixels = new byte[length];
}
}
3. 年轻代与老年代
-
存储在JVM中的Java对象可以被划分为两类:
- 一类是生命周期较短的瞬时对象,这类对象的创建和消亡都非常迅速;
- 另一类对象是生命周期非常长,在某些情况下还能与JVM的生命周期保持一致;
-
Java堆区进一步细分为年轻代和老年代;
-
其中年轻代又分为Eden空间,Survivor0空间和Survivor1空间(有时也叫from区,to区)
-
配置新生代与老年代在堆结构中的占比
- 默认-XX:NewRatio=2,表示老年代占整个堆的2/3;
- 可以修改-XX:NewRatio=4,表示老年代占整个堆的4/5;
-
根据规范来说,在HotSpot虚拟机中,Eden空间和另外两个Survivor空间所占的比例为8:1:1(但是实际的测试结果为6:1:1),开发人员可以通过选项 -XX:SurvivorRatio 调整空间比例,例: -XX:SurvivorRatio=8;
-
几乎所有的Java对象都是在Eden区被new出来的;
-
绝大部分的Java对象都销毁在新生代了(IBM公司的专门研究表明,新生代80%的对象都是“朝生夕死”);
-
可以使用选项 -Xmn 设置新生代最大内存大小(这个参数一般使用默认值就好了);
-
测试代码:
/**
* -Xms600m -Xmx600m
*
* -XX:NewRatio : 设置新生代与老年代的比例。默认值是2.
* -XX:SurvivorRatio :设置新生代中Eden区与Survivor区的比例。默认值是8
* -XX:-UseAdaptiveSizePolicy :关闭自适应的内存分配策略 '-'关闭,'+'打开 (暂时用不到)
* -Xmn:设置新生代的空间的大小。 (一般不设置)
*
*/
public class EdenSurvivorTest {
public static void main(String[] args) {
System.out.println("我只是来打个酱油~");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
4. 图解对象的分配过程
4.1
为新对象分配内存是一件非常严谨和复杂的任务,JVM的设计者们不仅需要考虑如何分配,在哪里分配的问题,并且由于内存分配算法与内存回收算法密切相关,所以还需要考虑GC执行完内存回收后是否会在内存空间产生内存碎片;
- new的对象先放在Eden区,此区有大小限制;
- 当Eden的空间被填满的时候,程序又需要新对象,JVM的垃圾回收器将对Eden区进行垃圾回收(Minor GC),将Eden区中不再被其它对象所引用的对象实例进行销毁,然后将Eden区中剩余的对象移动到Survivor0中(所以经过一次YGC之后Eden区一定是空的),再加载新的对象实例至Eden区;
- 如果再次触发垃圾回收,此时在上一次被放到Survivor0区的对象如果还活着的话,则就会被放到Survivor1区中;
- 如果再次经历垃圾回收仍存活,则会被重新放置于Survivor0中,接着还是相同的情况的话,之前的对象实例会辗转于0区与1区(年龄计数器+1);
- 什么时候可以去养老区呢,在这里我们可以设置参数(-XX:MaxTenuringThreshold=xxx),对应于年龄计数器的值,默认是15;
- 在养老区,当对应的内存空间不足的时候,会触发Major GC,进行养老区的内存清理;
- 若养老区执行了Major GC之后仍然无法进行对象的保存,则会抛出OOM异常;
- 总结:
- 针对幸存者S0,S1区,复制之后有交换,谁空谁是to
- 关于垃圾回收,频繁在新生区收集,很少在养老区收集,几乎不在永久区/元空间进行收集
- 只有Eden满了之后才会触发Minor GC/Young GC,而Survivor满了是绝对不会触发Minor GC的;
4.2 对象分配的特殊情况
4.3 代码举例
public class HeapInstanceTest {
byte[] buffer = new byte[new Random().nextInt(1024 * 200)];
public static void main(String[] args) {
ArrayList<HeapInstanceTest> list = new ArrayList<HeapInstanceTest>();
while (true) {
list.add(new HeapInstanceTest());
try {
Thread.sleep(10);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
- 对应堆空间分配过程示意图
4.4 常用调优工具
- JDK命令行
- Eclipse:Memory Analyzer Tool
- Jconsole
- VisualVM
- Jprofiler
- Java Flight Recorder
- GCViewer
- GC Easy
5. Minor GC,Major GC,Full GC
JVM在进行GC是,并非每次都针对上面三个区域(新生代,老年代,方法区)一起回收,大部分时候回收的都是指新生代;
针对HotSpot VM的实现,它里面的GC按照回收区域又分为两大种类型:一种是部分收集(Partial GC),一种是整堆收集(Full GC)
- 部分收集:不是完整收集整个Java堆的垃圾收集,其又分为:
- 新生代收集(Minor GC/Yong GC):只是新生代的垃圾收集;
- 老年代收集(Major GC/Old GC):只是老年代的垃圾收集;
- 目前只有CMS GC会有单独收集老年代的行为;
- 注意,很多时候Major GC会和Full GC混淆使用,需要我们自己具体分清是老年代回收还是整堆回收;
- 混合收集(Mixed GC):收集整个新生代以及部分老年代的垃圾收集,目前只有G1 GC会有这种行为;
- 整堆收集(Full GC):手机整个Java堆和方法区的垃圾收集;
- Minor GC的触发机制:
- 当年轻代空间不足时,就会触发Minor GC,这里的年轻代指的是Eden区满,Survivor区满不会触发Minor GC(每次Minor GC会清理整个年轻代的内存,Survivor是被动GC,不会主动GC);
- 因为Java对象大多具有朝生夕死的特性,所以Minor GC会非常频繁的发生,但是一般回收速度也比较快;
- Minor GC会引发STW(Stop The World),暂停其它的用户线程,等待垃圾回收结束用户线程才恢复运行;
- 老年代GC(Major/Full GC)触发机制
- 指发生在老年代的GC;
- 出现了Major GC,经常会伴随至少一次的Minor GC(不是绝对的,在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程),也就是说在老年代空间不足的时候,会先尝试触发Minor GC,如果之后空间还是不够则触发Major GC;
- Mahor GC的速度一般会比Minor GC慢10倍以上,STW时间更长;
- 如果Major GC后,内存空间还是不足,程序就会抛出OOM;
- Full GC触发机制
- 出发Full GC执行的情况有以下五种
- 调用System.gc()时,建议系统执行Full GC,但是不必然执行;
- 老年代或者是方法区空间不足;
- 通过Minor GC后进入老年代的平均大小大于老年代的可用内存;
- 由Survivor区晋升至老年代时,老年代的可用内存不足;(Full GC是开发或者是调优中尽量要避免的,这样暂停时间会短一些)
- 出发Full GC执行的情况有以下五种
- 代码展示:Yong GC -> Full GC -> OOM
/** 测试GC分代回收
* 测试MinorGC 、 MajorGC、FullGC
* -Xms9m -Xmx9m -XX:+PrintGCDetails
*/
public class GCTest {
public static void main(String[] args) {
int i = 0;
try {
List<String> list = new ArrayList<>();
String a = "testGC";
while (true) {
list.add(a);
a = a + a;
i++;
}
} catch (Throwable t) {
t.printStackTrace();
System.out.println("遍历次数为:" + i);
}
}
}
- 日志输出
6. 堆空间的分代思想
-
问:为什么要把堆空间分代,不分代就不能正常工作了吗?
-
经研究,不同和对象有不同的生命周期,但是70%-90%的对象都是临时对象;
- 新生代由Eden和Survivor构成(S0,S1 又称from,to区),to区总为空;
- 老年代用于存放新生代中经历多次垃圾回收依然存活的对象;
-
其实不分代完全是可以的,分代的唯一目的就是优化GC的性能,如果没有分代思想,那么所有对象都将分配在一起,就像将一个学校的所有学生集中在一个教室进行教学活动;GC想要找到哪些对象已经没有用处时吗,就必须扫描整个堆空间,而我们的很多对象都是朝生夕死的,如果分代的话,我们把新创建的对象放在某一个地方,当GC的时候先对这块存放朝生夕死的对象的区域进行垃圾回收,这样就会腾出很大的一块内存空间;
7. 内存分配策略
-
如果对象在Eden出生并经过一次Minor GC后依然存活,并且能被Survivor容纳的话,将被移到Survivor空间中,并把那个对象的年龄设置为1,该对象在Survivor中每熬过一次Minor GC,它的年龄就会增加一岁,当它的年龄增加到一定的程度(默认是15,但每一个JVM,每一个GC都有所不同)时,就会被晋升到老年代中(对象晋升到老年代的阈值可以通过参数-XX:MaxTenuringThreshold来设置);
-
针对不同年龄段的对象分配原则如下:
-
优先分配放到Eden中;
-
大对象直接分配到老年代;(尽量避免程序中有过多的大对象);
-
长期存活的对象分配到老年代;
-
动态对象年龄判断:
- 如果Survivor区中相同年龄的所有对象的大小总和大于Survivor空间的一半,年龄大于或等于该年龄的对象直接进入老年代,而无需达到所要求的年龄(如15);
- 空间分配担保:-XX:HandlePromotionFailure
-
-
代码示例:
/** 测试:大对象直接进入老年代
* -Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails
*/
public class YoungOldAreaTest {
// 新生代 20m ,Eden 16m, s0 2m, s1 2m
// 老年代 40m
public static void main(String[] args) {
//Eden 区无法存放buffer 晋升老年代
byte[] buffer = new byte[1024 * 1024 * 20];//20m
}
}
- 日志输出:
8. 为对象分配内存(TLAB线程私有缓存区域)
-
为什么有TLAB:
- 堆区是线程共享的区域,任何线程都可以访问到堆区中的共享数据,由于对象的实例的创建在JVM中非常的频繁,因此在并发环境下从堆区中划分内存空间是不安全的;
- 一般为了避免多个线程操作同一内存地址,需要使用加锁等机制,但是加锁会影响内存分配的速度,为了解决这一问题,TLAB应运而生;
-
什么是TLAB
- 从内存模型而不是垃圾收集的角度,对Eden区继续进行划分,JVM为每一个线程分配了一个线程私有的缓存区域,它包含在Eden空间内;
- 多线程同时分配内存的时候,使用TLAB可以避免一系列的非线程安全问题,同时还能够提升内存分配的吞吐量,因此我们可以将这种内存分配方式称之为快速分配策略;
- 所有OpenJDK衍生出来的JVM都提供了TLAB的设计;
-
TLAB说明
- 尽管不是所有的对象实例都能够在TLAB中成功分配内存,但是JVM明确将TLAB作为内存分配的首选;
- 在程序中,开发人员可以通过选项“-XX:UseTLAB“ 设置是够开启TLAB空间;
- 默认情况下TLAB的内存空间非常的小,仅占整个Eden的1%,当然我们可以通过参数 ”-XX:TLABWasteTargetPercent“ 设置TLAB空间所占用Eden空间的百分比大小;
- 一旦对象在TLAB中分配内存失败时,JVM就会尝试着通过使用加锁机制来确保数据操作的原子性,从而直接在Eden空间中分配内存;
-
代码展示:
- 运行程序后,终端输入jps查看相应进程id
- jinfo -flag UseTLAB 64566(进程id),输出-XX:+UseTLAB,证明TLAB默认是开启的
/**
* 测试-XX:UseTLAB参数是否开启的情况:默认情况是开启的
*/
public class TLABArgsTest {
public static void main(String[] args) {
System.out.println("我只是来打个酱油~");
try {
Thread.sleep(1000000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
- TLAB对象分配过程
9. 堆空间中的参数设置
-
-XX:PrintFlagsInitial: 查看所有参数的默认初始值
-
-XX:PrintFlagsFinal:查看所有的参数的最终值(可能会存在修改,不再是初始值)
-
具体查看某个参数的指令:
- jps:查看当前运行中的进程
- jinfo -flag SurvivorRatio 进程id: 查看新生代中Eden和S0/S1空间的比例
- -Xms: 初始堆空间内存(默认为物理内存的1/64)
- -Xmx: 最大堆空间内存(默认为物理内存的1/4)
- -Xmn: 设置新生代大小(初始值及最大值)
- -XX:NewRatio: 配置新生代与老年代在堆结构的占比(比如4表示新生代:老年代=1:4);
- -XX:SurvivorRatio:设置新生代中Eden和S0/S1空间的比例(比如8表示两个Survivor:Eden=2:8);
- -XX:MaxTenuringThreshold:设置新生代垃圾的最大年龄(默认15)
- -XX:+PrintGCDetails:输出详细的GC处理日志
- 输出简略的GC处理日志:-XX:+PrintGC或者是-verbose:gc
- -XX:HandlePromotionFailure:是否设置空间分配担保
-
空间分配担保参数说明
-
在发生Minor GC之前,虚拟机会检查老年代最大的可用的连续空间是否大于新生代所有对象大小的总和;如果大于,则此次Minor GC是安全的;如果小于,则虚拟机会检查-XX:HandlePromotionFailure设置值是否允许担保失败(JDK7以后该参数就失效了,默认便是true)
-
如果是true,那么便会检查老年代最大的可用连续空间是否大于历次晋升到老年代的对象的平均大小,如果大于,则尝试一次Minor GC,但这次Minor GC仍是有风险的;如果小于或者是参数为false,则进行一次Full GC;
-
注意:在JDK6 Update24之后(JDK7),HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略,观察openJDK中的源码变化,虽然源码中还定义了HandlePromotionFailure参数,但是在代码中已经不会再使用它。JDK6 Update24之后的规则变为:只要老年代的连续可用空间大小大于新生代对象大小总和或者历次晋升的平均大小就会进行Minor GC,否则将进行Full GC;
-
为什么要进行空间分配担保:因为新生代采用的是复制收集算法,假如有大量的对象在Minor GC后存活下来(最极端的情况为内存回收后新生代所有的对象都存活下来),而Survivor空间是比较小的,这时就需要老年代进行空间分配担保,把Survivor无法容纳的对象分配到老年代,前提是老年代拥有足够多的内存空间,但是一共有多少对象在内存回收后存活下来是不可预知的,因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考;使用这个平均值与老年代剩余空间进行比较,来决定是否进行Full GC来让老年代腾出更多空间;
-
10. 堆是分配对象的唯一选择吗(不是)
- 在《深入理解Java虚拟机中》关于Java堆内存有这样一段描述:随着JIT编译器的发展与逃逸分析技术的逐渐成熟,栈上分配,标量替换优化技术将会导致一些微妙的变化,所有的对象都分配到堆上也渐渐变得不那么绝对了;
- 在Java虚拟机中,对象是分配在堆内存的,这是一个普遍的常识,但是有一种特殊情况,那就是如果经过逃逸分析后发现一个对象都没有逃逸出去的话,那么就可能被优化成栈上分配,这样就无需在堆上分配内存,也无需进行垃圾回收了,这是一种常见的堆外存储技术;
- 此外,前面提到的基于OpenJDK深度定制的TaoBaoVM,其中创新的GCHI(GCinvisible heap)技术实现OFF-HEAP,将生命周期较长的Java对象从堆中移动到堆外,并且GC不能管理到GCIH内部的Java对象,以此达到降低GC回收频率和提升GC的回收效率的目的;
- 逃逸分析
- 如何将对上的对象分配到栈,需要使用逃逸分析的手段;
- 这是一种可以有效减少Java程序中同步分析和内存堆分配压力的跨函数全局数据流分析算法;
- 通过逃逸分析,Java Hotspot编译器能够分析出一个新的对象的引用的使用范围从而决定是否要将这个对象分配到堆上;
- 逃逸分析的基本行为就是分析对象动态作用域:当一个对象在方法中被定义后,对象只在方法内部中被使用,而没有在方法外部被使用,则认为没有发生逃逸;当一个对象在方法中被定义后,它被外部方法所引用,则认为发生了逃逸,例如作为调用参数传递到其它方法中;
- 如何快速判断是否发生了逃逸分析,就看new的对象实体是否有可能在方法外部被调用;
- 代码分析1:
public void method(){
V v = new V();
//use V
//......
v = null;
//没有发生逃逸的对象,则可以分配到栈上,随着方法执行的结束,栈空间就被移除
}
public static StringBuffer createStringBuffer(String s1,String s2){
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
return sb;
/**
* 由于这个方法返回的sb在方法外部被使用,发生了逃逸
* 改写成return sb.toString();则不会发生逃逸,
* 因为返回的不是sb本身;
*/
}
- 代码分析2:
/**
* 逃逸分析
*
* 如何快速的判断是否发生了逃逸分析,就看new的对象实体是否有可能在方法外被调用。
*/
public class EscapeAnalysis {
public EscapeAnalysis obj;
/*
方法返回EscapeAnalysis对象,发生逃逸
*/
public EscapeAnalysis getInstance(){
return obj == null? new EscapeAnalysis() : obj;
}
/*
为成员属性赋值,发生逃逸
*/
public void setObj(){
this.obj = new EscapeAnalysis();
}
//思考:如果当前的obj引用声明为static的?仍然会发生逃逸。
/*
对象的作用域仅在当前方法中有效,没有发生逃逸
*/
public void useEscapeAnalysis(){
EscapeAnalysis e = new EscapeAnalysis();
}
/*
引用成员变量的值,发生逃逸
*/
public void useEscapeAnalysis1(){
EscapeAnalysis e = getInstance();
//getInstance().xxx()同样会发生逃逸
}
}
-
参数设置:
- 在JDK 6u23版本之后,HotSpot中默认就已经开启了逃逸分析;
- -XX:+PrintEscapeAnalysis查看逃逸分析的筛选结果;
-
结论:开发中能使用局部变量的,就不要在方法外定义;
-
代码优化:
使用逃逸分析,编译器可以对代码做如下的优化;
- 栈上分配:将堆分配转化为栈分配,如果一个对象在子线程中被分配,要是指向该对象的指针永远都不会逃逸,对象可能是栈分配的候选,而不是堆分配;
- 同步省略:如果一个对象被发现只能从一个线程中被访问到,那么这个对象的操作可以不考虑同步;
- 分离对象或标量替换:有的对象可能不需要作为一个连续的内存结构存在也可以被访问到,那么该对象的部分(或全部)可以不存储在堆内存,而是存储在CPU的寄存器中;
-
栈上分配
- JIT编译器在编译期间根据逃逸分析的结果,发现如果一个对象并没有逃逸出去的话,这个对象就可能被优化为栈上分配,当线程结束的时候,栈空间被回收,局部变量对象也被回收,这样就不需要进行GC了;
- 常见的发生逃逸的场景:给成员变量赋值、方法返回值、实例引用传递;
-
代码分析:以下代码关闭逃逸分析(-XX:-DoEscapeAnalysi)的时候,维护10000000个对象;开启逃逸分析(-XX:+DoEscapeAnalysi)的时候,只维护少量的对象(JDK7 逃逸分析默认开启);
/**
* 栈上分配测试
* -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
*/
public class StackAllocation {
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
// 查看执行时间
long end = System.currentTimeMillis();
System.out.println("花费的时间为: " + (end - start) + " ms");
// 为了方便查看堆内存中对象个数,线程sleep
try {
Thread.sleep(1000000);
} catch (InterruptedException e1) {
e1.printStackTrace();
}
}
private static void alloc() {
User user = new User();//未发生逃逸
}
static class User {
}
}
-
同步省略
- 线程同步的代价是非常高的,同步的后果是降低了并发性和性能;
- 在动态编译同步块的时候,JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能被一个线程所访问而没有被发布到其他的线程,如果没有,那么JIT编译器在编译这个同步代码块的时候就会取消对这部分代码的同步,这样就能大大的提高并发性和性能;这个取消同步的过程叫做同步省略,也叫锁消除;
/**
* 同步省略说明
*/
public class SynchronizedTest {
public void f() {
Object hollis = new Object();
synchronized(hollis) {
System.out.println(hollis);
}
}
//代码中对hollis这个对象进行加锁,但是hollis对象的生命周期只在f()方法中
//并不会被其他线程所访问控制,所以在JIT编译阶段就会被优化掉。
//优化为 ↓
public void f2() {
Object hollis = new Object();
System.out.println(hollis);
}
}
- 注意:上述代码只是为了直观的说明同步省略这一代码优化手段,代码本身是存在问题的;
public class SynchronizedTest {
public void f() {
Object hollis = new Object();
synchronized(hollis) {
System.out.println(hollis);
}
}
}
-
同步代码需要加锁,为不同线程的同步共享;但是所需要加的锁必须是同一个锁才有意义,上述同步代码块每次的锁对象hollos都是新new出来的,这并不符合加锁的同步效果;可以说是一个错误的代码,但是能够说明问题;
-
分离对象或标量替换
- 标量Scalcar是指一个无法再分解为更小的数据的数据,Java中的原始数据类型就是标量;
- 相对的,那些可以被分解的数据就是聚合量,Java中对象就是聚合量,因为他可以被分解为其他聚合量和标量;
- 在JIT阶段,如果经过逃逸分析发现一个对象不会被外界访问的话,那么经过JIT优化就会把这个对象拆解成若干个其中包含的若干个成员变量来替代;这个过程就是标量替换;
public class ScalarTest {
public static void main(String[] args) {
alloc();
}
public static void alloc(){
Point point = new Point(1,2);
}
}
class Point{
private int x;
private int y;
public Point(int x,int y){
this.x = x;
this.y = y;
}
}
- 以上代码经过标量替换之后就会变成:
public static void alloc(){
int x = 1;
int y = 2;
}
- 可以看到,Point这个聚合量经过逃逸分析之后发现她并没有逃逸,就被替换成两个标量了,那么标量替换有什么好处呢,标量替换可以大大减少堆内存的占用,因为一旦不需要创建对象了,那么就不需要分配堆内存了,标量替换为站上分配提供了很好的基础;
- 测试代码
/**
* 标量替换测试
* -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:-EliminateAllocations
*/
public class ScalarReplace {
public static class User {
public int id;//标量(无法再分解成更小的数据)
public String name;//聚合量(String还可以分解为char数组)
}
public static void alloc() {
User u = new User();//未发生逃逸
u.id = 5;
u.name = "www.atguigu.com";
}
public static void main(String[] args) {
long start = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
alloc();
}
long end = System.currentTimeMillis();
System.out.println("花费的时间为: " + (end - start) + " ms");
}
}
- 可以测试对比一下,开启标量替换所带来的性能提升还是很巨大的;
11. 逃逸分析小结
- 关于逃逸分析的论文在1999年就发表了,但直到JDK1.6才有实现,而且这项技术到如今也并不是十分成熟的;
- 其根本原因就是无法保证逃逸分析的性能消耗一定低于它所带来的性能提升;虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除;但是逃逸分析自身也是需要进行一系列复杂的分析的,这其实也是一个相对耗时的过程;一个极端的例子,就是经过逃逸分析之后,发现没有一个对象是不逃逸的;那这个逃逸分析的过程就白白浪费掉了;虽然这项技术并不十分成熟,但是它也是即时编译器优化技术中一个十分重要的手段;
- 注意到有一些观点,认为通过逃逸分析,JVM会在栈上分配那些不会逃逸的对象,这在理论上是可行的,但是取决于JVM设计者的选择。据我所知,Oracle HotspotJVM中并未这么做,这一点在逃逸分析相关的文档里已经说明,所以可以明确所有的对象实例都是创建在堆上。回归本篇的提问:堆是分配对象的唯一选择么?一开始我们是否定的态度,现在我们又去肯定这一观点,这岂不是自相矛盾;正所谓否定之否定的观点,通过这篇文章,我们还是有进步的,至少分离对象或标量替换这一点还是存在的,优化了代码运行的效率,减少了堆空间的占用,体现了栈上分配的思想;
- 目前很多书籍还是基于JDK7以前的版本,JDK已经发生了很大变化,intern字符串的缓存和静态变量曾经都被分配在永久代上,而永久代已经被元数据区取代。但是,intern字符串缓存和静态变量并不是被转移到元数据区,而是直接在堆上分配,所以这一点同样符合前面一点的结论:对象实例都是分配在堆上;
- 年轻代是对象的诞生、生长、消亡的区域,一个对象在这里产生、应用、最后被垃圾回收器收集、结束生命;
- 老年代中的Java对象,通常都是从Survivor区域筛选拷贝过来的Java对象;当然,也有特殊情况,我们知道普通的对象会被分配在TLAB上,如果对象较大,JVM会试图直接分配在Eden的其他位置上;如果对象太大,完全无法在新生代找到足够长的连续空闲空间,JVM就会直接将对象分配到老年代;
- 当GC只发生在年轻代中,回收年轻对象的行为被称为Minor GC。当GC发生在老年代时则被称为Major GC或者Full GC。一般的,Minor GC的发生频率要比Major GC高很多,即老年代中垃圾回收发生的频率远远低于年轻代;