Java編程常見問題彙總

時間 2019-11-08

原文原文鏈接

天天在寫Java程序，其實裏面有一些細節你們可能沒怎麼注意，這不，有人總結了一個咱們編程中常見的問題。雖然通常沒有什麼大問題，可是最好別這樣作。php

字符串鏈接誤用

錯誤的寫法：java

String s = "";  
for (Person p : persons) {  
    s += ", " + p.getName();  
}  
s = s.substring(2); //remove first comma

正確的寫法：web

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();   
}   
}