This website requires JavaScript.

《深入理解Java虚拟机》中一题引发的思考

1 - 引言

在阅读『深入理解 Java 虚拟机(第 3 版)』时看到里面的一道代码题目,书中给出了题目的解答。自己对于这个题目拓展的想了几个变式,结果有所差异,为了寻找产生差异的原因又深入了解了一番。

2 - 类初始化时机

2.1 - 原题

在『深入理解 Java 虚拟机(第 3 版)』的 7.2 章节 "类加载的时机",其代码清单 7-1 有这么一段代码:

public class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }

    public static int VALUE = 1;
}

public class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init!");
    }
}

public class Main {

    public static void main(String[] args) {
        System.out.println(SubClass.VALUE);
    }
}

输出的结果是: img_1

书中给出了这个结果的解答:

上述代码运行之后,只会输出“SuperClass init!”,而不会输出“SubClass init!”。对于静态字段, 只有直接定义这个字段的类才会被初始化,因此通过其子类来引用父类中定义的静态字段,只会触发父类的初始化而不会触发子类的初始化。1

所以 main() 方法里调用 SubClass.VALUE 时实际上调用了 SuperClass.VALUE。而 SuperClass 之前还未被加载过,就触发了加载的过程,在初始化的时候调用了 SuperClass 里的 static 静态代码块。

2.2 - 变式一

这里把上面代码稍作修改。

public class SuperClass {
    static {
        System.out.println("SuperClass init");
    }

    // public static int VALUE = 1;
    public final static int VALUE = 1; // 添加一个 final 修饰
}    

在其他代码不变的情况下,把 SuperClass.VALUE 增加一个 final修饰符,这时候输出结果是: img_2

和原来的结果不同,"SuperClass init!"和"SubClass init!"都没有输出出来。

对于这个结果,我一开始猜测的是由于 VALUE 字段被 final 修饰,且又是基本数据类型,所以 JVM 做了一些优化,不通过 SuperClass.VALUE 而是直接引用这个字段的值。

后来看了一下 IDEA 反编译 Main.class的源码:

// Main.class
public class Main {
    public Main() {
    }

    public static void main(String[] args) {
        System.out.println(1);
    }
}

Main类在编译的时候直接把 SubClass.VALUE 优化成了值"1"。这和一开始的猜测还是有些出入,Main类不是被 JVM 在运行时优化的,而是在编译器就直接被优化了。

对于这种情况编译器是依据什么原理优化的,在后面在深入展开,先继续看下一种变式。

2.3 - 变式二

public class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }

    // public static int VALUE = 1;
    // public final static int VALUE = 1;
    public final static Integer VALUE = 1; // 把 VALUE 改成 Integer 包装类
}   

这次把之前 int 类型的 VALUE 改成 包装类Integer,看一下运行的结果。

img_3

这次的结果又输出了"SuperClass init!"。确实,包装类其实就是一种被 final 修饰的普通类,不能像基本数据类型那样被编译器优化,所以就要调用 SubClass.VALUE 而初始化 SuperClass

2.4 - 变式三

public class SuperClass {
    static {
        System.out.println("SuperClass init!");
    }

    // public static int VALUE = 1;
    // public final static int VALUE = 1;
    // public final static Integer VALUE = 1;
    public final static String VALUE = "1"; // 把 VALUE 改成 String
}  

这次把 SubClass.VALUEInteger 改成 String,看一下运行的结果: img_4

现在的结果和前面变式一的结果一样了,这让我有点疑惑的。StringInteger 不都是包装类吗,为什么可以和基本数据类型一样不会触发 SuperClass 的初始化,难道 String 有什么特殊处理吗?

我还是先去看了一下 IDEA 反编译的 Main.class 的源码:

// Main.class
public class Main {
    public Main() {
    }

    public static void main(String[] args) {
        System.out.println("1");
    }
}

确实和变式一的情况一样,编译器直接在编译阶段就把 String 类型的 VALUE 值直接优化了。

3 - 编译器优化技术---条件常量传播

对于上文中变式一和变式三的代码运行结果,只输出了 VALUE 的值而没有输出"SuperClass init!",首要原因就是编译器优化技术

编译器的目标虽然是做由程序代码翻译为本地机器码的工作,但其实难点并不在于能不能成功翻译出机器码,输出代码优化质量的高低才是决定编译器优秀与否的关键。 OpenJDK 的官方 Wiki 上,HotSpot 虚拟机设计团队列出了一个相对比较全面的、即时编译器中采用的优化技术列表。地址:https://wiki.openjdk.java.net/display/HotSpot/PerformanceTacticIndex。 1

官方列出了很多的编译器优化技术,其中 条件常量传播 (conditional constant propagation) 就是造成上文变式一和变式三输出结果的原因。

常量传播是现代的编译器中使用最广泛的优化方法之一,它通常应用于高级中间表示(IR)。它解决了在运行时静态检测表达式是否总是求值为唯一常数的问题,如果在调用过程时知道哪些变量将具有常量值,以及这些值将是什么,则编译器可以在编译时期简化常数。2

3.1 - 优化常量

简单来说就是编译器会通过一定的算法发现代码中存在的常量,然后直接替换指向它的变量值。例如:

public class Main {
    public static final int a = 1; // 全局静态常量

    public static void main(String[] args) {
        final int b = 2; // 局部常量
        System.out.println(a);
        System.out.println(b);
    }
}

编译器编译之后:

// Main.class
public class Main {
    public static final int a = 1;

    public static void main(String[] args) {
        int b = true;
        System.out.println(1);
        System.out.println(2);
    }
}

