Java整數池。為什么？

它被稱為Flyweight模式，用于最小化內存使用。

這些數字很可能會被重復使用，并且類似autoBox的類型Integer是不可變的（請注意，這樣做不僅是針對Integer）。緩存它們可以使實例不多，并且也減少了GC（垃圾收集）的工作。

JLS在5.1.7中對此進行了介紹。裝箱轉換專門通過說：

如果裝箱的值p為true，false，字節或 u0000到u007f范圍內的char或-128到127（含）之間的整數或短數，則令r1和r2為p的任何兩次拳擊轉換。r1 == r2總是這樣。

理想情況下，將給定的原始值p裝箱將始終產生相同的參考。實際上，使用現有的實現技術可能不可行。以上規則是務實的妥協。上面的最后一句要求始終將某些通用值裝在無法區分的對象中。該實現可以懶惰地或急切地緩存它們。對于其他值，此公式不允許對程序員方面的帶框值的身份進行任何假設。這將允許（但不要求）共享部分或全部這些引用。

這樣可以確保在最常見的情況下，行為將是理想的，而不會造成不必要的性能損失，尤其是在小型設備上。例如，較少內存限制的實現可能會緩存所有char和short值，以及-32K到+32K范圍內的int和long值。

我到處都讀到過，當您在Java中定義介于-128到127之間的Integer時，它不會創建新對象，而是返回已經創建的對象。

除了讓新手程序員比較Integer對象==以查看它們是否具有相同的數字外，我看不到這樣做的任何意義，但是我認為這很糟糕，因為確保他們認為可以將任何Integer對象與進行比較==，并且還在教學在任何編程語言中都不好的做法：將兩個“不同”對象的內容與進行比較==。

這樣做有其他原因嗎？還是在設計語言（以我的觀點）（如JavaScript中的可選分號）時只是一個錯誤的決定？

編輯：我在這里看到他們解釋行為：為什么Integer常量池的行為在127發生變化？

我在問為什么他們設計它具有這種行為，而不是為什么會發生這種行為。