自动装箱规则，引擎盖下是什么？

我遇到了一个非常奇怪的行为，后来found to be a part of java specs。让我把相关的代码从上述发布自动装箱规则，引擎盖下是什么？

Integer a = 1000, b = 1000; 
     System.out.println(a == b); //Prints false 

     Integer c = 100, d = 100; 
     System.out.println(c == d); //Prints true

此颇为相似字符串文字池但是有一个例外，有它的限制。让我再次引用Jon Skeet对前面提到的帖子的回复。

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

现在我的问题是，因为我们没有字符串文字池的限制，为什么不相同的其他类型？没有这个的设计/性能考虑是什么？有没有可配置的方法？

来源

2011-12-29 Santosh

是的，自从Java 5.0（2004）以来，它就一直存在。 ;） – 2011-12-29 13:39:57

虽然文字实际上是原始文字，但您可以为包装类型设置某种“文字池”。但为什么要麻烦？有趣的情况是变量变量。当人们试图用常量值测试东西时，让'=='有不同的工作方式，可能不会成为后遗症。 – 2011-12-29 13:49:51

Is there any way its configurable?

阅读我的回答here。

来源

2011-12-29 13:41:19

+1：冒着让它成为报价而不是代码块的自由。 ;） – 2011-12-29 13:42:58

谢谢！这应该是另一个隐藏的Java宝石！它可能是一个涉及很多整数运算的游戏转换器。 – Santosh 2011-12-29 14:09:34

since we do not have a limit to the String Literal Pool, why not the same for other types ?

因为一组Java类中的字符串文字的数量是有限的，并且可能相当低。相反，动态装箱的Integer实例的数量没有限制（嗯，有2^32个可能的值）。缓存它们都会消耗千兆字节的内存，并且会适得其反。

而且我还没有谈论所有其他类型：字符，短，长，等

这个简单的程序会导致OutOfMemoryError错误：

for (int i = 0; i < Integer.MAX_VALUE; i++) { 
    Integer.valueOf(i); 
}

来源

2011-12-29 13:52:54

从统计数字上看，低的数字出现的频率比大的要多得多。正数出现的次数多于负数（全部0到n循环）。 128对我来说有点低，但1024会覆盖我99.9％的数字。我在数据库支持的企业系统中工作，我永远不会从数据库获取超过1024行的数据。所以我的列表中没有一个超过这个大小，并且循环它们是所使用数字的大部分（如果我使用数字的话）。无论如何，我使用BigDecimal或BigInteger表示长ID，并且只有其他长数字是可搜索界面的UNIDs，它们是最终的和长的。

我认为大多数开发者缓存大型Integer对象并不值得。此外，您应该使用equals metod而不是==。除非我正在处理基元，否则我从不使用==。

来源

2011-12-29 13:53:23

自动装箱规则，引擎盖下是什么？

回答

相关问题