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

头像
zzzzbw
    阅读 7 分钟
    6

    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.VALUE 从 Integer 改成 String，看一下运行的结果:

    img_4

    现在的结果和前面变式一的结果一样了，这让我有点疑惑的。String 和 Integer 不都是包装类吗，为什么可以和基本数据类型一样不会触发 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...。 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.png1

    静态常量池编译之后就写定在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

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

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

    4.3 - 动态常量池

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

    <div id="refer-anchor"></div>

    5 - 结语

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

    参考

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

    javajvm字节码
    zzzzbw
    922 声望383 粉丝

    Playing and Coding

    « 上一篇
    Service调用其他Service的private方法, @Transactional会生效吗(下)
    下一篇 »
    详解SptingBoot参数校验机制，使用校验不再混乱

    引用和评论

    推荐阅读
    头像
    责任链模式在 Spring 中的应用

    zzzzbw阅读 4.5k

    头像
    在Java程序中监听mysql的binlog

    huan1993赞 11阅读 1.9k

    头像
    Jerry和您聊聊Chrome开发者工具

    注销赞 9阅读 4.5k评论 3

    头像
    Bitmap 和 布隆过滤器傻傻分不清？你这不应该啊

    程序员小富赞 8阅读 1.6k评论 1

    头像
    Just for fun——迅速写完快速排序

    ufdf赞 3阅读 2.6k

    头像
    Spring 实现 3 种异步流式接口，干掉接口超时烦恼

    程序员小富赞 5阅读 1.7k

    头像
    💢线上高延迟请求排查

    crossoverJie赞 6阅读 802评论 5

    0 条评论
    得票最新