LongCache机制与Long等值比较\\\\Integer 中的缓存类IntegerCache

Myth丶恋晨 2022-05-22 10:47 236阅读 0赞

转载自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

\[java\]  [view plain][]   [copy][view plain]

1.  **public** **class** A \{  
2.      **public** **static** **void** main(String\[\] args) \{  
3.          Long l1 = 128L;  
4.          Long l2 = 128L;  
5.          System.out.println(l1 == l2);   
6.      \}  
7.  \}

程序输出：false

2、程序2

\[java\]  [view plain][]   [copy][view plain]

1.  **public** **class** A \{  
2.      **public** **static** **void** main(String\[\] args) \{  
3.          Long l1 = 127L;  
4.          Long l2 = 127L;  
5.          System.out.println(l1 == l2);   
6.      \}  
7.  \}

程序输出：true

三、关于LongCache.class

在Long的源代码中，可以找到LongCache内部类的代码：

\[java\]  [view plain][]   [copy][view plain]

1.  **private** **static** **class** LongCache \{  
2.          **private** LongCache()\{\}  
3.    
4.          **static** **final** Long cache\[\] = **new** Long\[-(-128) + 127 + 1\];  
5.    
6.          **static** \{  
7.              **for**(**int** i = 0; i < cache.length; i++)  
8.                  cache\[i\] = **new** Long(i - 128);  
9.          \}  
10.     \}

从LongCache的代码可以很容易看出来，在类初始化的时候，便生成了一个final的static的Long类型数组，数组的范围是-128到127。

Long类型的valueOf方法代码如下：

\[java\]  [view plain][]   [copy][view plain]

1.  **public** **static** Long valueOf(**long** l) \{  
2.          **final** **int** offset = 128;  
3.          **if** (l >= -128 && l <= 127) \{ // will cache  
4.              **return** LongCache.cache\[(**int**)l + offset\];  
5.          \}  
6.          **return** **new** Long(l);  
7.      \}

从以上两个代码中不难发现，当外部程序调用了valueOf方法时，Java先判断欲生成的Long对象是否在LongCache.cache数组的范围内，如果是，则直接返回已经存在cache数组的Long对象引用。根据之前对String类型的研究，这应该是通过重复使用对象的引用，从而实现了较高的性能和较少的内存消耗。此外，经过测试，通过“Long = long”方式生成的Long对象，称为自动封箱，也有相同的逻辑。  
 所以也就不难知道，当实际的long大小超过正数127时，判断两个封装类==时，会返回false。

另外一种情况，通过new方式生成的两个等值的对象，是否会有相同的效果呢？经过测试，是否定的。两次new出来的对象，都是在内存中新划分区域生成的对象，除非重写方法，否则是绝对不能通过==进行比较的。

四、其他内容

1、Integer、Short、Character、Bytes等封装类也有类似的机制；

2、请关注JVM参数：AutoBoxCacheMax

3、请关注Integer内部类IntegerCache的high属性。

———————————————————————————————————————————————————

2014年去某公司笔试的时候遇到这么一道题：

![复制代码][copycode.gif]

public class Test {
        public static void main(String[] args) {
            Integer int1 = Integer.valueOf("100");
            Integer int2 = Integer.valueOf("100");
            System.out.println(int1 == int2);
        }
    }

![复制代码][copycode.gif]

问打印的结果的多少？ 但是我回答的是false, 后来仔细想想应该没有这个简单，就翻了下JDK的源码，发现：

![复制代码][copycode.gif]

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);
        }

![复制代码][copycode.gif]

发现里面另有玄机，多了个IntegerCache类：

![复制代码][copycode.gif]

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() {}
        }

![复制代码][copycode.gif]

原来Integer把-128到127（可调）的整数都提前实例化了。 这就解释了那道面试题的答案，原来你不管创建多少个这个范围内的Integer用ValueOf出来的都是同一个对象。

但是为什么JDK要这么多此一举呢？ 我们仔细想想， 淘宝的商品大多数都是100以内的价格， 一天后台服务器会new多少个这个的Integer， 用了IntegerCache，就减少了new的时间也就提升了效率。同时JDK还提供cache中high值得可配置，

这无疑提高了灵活性，方便对JVM进行优化。

参考Long的源码：

![复制代码][copycode.gif]

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);
            }
        }

![复制代码][copycode.gif]

Long也做了缓存，只是没有提供调整机制, 在Short中类似：

![复制代码][copycode.gif]

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));
            }
        }

![复制代码][copycode.gif]

[view plain]: https://blog.csdn.net/louistech/article/details/51062966#
[copycode.gif]: /images/20220522/e5b431dea60f42da9fbf1cd5212b87c3.png