Java 沉思录(一):自动装箱实现细节

本文同时发布至我的个人博客,点击进入我的个人博客阅读。

本文仅供技术交流与经验分享,转载前请私信告知,转载时请声明原文地址并保留这段文字:https://damondu.github.io/2017/11/02/ruminations-on-java-1/。感谢!

这是<Java 沉思录>系列的第一篇文章。之所以叫<Java 沉思录>,其实是仿照<C++沉思录>的命名。后者几乎是我第一次读到的能够令人激动和恍然大悟的技术书籍,让当时还是编程语言初学者的我印象深刻。虽然本系列大概无法匹及那种高度和深度,但主要动机是相似的,即:记录开发过程中可能会遇到但经常被忽略的一些技术细节与语言陷阱。第一篇文章,从基础的自动装箱谈起。

(一) 自动装箱

Java 的自动装箱为我们提供从基本值类型到引用类型的便捷转化方法:

Integer a = new Integer(1000);//无自动装箱
Integer b = 1000;//自动装箱

(二) 一个陷阱

考虑如下代码:

public class Test {
    public static void main(String[] args) {
        Integer a = 10; //自动装箱生成对象a
        Integer b = 10; //自动装箱生成对象b
        System.out.println("a==b : " + String.valueOf(a==b));
        System.out.println("a.equals(b) : " + String.valueOf(a.equals(b)));
    }
}

这段代码的输出会是什么?

Java 初学者应该都知道如下的事实:

比较两个对象时:

使用==:比较内存地址是否相等

使用equals():比较是否相等

这也是我们在进行引用类型对象之间的比较时,常常使用equals()而不是==的原因,我们一般关注两个对象的值之间的关系而非内存地址之间的比较。

按照这个事实,我们认为 a 与 b 是两个不同的对象,所以他们有不同的内存地址;又由于他们的值相同,所以我们自然而然地预期如下输出:

a==b : false
a.equals(b) : true

然而运行代码,真正的输出有些出乎意料

a==b : true
a.equals(b) : true

这是为什么呢?

(三) 查看源码:自动装箱时 Java 做了什么?

对于以上的输出,我们可以有一个直接的猜想:在进行自动装箱时 Java 通过某种机制,让 a 与 b 这两个引用实例指向了相同的一段内存空间。然而这仅仅是我们的猜测,我们可以从 Java 源码中找到真正的原因。

在这之前,首先我们需要知道一个事实:自动装箱是基于函数valueOf()实现的,即:

//下面两个语句等价:
Integer a = 10;
Integer a = Integer.valueOf(10);

因此我们查看 JDK 中Integer.valueOf()的代码实现:

//jdk edition:6-b14
public static Integer valueOf(int i) {
    final int offset = 128;
    if (i >= -128 && i <= 127) { // must cache
        return IntegerCache.cache[i + offset];
    }
    return new Integer(i);
}

这段代码的意思很好理解:当参数 i 落在区间[-128, 127] 时,返回值为IntegerCache.cache[i + offset],否则才返回Integer(i)这意味着并不是每次自动装箱都会创建一个新的Integer实例。但是,Java 如何实现两个引用示例指向相同地址空间呢?这与IntegerCache类有关:

//jdk edition:6-b14
private static class IntegerCache {
    private IntegerCache(){}

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

    static {
        for(int i = 0; i < cache.length; i++)
        cache[i] = new Integer(i - 128);
    }
}

可以看出IntegerCache内部维护了一个静态数组作为缓存,当我们自动装箱一个值在[-128, 127]之间的int时,它将直接返回静态数组里的对应值,这也就是为什么上面的 a 与 b 会共用相同的内存地址,因为从底层看,他们其实是同一个对象

(四) 进一步思考

为什么 Java 要这样设计?带来的好处是什么?

IntegerCache及其背后的缓存机制,是从 Java 5 开始引入的一种缓存策略。显然,[-128, 127]区间之间的值是在编程中高频出现的值,引入这种缓存机制意味着在多次使用中避免了多次重复的创建与销毁对象所带来的开销,本质上是通过“复用”来节省内存,提高运行速度。

缺陷与后续版本中的优化

考虑上述代码中的这部分代码:

if (i >= -128 && i <= 127) { // must cache
    return IntegerCache.cache[i + offset];
}

这样的代码直接其实存在一个 Magic Number 的问题,即直接将 -128,127这样的数字嵌入代码,这样的代码其实是 bad smell 的。其实在 Java 7 以后的版本以及解决了这个问题:

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

需要注意的是默认区间仍然是[-128, 127],但是最大值可以通过设定 JVM 的启动参数来修改,以达到修改缓存空间大小的目的。

另外的一些类的自动装箱也存在缓存机制

在自动装箱的过程中,除了IntegerByteShortLongCharacter也存在缓存机制(缓存区间及大小不尽相同),而DoubleFloat则没有对应的缓存机制。

(五) 小结

对于严格的对象处理(例如要维护一个Integer的哈希映射时),我们要谨慎使用自动装箱,因为使用自动装箱往往会导致我们会从字面上认为我们创建了多个实例,而实际上他们使用同一个实例。在这种情况下,更好的选择是使用传统的构造器来创建对象。


参考网站:

  1. Grepcode:http://grepcode.com/
  2. 理解 Java Integer的缓存策略:http://www.importnew.com/18884.html
  3. How large is the Integer cache? - Stackoverflow:https://stackoverflow.com/questions/15052216/how-large-is-the-integer-cache
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 215,463评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,868评论 3 391
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,213评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,666评论 1 290
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,759评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,725评论 1 294
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,716评论 3 415
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,484评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,928评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,233评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,393评论 1 345
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,073评论 5 340
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,718评论 3 324
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,308评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,538评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,338评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,260评论 2 352

推荐阅读更多精彩内容

  • 1. Java基础部分 基础部分的顺序:基本语法,类相关的语法,内部类的语法,继承相关的语法,异常的语法,线程的语...
    子非鱼_t_阅读 31,620评论 18 399
  • Java8张图 11、字符串不变性 12、equals()方法、hashCode()方法的区别 13、...
    Miley_MOJIE阅读 3,699评论 0 11
  • 自动装箱和拆箱从Java 1.5开始引入,目的是将原始类型值转自动地转换成对应的对象。自动装箱与拆箱的机制可以让我...
    codersm阅读 418评论 0 0
  • 多么想一切重头再来,对于婚姻,我水土不服,身心不协调…好似一切都不按着自己的预期,一切都背道而驰
    谁也不想述说的话阅读 109评论 0 0
  • 如果我会自杀,那不是在别的天气,而一定是雨天。 想着自己为什么会来到这里——我是谁,我在哪儿,我要干什么。 无论自...
    彩澈阅读 125评论 0 0