在尋找==Java 中邏輯等于如何工作的解釋時，答案總是類似于：對于圖元，它返回圖元是否具有相同的值（這包括將圖元與其 WrapperObject 進(jìn)行比較，因為 WrapperObject 會自動拆箱為圖元）。對于對象，它返回它們是否代表堆上的同一個對象。但這些解釋似乎都暗示這是兩種不同的東西，它們的==行為不同取決于你是在比較對象還是基元。在我看來，它們實際上必須是完全相同的東西：從 Stack 中取出兩個變量并比較它們的值。改變的不是 的行為==，而是它所比較的值所代表的內(nèi)容。如果你比較的東西是原語，那么 Stack 上的值就是原語本身的值。如果您正在比較對象，那么堆棧上的值就是引用的值（因此是對象在堆上的地址）。我是不是誤解了什么，或者==在所有情況下都表現(xiàn)得一樣？如果你能給我指出這在幕后是如何工作的文檔，那就加分了。
2 回答
慕田峪4524236
TA貢獻(xiàn)1875條經(jīng)驗 獲得超5個贊
在 Java 語言級別，==運(yùn)算符語義以獨(dú)立于實現(xiàn)的方式指定（在JLS 15.21中）。嚴(yán)格來說，您不能從 JLS 文本中推斷出“幕后”實現(xiàn)細(xì)節(jié)。您只能說，任何符合規(guī)范的實現(xiàn)都==必須以某種方式運(yùn)行。
我假設(shè)我們正在談?wù)搨鹘y(tǒng)的 JVM，其中引用的實際機(jī)器表示是機(jī)器地址。可以通過其他方式實現(xiàn)引用；例如，使用某種間接尋址機(jī)制，例如PIDLAM。
在字節(jié)碼級別，有許多不同的==字節(jié)碼指令實現(xiàn)了依賴于類型（int，或引用）的邏輯long。但是，比較的語義是相似的。一旦字節(jié)碼被驗證為類型安全的，為了在硬件級別進(jìn)行比較，就可以對整數(shù)和地址進(jìn)行相同的處理。==
在硬件（機(jī)器指令）級別，==原始整數(shù)類型和非原始值的工作方式相同。在這兩種情況下，它將執(zhí)行一條機(jī)器指令，該指令比較從寄存器或內(nèi)存（堆或堆棧）中獲取的兩個“字”。
JLS 指定的==forfloat和的語義double有點(diǎn)不同，因為特殊值（無窮大和非數(shù)字值）需要特殊處理。例如：NaN == NaN 是false.?另請參閱 IEEE 754 浮點(diǎn)標(biāo)準(zhǔn)。
為此有不同的字節(jié)碼，并且在硬件級別使用的指令與整數(shù)和參考案例中使用的指令不同。（特殊值的處理通常在浮動硬件中處理。）
JLS 指定了==for?boolean、和 is的語義byte，以便在比較它們之前將值提升為另一種類型（、或） 。如果操作數(shù)具有不同的（未裝箱的）類型，則提升也會發(fā)生在其他情況下。?shortcharintlongfloatdouble
此外，如果一個（但不是兩個?。┎僮鲾?shù)被裝箱，則會發(fā)生拆箱。如果兩個操作數(shù)都被裝箱，則為==引用比較。
總結(jié)以上...
我是不是誤解了什么，或者 == 實際上在所有情況下都表現(xiàn)得一樣？
不，如果您包括浮點(diǎn)類型，以及原始加寬和拆箱的注意事項，則不會。
如果你能給我指出這在幕后是如何工作的文檔，那就加分了。
沒有關(guān)于此的官方（Oracle）公共文檔。JLS 和 JVM 規(guī)范沒有規(guī)定實現(xiàn)策略。
Helenr
TA貢獻(xiàn)1780條經(jīng)驗 獲得超4個贊
我理解你的解釋，并且給出某些術(shù)語的定義是正確的。但它不符合 Java 談?wù)搶ο蠛驮Z的方式。
在 Java 中“引用”對象的想法被嚴(yán)重低估了；我認(rèn)為有可能成為一名“Java 程序員”卻并不真正了解什么是引用。您可以記住它產(chǎn)生影響的規(guī)則——“==”運(yùn)算符，將參數(shù)傳遞給方法——而不理解它是如何實現(xiàn)的，或者可能是如何實現(xiàn)的。
所以我認(rèn)為許多使用 Java 編程的人會感到困惑，因為說 == “在所有情況下都表現(xiàn)相同”，因為這涉及太多“幕后”知識。Java 不鼓勵您（或要求您）在那種程度上“深入了解”。
添加回答
舉報
0/150
提交
取消