如果使用字符串常量，我們的行為是Java編譯器將使用相同的實(shí)例 String a = "abc";
String b = "abc";
//a == b
String c = new String("abc");
// c is a brand new object on the heap;為什么java編譯器不優(yōu)化新的String并用等效賦值替換它？是否有一些深層次的設(shè)計(jì)決定，或者只是巧合？我們是否可以期望不同的JVM或編譯器更具攻擊性，并且實(shí)際上用一個(gè)眾所周知的靜態(tài)對(duì)象替換不可變對(duì)象的堆實(shí)例？雖然String是最臭名昭著的例子，但我們可以為Integer提供相同的行為。
2 回答
四季花海
TA貢獻(xiàn)1811條經(jīng)驗(yàn) 獲得超5個(gè)贊
首先，String(String)“復(fù)制”構(gòu)造函數(shù)源于最初的日子并且是異常的。也許是因?yàn)?code>String.intern()其中有一些復(fù)制預(yù)防，以及常量"..."。它永遠(yuǎn)不需要，因?yàn)镾tring是一個(gè)不可變final類。
因?yàn)?code>Integer有Integer.valueOf(int)使用瞬時(shí)的緩存，默認(rèn)情況下保持-128到127。
盡管涉及非常稱職的編譯器開發(fā)團(tuán)隊(duì)，但java字節(jié)碼編譯器編譯非常幼稚。但是，在機(jī)器代碼的字節(jié)代碼上，可能會(huì)發(fā)生一些不錯(cuò)的事情。例如，對(duì)象不是在堆上創(chuàng)建的，而是在堆棧上創(chuàng)建的。
簡(jiǎn)單編譯至少不太可能在智能技巧的數(shù)據(jù)流分析中包含錯(cuò)誤。（這也是提供良好代碼風(fēng)格的好理由。）
一個(gè)例子：
List<String> list = ...String[] array1 = list.toArray(new String[0]);String[] array2 = list.toArray(new String[list.size()]);
toArray需要一個(gè)實(shí)際的數(shù)組實(shí)例，因?yàn)轭愋筒脸?code>List list不再知道它包含Strings。
歷史上，作為優(yōu)化，可以傳遞適合大小的數(shù)組（這里是版本list.size()），然后返回。更優(yōu)化和更快，仍然有一些風(fēng)格檢查標(biāo)記第一個(gè)版本。然而實(shí)際上第一個(gè)版本更快，因?yàn)槭褂昧肆硪粋€(gè)數(shù)組字節(jié)cdoe實(shí)例化，并且array1將更快地生成。
關(guān)于某些數(shù)字劃分的相同故事。在C中，有許多編譯器優(yōu)化涉及更快的移位。這是（部分）在Java中以字節(jié)代碼完成的，用于機(jī)器代碼編譯，這是這些優(yōu)化的更合理的地方。
我個(gè)人認(rèn)為優(yōu)化字節(jié)碼編譯器會(huì)很好，也許適合大學(xué)項(xiàng)目。但是，對(duì)于代碼改進(jìn)而言，可能不合理，例如不使用.equals枚舉值。
添加回答
舉報(bào)
0/150
提交
取消