vlambda博客
学习文章列表

数字运算，是一门语言安身立命的根本。如果连1+1都变得不可信了，整个程序就会变得不可信。

考虑到这样一段代码：

Integer a = 1;
System.out.println(a);
Integer b = 2;
System.out.println( a.intValue() == b.intValue() );
System.out.println(a.equals(b));

执行的结果，竟然是：

-996
true
true

这时候，你还敢继续把代码写下去么？

为什么会这样？

很简单，我们使用反射改变了某些东西。

下面这段代码，将会改变一些基本运算的执行逻辑，理所当然属于埋坑的范畴之一。我们还是先看一下它的行为。

public class StaticBlock {
    static {
        try {
            Class<?> cls = Integer.class.getDeclaredClasses()[0];
            Field f = cls.getDeclaredField("cache");
            f.setAccessible(true);
            Integer[] cache = ((Integer[]) f.get(cls));
            for (int i = 0; i < cache.length; i++) {
                cache[i] = -996;
            }
        } catch (Exception e) {
            e.printStackTrace();
            //silence
        }
    }
}

程序使用反射，修改了Integer中cache变量中的内容，使得里面的数字，变成了一个固定的值。我们这里用的是-996，意思是永远没有996。

你只要想方设法把这段代码给触发了，Java的Integer包装类，就算是废了。

我们能这么做，关键就在于cache变量上。

数字缓存

Java 中有 8 种基本类型，鉴于 Java 面向对象的特点，它们同样有着对应的 8 个包装类型，比如 int 和 Integer，包装类型的值可以为 null，很多时候，它们都能够相互赋值。

考虑到下面这段小小的代码，它的运算就经历了多次装箱拆箱。

public Integer cal() {
 Integer a = 1000;
 int b = a * 10;
 return b;
}

我们从字节码层面看一下。

public java.lang.Integer read();
    descriptor: ()Ljava/lang/Integer;
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=1
         0: sipush        1000
         3: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
         6: astore_1
         7: aload_1
         8: invokevirtual #3                  // Method java/lang/Integer.intValue:()I
        11: bipush        10
        13: imul
        14: istore_2
        15: iload_2
        16: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
        19: areturn

可以看到这么简单的运算，竟然涉及了valueOf、intValue等方法多次，说明它的计算过程效率是比单纯的数字运算要低效的。

其中valueOf方法，用来将普通数字包装成Integer，我们跟踪到它的方法。

public static Integer valueOf(int i) {
    if (i >= IntegerCache.low && i <= IntegerCache.high)
        return IntegerCache.cache[i + (-IntegerCache.low)];
    return new Integer(i);
}

为了增加转化的效率，Integer内部，竟然缓存了i和Integer的对应关系！这样在下次用的时候，就能够直接进行定位。cache变量，就是用来存放这些中间信息的地方。如果我们通过反射改变了它，Integer就会有不正常的行为！

更多

IntegerCache，缓存了 low 和 high 之间的 Integer 对象，可以通过 -XX:AutoBoxCacheMax 来修改上限。

String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");

有意思的是，Long也有这样的Cache，但它的上下限是固定的，和Byte、Short是一样的。

static final Long cache[] = new Long[-(-128) + 127 + 1];S

Double和Float比较惨，只能直接new一个，做不了这种缓存。

综合来看，Integer是比较特殊的。下面这段代码，即使我们不做反射魔改，它的输出依然是不确定的。

Integer n1 = 123;
Integer n2 = 123;
Integer n3 = 128;
Integer n4 = 128;

System.out.println(n1 == n2);
System.out.println(n3 == n4);

这是因为，正常情况，它会输出true,false；而当我们使用AutoBoxCacheMax增加了它的上限，它就会输出true,true。果然对象之间相互比较，还是得用equals才相对靠谱一点啊。

End

看着这个齐胸小坑，我的感情真的是难以言表。这段代码整体看来，如果进行了正常的review，还是很容易看出问题的，但凡是总有万一。

如果这段代码被放到线上，哪怕是某个呆萌的同学不小心练手的时候提交到了仓库中，后果都是毁灭性的。这段代码目的比较直白，但如果我们把cache数组的修改逻辑，改的复杂一点，在某个特定的条件下才会触发某单个变量值的修改，那才是要命的。

毕竟连sonar都扫描不出来，而且jdk中这样的私有变量，还有一箩筐等着我们去探索呢！