原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。
数字运算,是一门语言安身立命的根本。如果连1+1都变得不可信了,整个程序就会变得不可信。
考虑到这样一段代码:
Integer a = 1;
Sy(a);
Integer b = 2;
Sy( a.intValue() == b.intValue() );
Sy(b));
执行的结果,竟然是:
-996
true
true
这时候,你还敢继续把代码写下去么?
为什么会这样?
很简单,我们使用反射改变了某些东西。
下面这段代码,将会改变一些基本运算的执行逻辑,理所当然属于埋坑的范畴之一。我们还是先看一下它的行为。
public class StaticBlock {
static {
try {
Class<?> cls = In()[0];
Field f = cls.getDeclaredField("cache");
f.setAccessible(true);
Integer[] cache = ((Integer[]) f.get(cls));
for (int i = 0; i < cac; 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:(I)Ljava/lang/Integer;
6: astore_1
7: aload_1
8: invokevirtual #3 // Method java/lang:()I
11: bipush 10
13: imul
14: istore_2
15: iload_2
16: invokestatic #2 // Method java/lang:(I)Ljava/lang/Integer;
19: areturn
可以看到这么简单的运算,竟然涉及了valueOf、intValue等方法多次,说明它的计算过程效率是比单纯的数字运算要低效的。
其中valueOf方法,用来将普通数字包装成Integer,我们跟踪到它的方法。
public static Integer valueOf(int i) {
if (i >= In && i <= In)
return In[i + (-In)];
return new Integer(i);
}
为了增加转化的效率,Integer内部,竟然缓存了i和Integer的对应关系!这样在下次用的时候,就能够直接进行定位。cache变量,就是用来存放这些中间信息的地方。如果我们通过反射改变了它,Integer就会有不正常的行为!
更多
IntegerCache,缓存了 low 和 high 之间的 Integer 对象,可以通过 -XX:AutoBoxCacheMax 来修改上限。
String integerCacheHighPropValue =
("java.lang.Integer.In");
有意思的是,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;
Sy(n1 == n2);
Sy(n3 == n4);
这是因为,正常情况,它会输出true,false;而当我们使用AutoBoxCacheMax增加了它的上限,它就会输出true,true。果然对象之间相互比较,还是得用equals才相对靠谱一点啊。
End
看着这个齐胸小坑,我的感情真的是难以言表。这段代码整体看来,如果进行了正常的review,还是很容易看出问题的,但凡是总有万一。
如果这段代码被放到线上,哪怕是某个呆萌的同学不小心练手的时候提交到了仓库中,后果都是毁灭性的。这段代码目的比较直白,但如果我们把cache数组的修改逻辑,改的复杂一点,在某个特定的条件下才会触发某单个变量值的修改,那才是要命的。
毕竟连sonar都扫描不出来,而且jdk中这样的私有变量,还有一箩筐等着我们去探索呢!
推荐阅读:
1. 玩转Linux
2. 什么味道专辑
3. 蓝牙如梦
4. 杀机!
5. 失联的架构师,只留下一段脚本
6. 架构师写的BUG,非比寻常