3.2 - 优化常量表达式

甚至一些常量的表达式,也可以预先直接把结果编译出来:

public class Main {
    public static void main(String[] args) {
        final int a = 3 * 4 + 5 - 6;
        int b = 10;
        if (a > b) {
            System.out.println(a);
        }
    }
}

编译之后:

// Main.class
public class Main {
    public static void main(String[] args) {
        int a = true;
        int b = 10;
        if (11 > b) {
            System.out.println(11);
        }

    }
}

3.3 - 优化字符串拼接

还可以编译字符串的拼接,网上经常有一些题目问生成了多少个 String 对象,在 JVM 虚拟机的层面一顿分析,其实都不正确,编译器直接在编译的时候就优化掉了,根本到不了运行时的内存池。

public class Main {
    public static void main(String[] args) {
        final String str = "hel" + "lo";
        System.out.println(str);
        System.out.println("hello" == str);
    }
}

编译后的源码,看到 str 直接被替换成了"hello"字符串,且 "hello" == str 为 true,所以全程就一个 String 对象生成。

// Main.class
public class Main {
    public static void main(String[] args) {
        String str = "hello";
        System.out.println("hello");
        System.out.println(true);
    }
}

小拓展:很多地方都说多个字符串拼接不能用"+"直接拼接,要用 StringBuilder 之类的。实际上,即使用"+"也会被编译器优化成 StringBuilder 的,有兴趣可以自己尝试一下。

3.4 - 编译器条件常量传播带来的风险

虽然编译器优化代码可以提升运行时的效率,但是也会带来一定的风险

3.4.1 - 常量反射失效

虽然一些被 final 修饰的字段编译器会认定其为常量而进行优化,但是 Java 有反射机制,通过一些奇淫技巧可以更改这些值。但是由于被编译器优化了,可能导致被修改的值不能像预期那样生效。如:

public class Main {
    public static final String VALUE = "A";

    public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException {
        Class<Main> mainClass = Main.class;
        Field value = mainClass.getField("VALUE");
        value.setAccessible(true);

        // 去除 A 的 final 修饰符
        Field modifiersField = Field.class.getDeclaredField("modifiers");
        modifiersField.setAccessible(true);
        modifiersField.setInt(value, value.getModifiers() & ~Modifier.FINAL);

        value.set(null, "B");
        System.out.println(VALUE); // 实际还是输出 "A"
    }
}  

这段代码虽然一通操作把 VALUE 的值从"A"改成"B"了,但是编译器在编译的时候早就把 System.out.println(VALUE); 替换成 System.out.println("A"); ,最后运行结果会和预期不同。

3.4.2 - 部分编译

如果常量和其引用的对象不在一个文件中,当修改常量之后只重新编译常量所在文件,那么未重新编译的文件就会使用旧值。如:

// Constant.java
public class Constant {
    public final static String VALUE = "A";
}

// Main.java
public class Main {
    public static void main(String[] args) {
        System.out.println(Constant.VALUE);
    }
}

假如把 Constant.VALUE 的值修改成"B"然后通过 javac Constant.java 单独编译 Constant.java 文件,但是 Main 里面输出的值依旧会是"A"。

4 - 常量、静态常量池、动态常量池

4.1 - 常量

常量是指在程序的整个运行过程中值保持不变的量。在 Java 开发的时候通常指的是被 final 修饰的变量。但从虚拟机的角度看"常量"的定义会有所不同。

在虚拟机中,常量会被存放于常量池中,而常量池中会存放两大类常量:字面量(Literal)和符号引用(Symbolic References)。字面量比较接近于 Java 语言层面的常量概念,如文本字符串、被声明为 final 的常量值等。1 而符号引用则属于编译原理方面的概念,主要包含类、字段、方法信息等,这里就不展开描述了。

4.2 - 静态常量池

(静态)常量池可以比喻为 Class 文件里的资源仓库,它是 Class 文件结构中与其他项目关联最多的数据,通常也是占用 Class 文件空间最大的数据项目之一,另外,它还是在 Class 文件中第一个出现的表类型数据项目。

(静态)常量池里面存储的数据项目类型如下表: img.png

img_1.png 1

静态常量池编译之后就写定在 class 文件里了,可以直接查看字节码来观察其组成结构,如以下代码:

public class Main {
    final static String A = "A";
    final static int B = 1;
    final static Integer C = 2;

    public static void main(String[] args) {
        System.out.println(A);
        System.out.println(B);
        System.out.println(C);
    }
}

编译之后通过 javap -verbose Main.class 命令查看反编译之后的字节码: img.jpg

可以发现代码中的 Stringint 型数据被存储在静态常量池中,Integer就没有。因为前者对应常量池中的"CONSTANT_String_info"和"CONSTANT_Integer_info" 类型,而后者相当于普通的对象,只被存储了对象信息。

这就解释了上文中变式一、变式三与变式二结果不同的原因。

4.3 - 动态常量池

运行时常量池(动态常量池)相对于 Class 文件常量池(静态常量池)的另外一个重要特征是具备动态性,Java 语言并不要求常量一定只有编译期才能产生,也就是说,并非预置入 Class 文件中常量池的内容才能进入方法区运行时常量池,运行期间也可以将新的常量放入池中,这种特性被开发人员利用得比较多的便是 String 类的 intern() 方法。

5 - 结语

《深入理解 Java 虚拟机》确实是一本很好的书,反复读过几次,每次都有新的收获,这次更是由于自己在打源码的时候的"不小心失误"有了意料之外的收获。

参考


原文地址:《深入理解 Java 虚拟机》中一题引发的思考

0条评论
avatar