Java整数池。为什么？ [英] Java Integer pool. Why?

问题描述

我到处都读到，当你在Java中定义-128到127之间的整数时，它不会创建一个新对象，而是返回一个已创建的对象。

I've read everywhere that when you define an Integer between -128 to 127 in Java, instead of creating a new object it returns an object already created.

除了让新手程序员将Integer对象与 == 进行比较以查看它们是否是相同的数字之外，我没有看到这样做的任何意义，但我认为这很糟糕，因为确定他们认为他们可以将任何整数与 == 进行比较，并且还在教授任何编程语言的不良做法：将两个不同对象的内容与<$进行比较c $ c> == 。

I don't see any point of doing this other than letting newbie programmers compare Integer objects with == to see if they are the same number, but I think this is bad because sure they think that they can compare any Integer with ==, and also is teaching a bad practice in any programming language: comparing the content of two 'different' objects with ==.

为什么要这样做还有其他原因吗？或者在设计语言时（在我看来）像JavaScript中的可选分号一样，这只是一个错误的决定吗？

Is there any other reason on why this is done? Or is it just a bad decision when designing the language (In my point of view) like optional semicolon in JavaScript?

编辑：我在这里看到他们解释了这个行为： 为什么整数的行为不变池更改为127？

I see here that they explain the behaviour: Why does the behavior of the Integer constant pool change at 127?

我问他们为什么设计它才能有这种行为，而不是为什么会发生这种情况。

I'm asking why they designed it to have this behaviour, and not why is this behaviour happening.

推荐答案

它被称为 Flyweight模式和用于最小化内存使用。

It's called the Flyweight pattern and is used to minimize memory usage.

这些数字很可能被重复使用，而 Integer 等自动装箱类型是不可变的（注意这是完成的）不仅仅是整数）。缓存它们使得它没有很多实例并且减少了GC（垃圾收集）工作。

Those numbers are very likely to be used repeatedly, and autobox types like Integer are immutable (note this is done not just for Integer). Caching them makes it so there aren't lots of instances and reduces GC (Garbage Collection) work as well.

JLS涵盖了 5.1.7。拳击转换具体说：

The JLS covers this in 5.1.7. Boxing Conversion specifically by saying:

如果被加框的值是真，假，一个字节或一个字符范围\\\到\ u007f，或介于-128和127（含）之间的int或短数，然后让r1和r2为p的任意两次装箱转换的结果。总是这样的情况是r1 == r2。

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

理想情况下，装箱给定的原始值p总会产生相同的参考。实际上，使用现有的实现技术可能不可行。上述规则是务实的妥协。上面的最后一个条款要求将某些常见值装入无法区分的对象中。实现可以懒惰地或急切地缓存这些。对于其他值，此公式不允许对程序员的盒装值的身份进行任何假设。这将允许（但不要求）共享部分或全部这些引用。

Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

这可以确保在大多数情况下，行为将是所需的行为，而不会强加不当的性能损失，特别是在小型设备上。例如，较少内存限制的实现可以缓存所有char和short值，以及-32K到+ 32K范围内的int和long值。

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.

这篇关于Java整数池。为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！