當(dāng)我們將一種類(lèi)型的對(duì)象轉(zhuǎn)換為另一種類(lèi)型時(shí)，會(huì)產(chǎn)生額外的開(kāi)銷(xiāo)嗎？還是編譯器可以解決所有問(wèn)題，并且在運(yùn)行時(shí)沒(méi)有成本？這是一般的事情，還是有不同的情況？例如，假設(shè)我們有一個(gè)Object []數(shù)組，其中每個(gè)元素可能具有不同的類(lèi)型。但是我們始終可以肯定地知道，例如，元素0是Double，元素1是String。（我知道這是一個(gè)錯(cuò)誤的設(shè)計(jì)，但是讓我們假設(shè)我必須這樣做。）Java的類(lèi)型信息是否仍在運(yùn)行時(shí)保留？還是編譯后一切都被遺忘了，如果我們執(zhí)行（Double）elements [0]，我們將僅跟隨指針并將這8個(gè)字節(jié)解釋為雙精度，無(wú)論是什么？我不清楚在Java中如何完成類(lèi)型。如果您對(duì)書(shū)籍或文章有任何建議，也請(qǐng)多謝。
3 回答
慕桂英3389331
TA貢獻(xiàn)2036條經(jīng)驗(yàn) 獲得超8個(gè)贊
有2種類(lèi)型的轉(zhuǎn)換：
隱式轉(zhuǎn)換，當(dāng)您將類(lèi)型從類(lèi)型轉(zhuǎn)換為更寬泛的類(lèi)型時(shí)，它是自動(dòng)完成的，并且沒(méi)有開(kāi)銷(xiāo)：
String s = "Cast";
Object o = s; // implicit casting
從較寬的類(lèi)型轉(zhuǎn)換為較窄的類(lèi)型時(shí)，顯式轉(zhuǎn)換。對(duì)于這種情況，您必須顯式使用如下所示的強(qiáng)制轉(zhuǎn)換：
Object o = someObject;
String s = (String) o; // explicit casting
在第二種情況下，運(yùn)行時(shí)會(huì)產(chǎn)生開(kāi)銷(xiāo)，因?yàn)楸仨殭z查這兩種類(lèi)型，并且在強(qiáng)制轉(zhuǎn)換不可行的情況下，JVM必須拋出ClassCastException。
摘自JavaWorld：鑄造成本
鑄造用類(lèi)型之間的轉(zhuǎn)換-特別是引用類(lèi)型之間，鑄造操作中，我們有興趣在這里的類(lèi)型。
上位操作（在Java語(yǔ)言規(guī)范中也稱(chēng)為擴(kuò)展轉(zhuǎn)換）將子類(lèi)引用轉(zhuǎn)換為祖先類(lèi)引用。這種轉(zhuǎn)換操作通常是自動(dòng)的，因?yàn)樗偸前踩?，并且可以由編譯器直接實(shí)現(xiàn)。
向下轉(zhuǎn)換操作（在Java語(yǔ)言規(guī)范中也稱(chēng)為縮小轉(zhuǎn)換）將祖先類(lèi)引用轉(zhuǎn)換為子類(lèi)引用。由于Java要求在運(yùn)行時(shí)檢查強(qiáng)制轉(zhuǎn)換以確保其有效，因此此強(qiáng)制轉(zhuǎn)換操作會(huì)產(chǎn)生執(zhí)行開(kāi)銷(xiāo)。如果引用的對(duì)象不是強(qiáng)制轉(zhuǎn)換的目標(biāo)類(lèi)型的實(shí)例或該類(lèi)型的子類(lèi)的實(shí)例，則不允許嘗試進(jìn)行強(qiáng)制轉(zhuǎn)換，并且必須拋出java.lang.ClassCastException。
滄海一幻覺(jué)
TA貢獻(xiàn)1824條經(jīng)驗(yàn) 獲得超5個(gè)贊
對(duì)于Java的合理實(shí)現(xiàn)：
每個(gè)對(duì)象都有一個(gè)標(biāo)頭，除其他外，標(biāo)頭包含一個(gè)指向運(yùn)行時(shí)類(lèi)型的指針（例如Double或String，但永遠(yuǎn)不能是CharSequence或AbstractList）。假設(shè)運(yùn)行時(shí)編譯器（在Sun情況下通常為HotSpot）無(wú)法靜態(tài)確定類(lèi)型，則生成的機(jī)器代碼需要執(zhí)行一些檢查。
首先，需要讀取指向運(yùn)行時(shí)類(lèi)型的指針。無(wú)論如何，這對(duì)于在類(lèi)似情況下調(diào)用虛擬方法是必需的。
對(duì)于強(qiáng)制轉(zhuǎn)換為類(lèi)類(lèi)型，在您命中之前java.lang.Object，確切知道有多少個(gè)超類(lèi)，因此可以從類(lèi)型指針（實(shí)際上是HotSpot中的前八個(gè)）以恒定的偏移量讀取類(lèi)型。同樣，這類(lèi)似于讀取虛擬方法的方法指針。
然后，讀取值僅需要與預(yù)期的強(qiáng)制類(lèi)型轉(zhuǎn)換進(jìn)行比較。根據(jù)指令集的體系結(jié)構(gòu)，另一條指令將需要在錯(cuò)誤的分支上分支（或出錯(cuò)）。諸如32位ARM之類(lèi)的ISA具有條件指令，并且可能能夠使悲傷路徑通過(guò)快樂(lè)路徑。
由于接口的多重繼承，接口更加困難。通常，對(duì)接口的最后兩個(gè)強(qiáng)制類(lèi)型轉(zhuǎn)換將在運(yùn)行時(shí)類(lèi)型中進(jìn)行緩存。在早期（十多年前），接口有點(diǎn)慢，但這已不再重要。
希望您能看到這種情況與性能無(wú)關(guān)。您的源代碼更為重要。在性能方面，您的方案受到的最大打擊可能是由于在各處跟蹤對(duì)象指針而導(dǎo)致的高速緩存未命中（類(lèi)型信息當(dāng)然很常見(jiàn)）。
HUX布斯
TA貢獻(xiàn)1876條經(jīng)驗(yàn) 獲得超6個(gè)贊
例如，假設(shè)我們有一個(gè)Object []數(shù)組，其中每個(gè)元素可能具有不同的類(lèi)型。但是我們始終可以肯定地知道，例如，元素0是Double，元素1是String。（我知道這是一個(gè)錯(cuò)誤的設(shè)計(jì)，但是讓我們假設(shè)我必須這樣做。）
編譯器不會(huì)記錄數(shù)組中各個(gè)元素的類(lèi)型。它只是檢查每個(gè)元素表達(dá)式的類(lèi)型是否可分配給數(shù)組元素類(lèi)型。
Java的類(lèi)型信息是否仍在運(yùn)行時(shí)保留？還是編譯后一切都被遺忘了，如果我們執(zhí)行（Double）elements [0]，我們將僅跟隨指針并將這8個(gè)字節(jié)解釋為雙精度，無(wú)論是什么？
在運(yùn)行時(shí)會(huì)保留一些信息，但不會(huì)保留各個(gè)元素的靜態(tài)類(lèi)型。您可以通過(guò)查看類(lèi)文件格式來(lái)說(shuō)明這一點(diǎn)。
從理論上講，JIT編譯器可以使用“轉(zhuǎn)義分析”來(lái)消除某些分配中不必要的類(lèi)型檢查。但是，按照您建議的程度執(zhí)行此操作將超出實(shí)際優(yōu)化的范圍。分析單個(gè)元素類(lèi)型的收益將太小。
此外，人們不應(yīng)該這樣寫(xiě)應(yīng)用程序代碼。
添加回答
舉報(bào)
0/150
提交
取消