一、堆,是分配对象的唯一选择吗

在《深入理解Java虚拟机中》关于Java堆内存有这样一段描述:
随着JIT编译期的发展与逃逸分析技术逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化,所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

在Java虚拟机中,对象是在Java堆中分配内存的,这是一个普遍的常识。但是,有一种特殊情况,那就是如果经过逃逸分析(Escape Analysis)后发现,一个对象并没有逃逸出方法的话,那么就可能被优化成栈上分配。这样就无需在堆上分配内存,也无须进行垃圾回收了。这也是最常见的堆外存储技术。

此外,前面提到的基于OpenJDK深度定制的TaoBaoVM,其中创新的GCIH(GC invisible heap)技术实现off-heap,将生命周期较长的Java对象从heap中移至heap外,并且GC不能管理GCIH内部的Java对象,以此达到降低GC的回收频率和提升GC的回收效率的目的。


马克思:否定之否定!

是 —-> 不是 —-> 是

二、编译的开销

2.1-时间开销

编译的时间开销:

解释器的执行,抽象的看是这样的:
输入的代码 -> [ 解释器 解释执行 ] -> 执行结果

JIT编译然后再执行的话,抽象的看则是:
输入的代码 -> [ 编译器 编译 ] -> 编译后的代码 -> [ 执行 ] -> 执行结果

