字串連線誤用
錯誤的寫法:
String s = "";
for (Person p : persons) {
s += ", " + p.getName();
}
s = s.substring(2); //remove first comma
複製程式碼
正確的寫法:
StringBuilder sb = new StringBuilder(persons.size() * 16); // well estimated buffer
for (Person p : persons) {
if (sb.length() > 0) sb.append(", ");
sb.append(p.getName);
}
複製程式碼
錯誤的使用StringBuffer
錯誤的寫法:
StringBuffer sb = new StringBuffer();
sb.append("Name: ");
sb.append(name + '\n');
sb.append("!");
...
String s = sb.toString();
複製程式碼
問題在第三行,append char比String效能要好,另外就是初始化StringBuffer沒有指定size,導致中間append時可能重新調整內部陣列大小。如果是JDK1.5最好用StringBuilder取代StringBuffer,除非有執行緒安全的要求。還有一種方式就是可以直接連線字串。缺點就是無法初始化時指定長度。
正確的寫法:
StringBuilder sb = new StringBuilder(100);
sb.append("Name: ");
sb.append(name);
sb.append("\n!");
String s = sb.toString();
複製程式碼
或者這樣寫:
String s = "Name: " + name + "\n!";
複製程式碼
測試字串相等性
錯誤的寫法:
if (name.compareTo("John") == 0) ...
if (name == "John") ...
if (name.equals("John")) ...
if ("".equals(name)) ...
複製程式碼
上面的程式碼沒有錯,但是不夠好。compareTo不夠簡潔,==原義是比較兩個物件是否一樣。另外比較字元是否為空,最好判斷它的長度。
正確的寫法:
if ("John".equals(name)) ...
if (name.length() == 0) ...
if (name.isEmpty()) ...
複製程式碼
數字轉換成字串
錯誤的寫法:
"" + set.size()
new Integer(set.size()).toString()
複製程式碼
正確的寫法:
String.valueOf(set.size())
複製程式碼
利用不可變物件(Immutable)
錯誤的寫法:
zero = new Integer(0);
return Boolean.valueOf("true");
複製程式碼
正確的寫法:
zero = Integer.valueOf(0);
return Boolean.TRUE;
複製程式碼
請使用XML解析器
錯誤的寫法:
int start = xml.indexOf("<name>") + "<name>".length();
int end = xml.indexOf("</name>");
String name = xml.substring(start, end);
複製程式碼
正確的寫法:
SAXBuilder builder = new SAXBuilder(false);
Document doc = doc = builder.build(new StringReader(xml));
String name = doc.getRootElement().getChild("name").getText();
複製程式碼
請使用JDom組裝XML
錯誤的寫法:
String name = ...
String attribute = ...
String xml = "<root>"
+"<name att=""+ attribute +"">"+ name +"</name>"
+"</root>";
正確的寫法:
Element root = new Element("root");
root.setAttribute("att", attribute);
root.setText(name);
Document doc = new Documet();
doc.setRootElement(root);
XmlOutputter out = new XmlOutputter(Format.getPrettyFormat());
String xml = out.outputString(root);
複製程式碼
XML編碼陷阱
錯誤的寫法:
String xml = FileUtils.readTextFile("my.xml");
複製程式碼
因為xml的編碼在檔案中指定的,而在讀檔案的時候必須指定編碼。另外一個問題不能一次就將一個xml檔案用String儲存,這樣對記憶體會造成不必要的浪費,正確的做法用InputStream來邊讀取邊處理。為了解決編碼的問題, 最好使用XML解析器來處理。
未指定字元編碼
錯誤的寫法:
Reader r = new FileReader(file);
Writer w = new FileWriter(file);
Reader r = new InputStreamReader(inputStream);
Writer w = new OutputStreamWriter(outputStream);
String s = new String(byteArray); // byteArray is a byte[]
byte[] a = string.getBytes();
複製程式碼
這樣的程式碼主要不具有跨平臺可移植性。因為不同的平臺可能使用的是不同的預設字元編碼。
正確的寫法:
Reader r = new InputStreamReader(new FileInputStream(file), "ISO-8859-1");
Writer w = new OutputStreamWriter(new FileOutputStream(file), "ISO-8859-1");
Reader r = new InputStreamReader(inputStream, "UTF-8");
Writer w = new OutputStreamWriter(outputStream, "UTF-8");
String s = new String(byteArray, "ASCII");
byte[] a = string.getBytes("ASCII");
複製程式碼
未對資料流進行快取
錯誤的寫法:
InputStream in = new FileInputStream(file);
int b;
while ((b = in.read()) != -1) {
...
}
複製程式碼
上面的程式碼是一個byte一個byte的讀取,導致頻繁的本地JNI檔案系統訪問,非常低效,因為呼叫本地方法是非常耗時的。最好用BufferedInputStream包裝一下。曾經做過一個測試,從/dev/zero下讀取1MB,大概花了1s,而用BufferedInputStream包裝之後只需要60ms,效能提高了94%! 這個也適用於output stream操作以及socket操作。
正確的寫法:
InputStream in = new BufferedInputStream(new FileInputStream(file));
複製程式碼
無限使用heap記憶體
錯誤的寫法:
byte[] pdf = toPdf(file);
複製程式碼
這裡有一個前提,就是檔案大小不能講JVM的heap撐爆。否則就等著OOM吧,尤其是在高併發的伺服器端程式碼。最好的做法是採用Stream的方式邊讀取邊儲存(本地檔案或database)。
正確的寫法:
File pdf = toPdf(file);
複製程式碼
另外,對於伺服器端程式碼來說,為了系統的安全,至少需要對檔案的大小進行限制。
不指定超時時間
錯誤的程式碼:
Socket socket = ...
socket.connect(remote);
InputStream in = socket.getInputStream();
int i = in.read();
複製程式碼
這種情況在工作中已經碰到不止一次了。個人經驗一般超時不要超過20s。這裡有一個問題,connect可以指定超時時間,但是read無法指定超時時間。但是可以設定阻塞(block)時間。
正確的寫法:
Socket socket = ...
socket.connect(remote, 20000); // fail after 20s
InputStream in = socket.getInputStream();
socket.setSoTimeout(15000);
int i = in.read();
複製程式碼
另外,檔案的讀取(FileInputStream, FileChannel, FileDescriptor, File)沒法指定超時時間, 而且IO操作均涉及到本地方法呼叫, 這個更操作了JVM的控制範圍,在分散式檔案系統中,對IO的操作內部實際上是網路呼叫。一般情況下操作60s的操作都可以認為已經超時了。為了解決這些問題,一般採用快取和非同步/訊息佇列處理。
頻繁使用計時器
錯誤程式碼:
for (...) {
long t = System.currentTimeMillis();
long t = System.nanoTime();
Date d = new Date();
Calendar c = new GregorianCalendar();
}
複製程式碼
每次new一個Date或Calendar都會涉及一次本地呼叫來獲取當前時間(儘管這個本地呼叫相對其他本地方法呼叫要快)。
如果對時間不是特別敏感,這裡使用了clone方法來新建一個Date例項。這樣相對直接new要高效一些。
正確的寫法:
Date d = new Date();
for (E entity : entities) {
entity.doSomething();
entity.setUpdated((Date) d.clone());
}
複製程式碼
如果迴圈操作耗時較長(超過幾ms),那麼可以採用下面的方法,立即建立一個Timer,然後定期根據當前時間更新時間戳,在我的系統上比直接new一個時間物件快200倍:
private volatile long time;
Timer timer = new Timer(true);
try {
time = System.currentTimeMillis();
timer.scheduleAtFixedRate(new TimerTask() {
public void run() {
time = System.currentTimeMillis();
}
}, 0L, 10L); // granularity 10ms
for (E entity : entities) {
entity.doSomething();
entity.setUpdated(new Date(time));
}
} finally {
timer.cancel();
}
複製程式碼
捕獲所有的異常
錯誤的寫法:
Query q = ...
Person p;
try {
p = (Person) q.getSingleResult();
} catch(Exception e) {
p = null;
}
複製程式碼
這是EJB3的一個查詢操作,可能出現異常的原因是:結果不唯一;沒有結果;資料庫無法訪問,而捕獲所有的異常,設定為null將掩蓋各種異常情況。
正確的寫法:
Query q = ...
Person p;
try {
p = (Person) q.getSingleResult();
} catch(NoResultException e) {
p = null;
}
複製程式碼
忽略所有異常
錯誤的寫法:
try {
doStuff();
} catch(Exception e) {
log.fatal("Could not do stuff");
}
doMoreStuff();
複製程式碼
這個程式碼有兩個問題, 一個是沒有告訴呼叫者, 系統呼叫出錯了. 第二個是日誌沒有出錯原因, 很難跟蹤定位問題。
正確的寫法:
try {
doStuff();
} catch(Exception e) {
throw new MyRuntimeException("Could not do stuff because: "+ e.getMessage, e);
}
複製程式碼