なぜ Java 開発者は依然としてラッパー クラスよりもプリミティブ型を好むのでしょうか?

Java におけるプリミティブ型の永続性を明らかにする

Java 5 でのオートボックス化とアンボックス化の導入にもかかわらず、プリミティブは引き続きその地位を維持しています。多くのプロジェクト。これにより、なぜ開発者は java.lang.Integer.

などの対応するオブジェクトよりもプリミティブ型を好むのかという疑問が生じます。Joshua Bloch が独創的な著書「Effective Java」で概説しているように、過剰なオブジェクトの作成は危険な可能性があります。パフォーマンスに悪影響を及ぼします。次のコードはこれを示しています。

public static void main(String[] args) {
    Long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

このコードは Long オブジェクトを使用しており、実行には約 43 秒かかります。ただし、Long をそのプリミティブ型 Long に変換すると、実行時間はわずか 6.8 秒に短縮されます。

もう 1 つの考慮事項は、Java にはネイティブ値の等価性が存在しないことです。オブジェクトの等価性は、equals() メソッドを使用して実行されますが、プリミティブ型では == 演算子を使用します。これにより、等価性を確認するためのより簡潔で効率的な方法が提供されます。次の例を考えてみましょう。

class Biziclop {
    public static void main(String[] args) {
        System.out.println(new Integer(5) == new Integer(5));
        System.out.println(new Integer(500) == new Integer(500));

        System.out.println(Integer.valueOf(5) == Integer.valueOf(5));
        System.out.println(Integer.valueOf(500) == Integer.valueOf(500));
    }
}

出力は、[-128; 127]、JVM キャッシュのため、プリミティブ型は等価性チェックで true を返します。ただし、この範囲を超えるとオブジェクトが作成され、誤った結果が生じます。このキャッシュ動作により、プリミティブ型が回避する等価性チェックに不整合が生じる可能性があります。

したがって、オートボックス化とアンボックス化は利便性をもたらしますが、プリミティブ型のパフォーマンス上の利点と効率的な等価性チェックにより、Java 開発では引き続き実行可能な選択肢となります。 Java 5 以降を必要とするプロジェクトでも。

以上がなぜ Java 開発者は依然としてラッパー クラスよりもプリミティブ型を好むのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。