注意:
说JIT比解释快,其实说的是“执行编译后的代码”比“解释器解释执行”要快,并不是说“编译”这个动作比“解释”这个动作快。JIT编译再怎么快,至少也比解释执行一次略慢一些,而要得到最后的执行结果还得再经过一个“执行编译后的代码”的过程。所以,对“只执行一次”的代码而言,解释执行其实总是比JIT编译执行要快。怎么算是只执行一次的代码呢?粗略说,下面条件同时满足时就是严格的`只执行一次。
只被调用一次,例如类的构造器(class initializer,())
没有循环,对只执行一次的代码做JIT编译再执行,可以说是得不偿失。
对只执行少量次数的代码,JIT编译带来的执行速度的提升也未必能抵消掉最初编译带来的开销。

只有对频繁执行的代码(热点代码),JIT编译才能保证有正面的收益。

2.2-空间开销

对一般的Java方法而言,编译后代码的大小相对于字节码的大小,膨胀比达到10+是很正常的。同上面说的时间开销一样,这里的空间开销也是,只有对执行频繁的代码才值得编译,如果把所有代码都编译则会显著增加代码所占空间,导致代码爆炸。这也就解释了为什么有些JVM会选择不总是做JIT编译,而是选择用解释器+JIT编译器的混合执行引擎。

三、即时编译对代码的优化

3.1-逃逸分析


如何将堆上的对象分配到栈,需要使用逃逸分析手段。逃逸分析主要是针对server端的jdk
逃逸分析(Escape Analysis)是目前Java虚拟机中比较前沿的优化技术。这是一种可以有效减少Java 程序中同步负载和内存堆分配压力的跨函数全局数据流分析算法。

通过逃逸分析,Java Hotspot编译器能够分析出一个新的对象的引用的使用范围,从而决定是否要将这个对象分配到堆上。

逃逸分析的基本行为就是分析对象动态作用域:
当一个对象在方法中被定义后,对象只在方法内部使用,则认为没有发生逃逸。
当一个对象在方法中被定义后,它被外部方法所引用,则认为发生逃逸。例如作为调用参数传递到其他地方中。

public void my_method() {
V v = new V();
//use v
//……
v = null;
}
没有发生逃逸的对象,则可以分配到栈上,随着方法执行的结束,栈空间就被移除。

逃逸分析包括:
- 全局变量赋值逃逸
- 方法返回值逃逸
- 实例引用发生逃逸
- 线程逃逸:赋值给类变量或可以在其他线程中访问的实例变量

代码举例1

  1. /**
  2. * 逃逸分析
  3. *
  4. * 如何快速的判断是否发生了逃逸分析,大家就看new的对象实体是否有可能在方法外被调用。
  5. *
  6. * @create 2021 下午 4:00
  7. */
  8. public class EscapeAnalysis {
  9. public EscapeAnalysis obj;
  10. /*
  11. 方法返回EscapeAnalysis对象,发生逃逸
  12. */
  13. public EscapeAnalysis getInstance(){
  14. return obj == null? new EscapeAnalysis() : obj;
  15. }
  16. /*
  17. 为成员属性赋值,发生逃逸
  18. */
  19. public void setObj(){
  20. this.obj = new EscapeAnalysis();
  21. }
  22. //思考:如果当前的obj引用声明为static的,会发生逃逸吗?会!
  23. /*
  24. 对象的作用域仅在当前方法中有效,没有发生逃逸
  25. */
  26. public void useEscapeAnalysis(){
  27. EscapeAnalysis e = new EscapeAnalysis();
  28. }
  29. /*
  30. 引用成员变量的值,发生逃逸
  31. */
  32. public void useEscapeAnalysis1(){
  33. EscapeAnalysis e = getInstance();
  34. //getInstance().xxx()同样会发生逃逸
  35. }
  36. /*
  37. * 也发生了逃逸,传入的变量e可能在别的地方使用
  38. * 所以会发生逃逸
  39. * */
  40. public void operate(EscapeAnalysis e){
  41. // e
  42. }
  43. }

参数设置

参数设置:
在JDK 6u23版本之后,HotSpot中默认就已经开启了逃逸分析。
如果使用的是较早的版本,开发人员则可以通过:

  • 通过选项“-XX:+DoEscapeAnalysis”显式开启逃逸分析
  • 通过选项“-XX:+PrintEscapeAnalysis”查看逃逸分析的筛选结果。


    结论:
    开发中能使用局部变量的,就不要使用在方法外定义。

    3.2-代码优化一:栈上分配

    使用逃逸分析,编译器可以对代码做如下优化:

    栈上分配。将堆分配转化为栈分配。如果经过逃逸分析后发现,一个对象并没有逃逸出方法的话,那么就可能被优化成栈上分配。这样就无需在堆上分配内存,也无须进行垃圾回收了。可以减少垃圾回收时间和次数。

    JIT编译器在编译期间根据逃逸分析的结果,发现如果一个对象并没有逃逸出方法的话,就可能被优化成栈上分配。分配完成后,继续在调用栈内执行,最后线程结束,栈空间被回收,局部变量对象也被回收。这样就无须进行垃圾回收了。

    代码举例

    1. /**
    2. * 栈上分配测试,-DoEscapeAnalysis是关闭逃逸分析,系统默认是开启的
    3. * -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
    4. *
    5. * 只要开启了逃逸分析,就会判断方法中的变量是否发生了逃逸。如果没有发生了逃逸,则会使用栈上分配
    6. *
    7. * @create 2021 10:31
    8. */
    9. public class StackAllocation {
    10. public static void main(String[] args) {
    11. long start = System.currentTimeMillis();
    12. for (int i = 0; i < 10000000; i++) {
    13. alloc();
    14. }
    15. // 查看执行时间
    16. long end = System.currentTimeMillis();
    17. System.out.println("花费的时间为: " + (end - start) + " ms");
    18. // 为了方便查看堆内存中对象个数,线程sleep
    19. try {
    20. Thread.sleep(1000000);
    21. } catch (InterruptedException e1) {
    22. e1.printStackTrace();
    23. }
    24. }
    25. private static void alloc() {
    26. User user = new User();//是否发生逃逸? 没有!
    27. }
    28. static class User {
    29. }
    30. //没有开启逃逸分析的情况下,执行时间是100ms左右
    31. //开启逃逸分析是3ms左右

    3.3-代码优化二:同步省略(消除)

    同步省略。如果一个对象被发现只能从一个线程被访问到,那么对于这个对象的操作可以不考虑同步。

    线程同步的代价是相当高的,同步的后果是降低并发性和性能。

    在动态编译同步块的时候,JIT编译器可以借助逃逸分析来判断同步块所使用的锁对象是否只能够被一个线程访问而没有被发布到其他线程。如果没有,那么JIT编译器在编译这个同步块的时候就会取消对这部分代码的同步。这样就能大大提高并发性和性能。这个取消同步的过程就叫同步省略,也叫锁消除。

    代码举例

    1. /**
    2. * 同步省略说明
    3. * @create 2021 11:07
    4. */
    5. public class SynchronizedTest {
    6. public void f() {
    7. /*
    8. * 代码中对hollis这个对象进行加锁,但是hollis对象的生命周期只在f()方法中,
    9. * 并不会被其他线程所访问到,所以在JIT编译阶段就会被优化掉。
    10. *
    11. * 问题:字节码文件中会去掉hollis吗?
    12. * */
    13. Object hollis = new Object();
    14. synchronized(hollis) {
    15. System.out.println(hollis);
    16. }
    17. /*
    18. * 优化后;
    19. * Object hollis = new Object();
    20. * System.out.println(hollis);
    21. * */
    22. }
    23. }

3.4-代码优化三:标量替换


标量(Scalar)是指一个无法再分解成更小的数据的数据。Java中的原始数据类型就是标量。

相对的,那些还可以分解的数据叫做聚合量(Aggregate),Java中的对象就是聚合量,因为他可以分解成其他聚合量和标量。

在JIT阶段,如果经过逃逸分析,发现一个对象不会被外界访问的话,那么经过JIT优化,就会把这个对象拆解成若干个其中包含的若干个成员变量来代替。这个过程就是标量替换。

代码举例1

  1. public static void main(String[] args) {
  2. alloc();
  3. }
  4. private static void alloc() {
  5. Point point = new Point1,2);
  6. System.out.println("point.x="+point.x+"; point.y="+point.y);
  7. }
  8. class Point{
  9. private int x;
  10. private int y;
  11. }
  12. 以上代码,经过标量替换后,就会变成:
  13. private static void alloc() {
  14. int x = 1;
  15. int y = 2;
  16. System.out.println("point.x="+x+"; point.y="+y);
  17. }
  1. /**
  2. * 标量替换测试
  3. * -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:-EliminateAllocations
  4. *
  5. * 结论:Java中的逃逸分析,其实优化的点就在于对栈上分配的对象进行标量替换。
  6. *
  7. * @create 2021 12:01
  8. */
  9. public class ScalarReplace {
  10. public static class User {
  11. public int id;
  12. public String name;
  13. }
  14. public static void alloc() {
  15. User u = new User();//未发生逃逸
  16. u.id = 5;
  17. u.name = "www.atguigu.com";
  18. }
  19. public static void main(String[] args) {
  20. long start = System.currentTimeMillis();
  21. for (int i = 0; i < 10000000; i++) {
  22. alloc();
  23. }
  24. long end = System.currentTimeMillis();
  25. System.out.println("花费的时间为: " + (end - start) + " ms");
  26. }
  27. }
  28. /*
  29. class Customer{
  30. String name;
  31. int id;
  32. Account acct;
  33. }
  34. class Account{
  35. double balance;
  36. }
  37. */

可以看到,Point这个聚合量经过逃逸分析后,发现他并没有逃逸,就被替换成两个标量了。那么标量替换有什么好处呢?就是可以大大减少堆内存的占用。因为一旦不需要创建对象了,那么就不再需要分配堆内存了。其实栈上分配采用的就是标量替换,如果把标量替换关掉,栈上分配的功能也失效了,标量替换的数据是放在栈上的。
具体要不要开启逃逸分析需要根据实际情况进行分析,在大多数代码中都是发生了逃逸的,如果开启逃逸分析势必会消耗一定的性能开销,除非能确定大多数代码没有发生逃逸

标量替换为栈上分配提供了很好的基础。

参数设置

标量替换参数设置:
参数-XX:+EliminateAllocations:开启了标量替换(默认打开),允许将对象打散分配在栈上。

代码举例2

3.5-逃逸分析小结

逃逸分析小结:逃逸分析并不成熟

  • 关于逃逸分析的论文在1999年就已经发表了,但直到JDK 1.6才有实现,而且这项技术到如今也并不是十分成熟的。
  • 其根本原因就是无法保证非逃逸分析的性能消耗一定能高于他的消耗。虽然经过逃逸分析可以做标量替换、栈上分配、和锁消除。但是逃逸分析自身也是需要进行一系列复杂的分析的,这其实也是一个相对耗时的过程。
  • 一个极端的例子,就是经过逃逸分析之后,发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。
  • 虽然这项技术并不十分成熟,但是它也是即时编译器优化技术中一个十分重要的手段。
  • 注意到有一些观点,认为通过逃逸分析,JVM会在栈上分配那些不会逃逸的对象,这在理论上是可行的,但是取决于JVM设计者的选择。
  • 目前很多书籍还是基于JDK 7以前的版本,JDK已经发生了很大变化,intern字符串的缓存和静态变量曾经都被分配在永久代上,而永久代已经被元数据区取代。但是,intern字符串缓存和静态变量并不是被转移到元数据区,而是直接在堆上分配,所以这一点同样符合前面一点的结论:对象实例都是分配在堆上。