Java編程最差實踐

Java編程最差實踐

博客分類： 
• Java

java 

原文地址:http://www.odi.ch/prog/design/newbies.php 
每天在寫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();
        }
}