Java程式設計常見問題彙總
每天在寫Java程式，其實裡面有一些細節大家可能沒怎麼注意，這不，有人總結了一個我們程式設計中常見的問題。雖然一般沒有什麼大問題，但是最好別這樣做。另外這裡提到的很多問題其實可以通過Findbugs( http://findbugs.sourceforge.net/ )來幫我們進行檢查出來。
字串連線誤用
錯誤的寫法：
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);
}
重複包裝RuntimeException
錯誤的寫法：
try {
doStuff();
} catch(Exception e) {
throw new RuntimeException(e);
}
正確的寫法：
try {
doStuff();
} catch(RuntimeException e) {
throw e;
} catch(Exception e) {
throw new RuntimeException(e.getMessage(), e);
}
try {
doStuff();
} catch(IOException e) {
throw new RuntimeException(e.getMessage(), e);
} catch(NamingException e) {
throw new RuntimeException(e.getMessage(), e);
}
不正確的傳播異常
錯誤的寫法：
try {
} catch(ParseException e) {
throw new RuntimeException();
throw new RuntimeException(e.toString());
throw new RuntimeException(e.getMessage());
throw new RuntimeException(e);
}
主要是沒有正確的將內部的錯誤資訊傳遞給呼叫者. 第一個完全丟掉了內部錯誤資訊, 第二個錯誤資訊依賴toString方法, 如果沒有包含最終的巢狀錯誤資訊, 也會出現丟失, 而且可讀性差. 第三個稍微好一些, 第四個跟第二個一樣。
正確的寫法：
try {
} catch(ParseException e) {
throw new RuntimeException(e.getMessage(), e);
}
用日誌記錄異常
錯誤的寫法：
try {
...
} catch(ExceptionA e) {
log.error(e.getMessage(), e);
throw e;
} catch(ExceptionB e) {
log.error(e.getMessage(), e);
throw e;
}
一般情況下在日誌中記錄異常是不必要的, 除非呼叫方沒有記錄日誌。
異常處理不徹底
錯誤的寫法：
try {
is = new FileInputStream(inFile);
os = new FileOutputStream(outFile);
} finally {
try {
is.close();
os.close();
} catch(IOException e) {
/* we can't do anything */
}
}
is可能close失敗, 導致os沒有close
正確的寫法：
try {
is = new FileInputStream(inFile);
os = new FileOutputStream(outFile);
} finally {
try { if (is != null) is.close(); } catch(IOException e) {/* we can't do anything */}
try { if (os != null) os.close(); } catch(IOException e) {/* we can't do anything */}
}
捕獲不可能出現的異常
錯誤的寫法：
try {
... do risky stuff ...
} catch(SomeException e) {
// never happens
}
... do some more ...
正確的寫法：
try {
... do risky stuff ...
} catch(SomeException e) {
// never happens hopefully
throw new IllegalStateException(e.getMessage(), e); // crash early, passing all information
}
... do some more ...
transient的誤用
錯誤的寫法：
public class A implements Serializable {
private String someState;
private transient Log log = LogFactory.getLog(getClass());
public void f() {
log.debug("enter f");
...
}
}
這裡的本意是不希望Log物件被序列化. 不過這裡在反序列化時, 會因為log未初始化, 導致f()方法拋空指標, 正確的做法是將log定義為靜態變數或者定位為具備變數。
正確的寫法：
public class A implements Serializable {
private String someState;
private static final Log log = LogFactory.getLog(A.class);
public void f() {
log.debug("enter f");
...
}
}
public class A implements Serializable {
private String someState;
public void f() {
Log log = LogFactory.getLog(getClass());
log.debug("enter f");
...
}
}
不必要的初始化
錯誤的寫法：
public class B {
private int count = 0;
private String name = null;
private boolean important = false;
}
這裡的變數會在初始化時使用預設值:0, null, false, 因此上面的寫法有些多此一舉。
正確的寫法：
public class B {
private int count;
private String name;
private boolean important;
}
最好用靜態final定義Log變數
private static final Log log = LogFactory.getLog(MyClass.class);
這樣做的好處有三：
- 可以保證執行緒安全
- 靜態或非靜態程式碼都可用
- 不會影響物件序列化
選擇錯誤的類載入器
錯誤的程式碼：
Class clazz = Class.forName(name); Class clazz = getClass().getClassLoader().loadClass(name);
這裡本意是希望用當前類來載入希望的物件, 但是這裡的getClass()可能丟擲異常, 特別在一些受管理的環境中, 比如應用伺服器, web容器, Java WebStart環境中, 最好的做法是使用當前應用上下文的類載入器來載入。
正確的寫法：
ClassLoader cl = Thread.currentThread().getContextClassLoader(); if (cl == null) cl = MyClass.class.getClassLoader(); // fallback Class clazz = cl.loadClass(name);
反射使用不當
錯誤的寫法：
Class beanClass = ... if (beanClass.newInstance() instanceof TestBean) ...
這裡的本意是檢查beanClass是否是TestBean或是其子類, 但是建立一個類例項可能沒那麼簡單, 首先例項化一個物件會帶來一定的消耗, 另外有可能類沒有定義預設建構函式. 正確的做法是用Class.isAssignableFrom(Class) 方法。
正確的寫法：
Class beanClass = ... if (TestBean.class.isAssignableFrom(beanClass)) ...
不必要的同步
錯誤的寫法：
Collection l = new Vector();
for (...) {
l.add(object);
}
Vector是ArrayList同步版本。
正確的寫法：
Collection l = new ArrayList();
for (...) {
l.add(object);
}
錯誤的選擇List型別
根據下面的表格資料來進行選擇
| ArrayList | LinkedList | |
| add (append) | O(1) or ~O(log(n)) if growing | O(1) |
| insert (middle) | O(n) or ~O(n*log(n)) if growing | O(n) |
| remove (middle) | O(n) (always performs complete copy) | O(n) |
| iterate | O(n) | O(n) |
| get by index | O(1) | O(n) |
HashMap size陷阱
錯誤的寫法：
Map map = new HashMap(collection.size());
for (Object o : collection) {
map.put(o.key, o.value);
}
這裡可以參考guava的Maps.newHashMapWithExpectedSize的實現. 使用者的本意是希望給HashMap設定初始值, 避免擴容(resize)的開銷. 但是沒有考慮當新增的元素數量達到HashMap容量的75%時將出現resize。
正確的寫法：
Map map = new HashMap(1 + (int) (collection.size() / 0.75));
對Hashtable, HashMap 和 HashSet瞭解不夠
這裡主要需要了解HashMap和Hashtable的內部實現上, 它們都使用Entry包裝來封裝key/value, Entry內部除了要儲存Key/Value的引用, 還需要儲存hash桶中next Entry的應用, 因此對記憶體會有不小的開銷, 而HashSet內部實現其實就是一個HashMap. 有時候IdentityHashMap可以作為一個不錯的替代方案. 它在記憶體使用上更有效(沒有用Entry封裝, 內部採用Object[]). 不過需要小心使用. 它的實現違背了Map介面的定義. 有時候也可以用ArrayList來替換HashSet.
這一切的根源都是由於JDK內部沒有提供一套高效的Map和Set實現。
對List的誤用
建議下列場景用Array來替代List:
- list長度固定，比如一週中的每一天
- 對list頻繁的遍歷，比如超過1w次
- 需要對數字進行包裝(主要JDK沒有提供基本型別的List)
比如下面的程式碼。
錯誤的寫法：
List<Integer> codes = new ArrayList<Integer>(); codes.add(Integer.valueOf(10)); codes.add(Integer.valueOf(20)); codes.add(Integer.valueOf(30)); codes.add(Integer.valueOf(40));
正確的寫法：
int[] codes = { 10, 20, 30, 40 };
錯誤的寫法：
// horribly slow and a memory waster if l has a few thousand elements (try it yourself!)
List<Mergeable> l = ...;
for (int i=0; i < l.size()-1; i++) {
Mergeable one = l.get(i);
Iterator<Mergeable> j = l.iterator(i+1); // memory allocation!
while (j.hasNext()) {
Mergeable other = l.next();
if (one.canMergeWith(other)) {
one.merge(other);
other.remove();
}
}
}
正確的寫法：
// quite fast and no memory allocation
Mergeable[] l = ...;
for (int i=0; i < l.length-1; i++) {
Mergeable one = l[i];
for (int j=i+1; j < l.length; j++) {
Mergeable other = l[j];
if (one.canMergeWith(other)) {
one.merge(other);
l[j] = null;
}
}
}
實際上Sun也意識到這一點, 因此在JDK中, Collections.sort()就是將一個List拷貝到一個陣列中然後呼叫Arrays.sort方法來執行排序。
用陣列來描述一個結構
錯誤用法：
/**
* @returns [1]: Location, [2]: Customer, [3]: Incident
*/
Object[] getDetails(int id) {...
這裡用陣列+文件的方式來描述一個方法的返回值. 雖然很簡單, 但是很容易誤用, 正確的做法應該是定義個類。
正確的寫法：
Details getDetails(int id) {...}
private class Details {
public Location location;
public Customer customer;
public Incident incident;
}
對方法過度限制
錯誤用法：
public void notify(Person p) {
...
sendMail(p.getName(), p.getFirstName(), p.getEmail());
...
}
class PhoneBook {
String lookup(String employeeId) {
Employee emp = ...
return emp.getPhone();
}
}
第一個例子是對方法引數做了過多的限制, 第二個例子對方法的返回值做了太多的限制。
正確的寫法：
public void notify(Person p) {
...
sendMail(p);
...
}
class EmployeeDirectory {
Employee lookup(String employeeId) {
Employee emp = ...
return emp;
}
}
對POJO的setter方法畫蛇添足
錯誤的寫法：
private String name;
public void setName(String name) {
this.name = name.trim();
}
public void String getName() {
return this.name;
}
有時候我們很討厭字串首尾出現空格, 所以在setter方法中進行了trim處理, 但是這樣做的結果帶來的副作用會使getter方法的返回值和setter方法不一致, 如果只是將JavaBean當做一個資料容器, 那麼最好不要包含任何業務邏輯. 而將業務邏輯放到專門的業務層或者控制層中處理。
正確的做法：
person.setName(textInput.getText().trim());
日曆物件(Calendar)誤用
錯誤的寫法：
Calendar cal = new GregorianCalender(TimeZone.getTimeZone("Europe/Zurich"));
cal.setTime(date);
cal.add(Calendar.HOUR_OF_DAY, 8);
date = cal.getTime();
這裡主要是對date, time, calendar和time zone不瞭解導致. 而在一個時間上增加8小時, 跟time zone沒有任何關係, 所以沒有必要使用Calendar, 直接用Date物件即可, 而如果是增加天數的話, 則需要使用Calendar, 因為採用不同的時令制可能一天的小時數是不同的(比如有些DST是23或者25個小時)
正確的寫法：
date = new Date(date.getTime() + 8L * 3600L * 1000L); // add 8 hrs
TimeZone的誤用
錯誤的寫法：
Calendar cal = new GregorianCalendar(); cal.setTime(date); cal.set(Calendar.HOUR_OF_DAY, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); Date startOfDay = cal.getTime();
這裡有兩個錯誤, 一個是沒有沒有將毫秒歸零, 不過最大的錯誤是沒有指定TimeZone, 不過一般的桌面應用沒有問題, 但是如果是伺服器端應用則會有一些問題, 比如同一時刻在上海和倫敦就不一樣, 因此需要指定的TimeZone.
正確的寫法：
Calendar cal = new GregorianCalendar(user.getTimeZone()); cal.setTime(date); cal.set(Calendar.HOUR_OF_DAY, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); cal.set(Calendar.MILLISECOND, 0); Date startOfDay = cal.getTime();
時區(Time Zone)調整的誤用
錯誤的寫法：
public static Date convertTz(Date date, TimeZone tz) {
Calendar cal = Calendar.getInstance();
cal.setTimeZone(TimeZone.getTimeZone("UTC"));
cal.setTime(date);
cal.setTimeZone(tz);
return cal.getTime();
}
這個方法實際上沒有改變時間, 輸入和輸出是一樣的. 關於時間的問題可以參考這篇文章: http://www.odi.ch/prog/design/datetime.php 這裡主要的問題是Date物件並不包含Time Zone資訊. 它總是使用UTC(世界統一時間). 而呼叫Calendar的getTime/setTime方法會自動在當前時區和UTC之間做轉換。
Calendar.getInstance()的誤用
錯誤的寫法：
Calendar c = Calendar.getInstance(); c.set(2009, Calendar.JANUARY, 15);
Calendar.getInstance()依賴local來選擇一個Calendar實現, 不同實現的2009年是不同的, 比如有些Calendar實現就沒有January月份。
正確的寫法：
Calendar c = new GregorianCalendar(timeZone); c.set(2009, Calendar.JANUARY, 15);
Date.setTime()的誤用
錯誤的寫法：
account.changePassword(oldPass, newPass); Date lastmod = account.getLastModified(); lastmod.setTime(System.currentTimeMillis());
在更新密碼之後, 修改一下最後更新時間, 這裡的用法沒有錯,但是有更好的做法: 直接傳Date物件. 因為Date是Value Object, 不可變的. 如果更新了Date的值, 實際上是生成一個新的Date例項. 這樣其他地方用到的實際上不在是原來的物件, 這樣可能出現不可預知的異常. 當然這裡又涉及到另外一個OO設計的問題, 對外暴露Date例項本身就是不好的做法(一般的做法是在setter方法中設定Date引用引數的clone物件). 另外一種比較好的做法就是直接儲存long型別的毫秒數。
正確的做法：
account.changePassword(oldPass, newPass); account.setLastModified(new Date());
SimpleDateFormat非執行緒安全誤用
錯誤的寫法：
public class Constants {
public static final SimpleDateFormat date = new SimpleDateFormat("dd.MM.yyyy");
}
SimpleDateFormat不是執行緒安全的. 在多執行緒並行處理的情況下, 會得到非預期的值. 這個錯誤非常普遍! 如果真要在多執行緒環境下公用同一個SimpleDateFormat, 那麼做好做好同步(cache flush, lock contention), 但是這樣會搞得更復雜, 還不如直接new一個實在。
使用全域性引數配置常量類/介面
public interface Constants {
String version = "1.0";
String dateFormat = "dd.MM.yyyy";
String configFile = ".apprc";
int maxNameLength = 32;
String someQuery = "SELECT * FROM ...";
}
很多應用都會定義這樣一個全域性常量類或介面, 但是為什麼這種做法不推薦? 因為這些常量之間基本沒有任何關聯, 只是因為公用才定義在一起. 但是如果其他元件需要使用這些全域性變數, 則必須對該常量類產生依賴, 特別是存在server和遠端client呼叫的場景。
比較好的做法是將這些常量定義在元件內部. 或者侷限在一個類庫內部。
忽略造型溢位(cast overflow)
錯誤的寫法：
public int getFileSize(File f) {
long l = f.length();
return (int) l;
}
這個方法的本意是不支援傳遞超過2GB的檔案. 最好的做法是對長度進行檢查, 溢位時丟擲異常。
正確的寫法：
public int getFileSize(File f) {
long l = f.length();
if (l > Integer.MAX_VALUE) throw new IllegalStateException("int overflow");
return (int) l;
}
另一個溢位bug是cast的物件不對, 比如下面第一個println. 正確的應該是下面的那個。
long a = System.currentTimeMillis(); long b = a + 100; System.out.println((int) b-a); System.out.println((int) (b-a));
對float和double使用==操作
錯誤的寫法：
for (float f = 10f; f!=0; f-=0.1) {
System.out.println(f);
}
上面的浮點數遞減只會無限接近0而不會等於0, 這樣會導致上面的for進入死迴圈. 通常絕不要對float和double使用==操作. 而採用大於和小於操作. 如果java編譯器能針對這種情況給出警告. 或者在java語言規範中不支援浮點數型別的==操作就最好了。
正確的寫法：
for (float f = 10f; f>0; f-=0.1) {
System.out.println(f);
}
用浮點數來儲存money
錯誤的寫法：
float total = 0.0f;
for (OrderLine line : lines) {
total += line.price * line.count;
}
double a = 1.14 * 75; // 85.5 將表示為 85.4999...
System.out.println(Math.round(a)); // 輸出值為85
BigDecimal d = new BigDecimal(1.14); //造成精度丟失
這個也是一個老生常談的錯誤. 比如計算100筆訂單, 每筆0.3元, 最終的計算結果是29.9999971. 如果將float型別改為double型別, 得到的結果將是30.000001192092896. 出現這種情況的原因是, 人類和計算的計數方式不同. 人類採用的是十進位制, 而計算機是二進位制.二進位制對於計算機來說非常好使, 但是對於涉及到精確計算的場景就會帶來誤差. 比如銀行金融中的應用。
因此絕不要用浮點型別來儲存money資料. 採用浮點數得到的計算結果是不精確的. 即使與int型別做乘法運算也會產生一個不精確的結果.那是因為在用二進位制儲存一個浮點數時已經出現了精度丟失. 最好的做法就是用一個string或者固定點數來表示. 為了精確, 這種表示方式需要指定相應的精度值.
BigDecimal就滿足了上面所說的需求. 如果在計算的過程中精度的丟失超出了給定的範圍, 將丟擲runtime exception.
正確的寫法：
BigDecimal total = BigDecimal.ZERO;
for (OrderLine line : lines) {
BigDecimal price = new BigDecimal(line.price);
BigDecimal count = new BigDecimal(line.count);
total = total.add(price.multiply(count)); // BigDecimal is immutable!
}
total = total.setScale(2, RoundingMode.HALF_UP);
BigDecimal a = (new BigDecimal("1.14")).multiply(new BigDecimal(75)); // 85.5 exact
a = a.setScale(0, RoundingMode.HALF_UP); // 86
System.out.println(a); // correct output: 86
BigDecimal a = new BigDecimal("1.14");
不使用finally塊釋放資源
錯誤的寫法：
public void save(File f) throws IOException {
OutputStream out = new BufferedOutputStream(new FileOutputStream(f));
out.write(...);
out.close();
}
public void load(File f) throws IOException {
InputStream in = new BufferedInputStream(new FileInputStream(f));
in.read(...);
in.close();
}
上面的程式碼開啟一個檔案輸出流, 作業系統為其分配一個檔案控制程式碼, 但是檔案控制程式碼是一種非常稀缺的資源, 必須通過呼叫相應的close方法來被正確的釋放回收. 而為了保證在異常情況下資源依然能被正確回收, 必須將其放在finally block中. 上面的程式碼中使用了BufferedInputStream將file stream包裝成了一個buffer stream, 這樣將導致在呼叫close方法時才會將buffer stream寫入磁碟. 如果在close的時候失敗, 將導致寫入資料不完全. 而對於FileInputStream在finally block的close操作這裡將直接忽略。
如果BufferedOutputStream.close()方法執行順利則萬事大吉, 如果失敗這裡有一個潛在的bug(http://bugs.sun.com/view_bug.do?bug_id=6335274): 在close方法內部呼叫flush操作的時候, 如果出現異常, 將直接忽略. 因此為了儘量減少資料丟失, 在執行close之前顯式的呼叫flush操作。
下面的程式碼有一個小小的瑕疵: 如果分配file stream成功, 但是分配buffer stream失敗(OOM這種場景), 將導致檔案控制程式碼未被正確釋放. 不過這種情況一般不用擔心, 因為JVM的gc將幫助我們做清理。
// code for your cookbook
public void save() throws IOException {
File f = ...
OutputStream out = new BufferedOutputStream(new FileOutputStream(f));
try {
out.write(...);
out.flush(); // don't lose exception by implicit flush on close
} finally {
out.close();
}
}
public void load(File f) throws IOException {
InputStream in = new BufferedInputStream(new FileInputStream(f));
try {
in.read(...);
} finally {
try { in.close(); } catch (IOException e) { }
}
}
資料庫訪問也涉及到類似的情況：
Car getCar(DataSource ds, String plate) throws SQLException {
Car car = null;
Connection c = null;
PreparedStatement s = null;
ResultSet rs = null;
try {
c = ds.getConnection();
s = c.prepareStatement("select make, color from cars where plate=?");
s.setString(1, plate);
rs = s.executeQuery();
if (rs.next()) {
car = new Car();
car.make = rs.getString(1);
car.color = rs.getString(2);
}
} finally {
if (rs != null) try { rs.close(); } catch (SQLException e) { }
if (s != null) try { s.close(); } catch (SQLException e) { }
if (c != null) try { c.close(); } catch (SQLException e) { }
}
return car;
}
finalize方法誤用
錯誤的寫法：
public class FileBackedCache {
private File backingStore;
...
protected void finalize() throws IOException {
if (backingStore != null) {
backingStore.close();
backingStore = null;
}
}
}
這個問題Effective Java這本書有詳細的說明. 主要是finalize方法依賴於GC的呼叫, 其呼叫時機可能是立馬也可能是幾天以後, 所以是不可預知的. 而JDK的API文件中對這一點有誤導：建議在該方法中來釋放I/O資源。
正確的做法是定義一個close方法, 然後由外部的容器來負責呼叫釋放資源。
public class FileBackedCache {
private File backingStore;
...
public void close() throws IOException {
if (backingStore != null) {
backingStore.close();
backingStore = null;
}
}
}
在JDK 1.7 (Java 7)中已經引入了一個AutoClosable介面. 當變數(不是物件)超出了try-catch的資源使用範圍, 將自動呼叫close方法。
try (Writer w = new FileWriter(f)) { // implements Closable
w.write("abc");
// w goes out of scope here: w.close() is called automatically in ANY case
} catch (IOException e) {
throw new RuntimeException(e.getMessage(), e);
}
Thread.interrupted方法誤用
錯誤的寫法：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// ok
}
or
while (true) {
if (Thread.interrupted()) break;
}
這裡主要是interrupted靜態方法除了返回當前執行緒的中斷狀態, 還會將當前執行緒狀態復位。
正確的寫法：
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
or
while (true) {
if (Thread.currentThread().isInterrupted()) break;
}
在靜態變數初始化時建立執行緒
錯誤的寫法：
class Cache {
private static final Timer evictor = new Timer();
}
Timer構造器內部會new一個thread, 而該thread會從它的父執行緒(即當前執行緒)中繼承各種屬性。比如context classloader, ThreadLocal以及其他的安全屬性(訪問許可權)。 而載入當前類的執行緒可能是不確定的，比如一個執行緒池中隨機的一個執行緒。如果你需要控制執行緒的屬性，最好的做法就是將其初始化操作放在一個靜態方法中，這樣初始化將由它的呼叫者來決定。
正確的做法：
class Cache {
private static Timer evictor;
public static setupEvictor() {
evictor = new Timer();
}
}
已取消的定時器任務依然持有狀態
錯誤的寫法：
final MyClass callback = this;
TimerTask task = new TimerTask() {
public void run() {
callback.timeout();
}
};
timer.schedule(task, 300000L);
try {
doSomething();
} finally {
task.cancel();
}
上面的task內部包含一個對外部類例項的應用, 這將導致該引用可能不會被GC立即回收. 因為Timer將保留TimerTask在指定的時間之後才被釋放. 因此task對應的外部類例項將在5分鐘後被回收。
正確的寫法：
TimerTask task = new Job(this);
timer.schedule(task, 300000L);
try {
doSomething();
} finally {
task.cancel();
}
static class Job extends TimerTask {
private MyClass callback;
public Job(MyClass callback) {
this.callback = callback;
}
public boolean cancel() {
callback = null;
return super.cancel();
}
public void run() {
if (callback == null) return;
callback.timeout();
}
}
相關文章
- Java程式設計常見問題彙總(一)Java程式設計
- Java 常見問題彙總Java
- Java常見知識點彙總（⑩）——常見設計模式Java設計模式
- Redis常見問題彙總Redis
- Bootstrap常見問題彙總boot
- Java程式設計師面試常見問題Java程式設計師面試
- 代理IP常見問題彙總
- Redis Manager 常見問題彙總Redis
- SpringMvc常見問題彙總SpringMVC
- JuniperNetScreen常見問題彙總
- 雲端計算 常見問題案例彙總情況
- Java常見面試題及答案彙總Java面試題
- 前端常見設計模式彙總前端設計模式
- mybatis常見庫及問題彙總MyBatis
- Vue專案常見問題彙總Vue
- 好程式設計師分享：Java面試題常見問題程式設計師Java面試題
- PCL常見程式設計問題程式設計
- Android Studio 常見問題彙總Android
- 安裝PHP常見問題彙總薦PHP
- mount命令詳解及常見問題彙總
- MyBatis學習總結（24）——Mybatis常見問題彙總MyBatis
- Java常見知識點彙總（⑨）——異常Java
- 新手雲伺服器租用常見問題彙總伺服器
- Python程式設計常見問題與解答Python程式設計
- java 常見問題Java
- Java常見知識點彙總（⑳）——鎖Java
- Java常見知識點彙總（②）——StaticJava
- Oracle RAC+DG巡檢常見問題彙總(一)Oracle
- 物聯網平臺常見問題與答案彙總
- 網頁設計常見問題網頁
- JavaScript常見面試題彙總（含答案）JavaScript面試題
- 常見問題總結
- Linux TCP程式設計常見問題考慮LinuxTCP程式設計
- 程式設計師世界常見的6個問題程式設計師
- 微信小程式常見問題彙總 微信小程式有什麼功能 如何申請？微信小程式
- 125條常見的java面試、筆試題大彙總Java面試筆試
- Linux常見問題彙總，比較適合菜鳥哈Linux
- VNC常用操作及常見問題解決辦法彙總VNC