コード :
Integer a1 = 100;
Integer a2 = 100;
System.out.println(a1 == a2); // true
Integer b1 = new Integer(100);
Integer b2 = new Integer(100);
System.out.println(b1 == b2); // false
Integer c1 = 150;
Integer c2 = 150;
System.out.println(c1 == c2); // false
AutoBoxing を使用すると、-128 から 127 までの値が同じ Integer オブジェクトを参照しているように見える Java 設計。これにより、最初のコード フラグメントと最後のコード フラグメントの結果が異なります。
私の質問は次のとおりです。なぜJavaはこのように設計されているのですか、何か利点はありますか?
単純な理論的根拠は、すでに作成され、ボックス化に使用できる一連の整数があると便利/効率的であるということです。アプリケーションがボックス化された整数を必要とする場合、それらは特定の範囲 (たとえば 1 など) になる可能性が非常に高くなります。それらが -127/128 までボックス化されているという事実は、膨大な数の整数を事前にボックス化しなくても利益をもたらす可能性があることに基づいた単純な設計ヒューリスティックです。
多くの数値演算が前述の間隔で int 値を使用しているため、これは一種の最適化です。
整数は、-128 から 127 までの値に対してキャッシュされます。これは、Java 言語仕様の一部です。
ボックス化された値 p が true、false、\u0000 ～ \u007f の範囲のバイト、または char、または -128 ～ 127 (両端を含む) の int または short の数値である場合、r1 および r2 を次の結果とします。 p の任意の 2 つのボクシング変換。r1 == r2 は常にそうです。
その動作の理由は同じセクションに記載されています。デフォルトの動作では、==比較は常に true を返しますが、パフォーマンス上の理由からその範囲に制限されています。
理想的には、指定されたプリミティブ値 p をボックス化すると、常に同一の参照が生成されます。実際には、これは既存の実装技術を使用して実現できない場合があります。[...]
この [範囲の制限] により、特に小さなデバイスでは、過度のパフォーマンス ペナルティを課すことなく、ほとんどの一般的なケースで、動作が目的の動作になることが保証されます。メモリ制限の少ない実装では、たとえば、すべての char 値と short 値、および -32K から +32K の範囲の int 値と long 値をキャッシュする場合があります。