1. ホーム
  2. java

[解決済み] Javaです。整数の等号と==の比較

2022-04-20 02:17:22

質問

Java 1.5では、ほとんどの場合、以下のように交換することができます。 Integer とは int を多くの場面で使用することができます。

しかし、私のコードに潜在的な欠陥が見つかり、少し驚いています。

次のようなコードです。

Integer cdiCt = ...;
Integer cdsCt = ...;
...
if (cdiCt != null && cdsCt != null && cdiCt != cdsCt)
    mismatch = true;

は、どのような状況か判断できませんが、値が等しいときに誤ってmismatchを設定しているように見えました。Eclipseでブレークポイントを設定すると Integer の値は両方とも137で、ブーリアン式をインスペクトしたらfalseと表示されましたが、それを踏み越えるとmismatchがtrueに設定されていました。

条件を変更する。

if (cdiCt != null && cdsCt != null && !cdiCt.equals(cdsCt))

は問題を修正しました。

なぜこのようなことが起こったのか、どなたか教えていただけませんか?今のところ、自分のPCのローカルホストでしかこの挙動を見たことがありません。この特別なケースでは、コードは約20の比較を成功裏に通過しましたが、2つの比較で失敗しました。この問題は一貫して再現可能でした。

もしこれが一般的な問題であれば、私たちの他の環境(devとtest)でもエラーが発生するはずですが、今のところ、このコードスニペットを実行する数百のテストの後、誰もこの問題を報告していません。

を使用するのはやはり正当ではないのでしょうか? == を比較するために、2つの Integer の値ですか?

以下のすべての素晴らしい回答に加えて、以下のstackoverflowのリンクにかなりの追加情報があります。本当は私の最初の質問に答えてくれるはずだったのですが、私が質問の中でautoboxingに言及しなかったため、選択された候補に表示されなかったのです。

なぜコンパイラやJVMは、オートボックスを「ただ動く」ようにできないのですか?

解決方法は?

JVMはInteger値をキャッシュしています。そのため == は-128から127の間の数に対してのみ機能します。

参考にしてください。 #Immutable_Objects_.2F_Wrapper_Class_Caching