转载自https://www.cnblogs.com/wellmaxwang/p/4422855.html
https://blog.csdn.net/louistech/article/details/51062966
一、背景引入
近期在开发一个项目的后台时,当项目上线后出现了一个测试环境没有出现的问题:部分用户在提交信息时提示了该信息不属于当前用户。
经过对代码的review,发现了出错的代码的开发逻辑是,在用户提交信息之后,将信息更新入数据库之前,首先判断当前的信息是否属于当前的用户;通过信息.account_id == 用户.id进行了判断,两个id都是Long类型。直觉是使用==号出错的问题,于是将此处的代码修改为先使用Long.longValue()取出来,再进行比较。(或者使用Long.equals()方法亦可)
然而有一个相当有趣的情况,那就是测试环境并没有这样的问题。究其原因,竟是因为Long类型的LongCache机制引起,且因为测试环境的模拟用户数据量较少,没有突破LongCache内部缓存数组的边界,导致该问题没能及时在测试环境发现。
二、编程建议
在Java开发过程中,最好严格区分原始类型(long/int/short/...)和封装类型(Long/Integer/Short...),虽然JDK能够在大多数情况下进行智能的转型,但是当面对开发一个涉及到金钱的项目时,这样的风险仍然太大!
Java在数据封装类型的设计中,都带了.equals()方法。
三、模拟
1、程序1
- public class A {
- public static void main(String[] args) {
- Long l1 = 128L;
- Long l2 = 128L;
- System.out.println(l1 == l2);
- }
- }
程序输出:false
2、程序2
- public class A {
- public static void main(String[] args) {
- Long l1 = 127L;
- Long l2 = 127L;
- System.out.println(l1 == l2);
- }
- }
程序输出:true
三、关于LongCache.class
在Long的源代码中,可以找到LongCache内部类的代码:
- private static class LongCache {
- private LongCache(){}
- static final Long cache[] = new Long[-(-128) + 127 + 1];
- static {
- for(int i = 0; i < cache.length; i++)
- cache[i] = new Long(i - 128);
- }
- }
从LongCache的代码可以很容易看出来,在类初始化的时候,便生成了一个final的static的Long类型数组,数组的范围是-128到127。
Long类型的valueOf方法代码如下:
- public static Long valueOf(long l) {
- final int offset = 128;
- if (l >= -128 && l <= 127) { // will cache
- return LongCache.cache[(int)l + offset];
- }
- return new Long(l);
- }
所以也就不难知道,当实际的long大小超过正数127时,判断两个封装类==时,会返回false。
另外一种情况,通过new方式生成的两个等值的对象,是否会有相同的效果呢?经过测试,是否定的。两次new出来的对象,都是在内存中新划分区域生成的对象,除非重写方法,否则是绝对不能通过==进行比较的。
四、其他内容
1、Integer、Short、Character、Bytes等封装类也有类似的机制;
2、请关注JVM参数:AutoBoxCacheMax
3、请关注Integer内部类IntegerCache的high属性。
———————————————————————————————————————————————————
2014年去某公司笔试的时候遇到这么一道题:
public class Test { public static void main(String[] args) { Integer int1 = Integer.valueOf("100"); Integer int2 = Integer.valueOf("100"); System.out.println(int1 == int2); } }
问打印的结果的多少? 但是我回答的是false, 后来仔细想想应该没有这个简单,就翻了下JDK的源码,发现:
public static Integer valueOf(String s) throws NumberFormatException { return Integer.valueOf(parseInt(s, 10)); } public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); }
发现里面另有玄机,多了个IntegerCache类:
private static class IntegerCache { static final int low = -128; static final int high; static final Integer cache[]; static { // high value may be configured by property int h = 127; String integerCacheHighPropValue = sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high"); if (integerCacheHighPropValue != null) { try { int i = parseInt(integerCacheHighPropValue); i = Math.max(i, 127); // Maximum array size is Integer.MAX_VALUE h = Math.min(i, Integer.MAX_VALUE - (-low) -1); } catch( NumberFormatException nfe) { // If the property cannot be parsed into an int, ignore it. } } high = h; cache = new Integer[(high - low) + 1]; int j = low; for(int k = 0; k < cache.length; k++) cache[k] = new Integer(j++); // range [-128, 127] must be interned (JLS7 5.1.7) assert IntegerCache.high >= 127; } private IntegerCache() {} }
原来Integer把-128到127(可调)的整数都提前实例化了。 这就解释了那道面试题的答案,原来你不管创建多少个这个范围内的Integer用ValueOf出来的都是同一个对象。
但是为什么JDK要这么多此一举呢? 我们仔细想想, 淘宝的商品大多数都是100以内的价格, 一天后台服务器会new多少个这个的Integer, 用了IntegerCache,就减少了new的时间也就提升了效率。同时JDK还提供cache中high值得可配置,
这无疑提高了灵活性,方便对JVM进行优化。
参考Long的源码:
private static class LongCache { private LongCache(){} static final Long cache[] = new Long[-(-128) + 127 + 1]; static { for(int i = 0; i < cache.length; i++) cache[i] = new Long(i - 128); } }
Long也做了缓存,只是没有提供调整机制, 在Short中类似:
private static class ShortCache { private ShortCache(){} static final Short cache[] = new Short[-(-128) + 127 + 1]; static { for(int i = 0; i < cache.length; i++) cache[i] = new Short((short)(i - 128)); } }