一：儘量重用對象，避免創建過多短時對象
對象在面向對象編程中隨處可見，甚至可以毫不誇張的說是：“一切都是對象”。如何更好的創建和使用對象，是優化中要考慮的一個重要方面。筆者將對象按使用分為兩大類：獨享對象和共用對象。獨享對象指由某個線程單獨擁有並維護其生命週期的對象，一般是通過new 創建的對象，線程結束且無其他對這個對象的引用，這個對象將由垃圾收集機制自動GC。共用對象指由多個線程共用的對象，各線程保持多個指向同一個對象的引用，任何對這個對象的修改都會在其他引用上得到體現，共用對象一般通過Factory工廠的getInstace()方法創建，單例模式就是創建共用對象的標準實現。獨享對象由於無其他指向同一對象的引用，不用擔心其他引用對對象屬性的修改，在多線程環境裏，也就不需要對其可能修改屬性的方法加以同步，減少了出錯的隱患和複雜性，但由於需要為每個線程都創建對象，增加了對記憶體的需求和JVM GC的負擔。共用對象則需要進行適當的同步（避免較大的同步塊，同時防止死鎖）。
還有幾種特殊對象：不變對象和方法對象。不變對象指對象對外不含有修改對象屬性的方法（如set方法），外部要修改屬性只能通過new新的實例來實現。不變對象最大的好處就是無需擔心屬性被修改，避免了潛在的bug，並能無需任何額外工作（如同步）就很好的工作在多線程環境下。如JDK的String對象就是典型的不變對象。方法對象簡單的說就是僅包含方法，不含有屬性的對象。由於沒有對象屬性，方法中無需進行修改屬性的操作，也就能採用static方法或單例模式，避免每次使用都要new對象，減少對象的使用。
那麼該如何確定創建何種對象，這就要結合對象的使用方式和生命週期、對象大小、構建花銷等方面來綜合考慮。如果對象生命週期較長，會存在修改操作，不能容忍其他線程對其的修改，就應該採用獨享對象，如常見的Bean類。而如果對象生命週期較長，且能為各個線程共用，就可以考慮共用對象。共用有2種常見情況，一種是系統全局對象，如配置屬性等，各個線程應該引用同一對象，任何對這個對象的修改都會影響其他線程；另一種是由於對象創建開銷較大，各線程對此對像是暫態訪問，且無需再次讀取其屬性，如常見的Date 對象，一般這種對象的使用是暫態的，比如把它format成String，如果每次創建然後等待GC就會浪費大量記憶體和CPU時間，較好做法就是做成共用對象，各個線程先set再使用，注意對進行set並訪問的方法要同步。不變對象一般使用在對象創建開銷較小（屬性較少，類層次較少），且需要能自由共用的情形。如一個對象裏的常量對象，使用public static final AAA=new AAA(…) 創建。方法對象使用較廣，如Util類、DAO類等，這些對象提供操作其他對象(一般是bean對象)的介面，能對系統在層次和功能上進行解耦合。
二：在迴圈處，多下功夫
迴圈作為程式編寫的基本語法，可以說是隨處可見。一些小的細節能帶來性能上的提升，而對迴圈體的一些改寫，能帶來性能的大幅提升。
比如最簡單的List遍歷，會有這樣的寫法：for(int i=0;i
同樣是對List的操作，如果要在遍歷同時進行增加和刪除操作，代碼如下：for(int i=0,j=l.size();i
這是由Collection庫ArrayList的實現決定的，以下是JDK1.3的ArrayList源碼：
public Object remove(int index) {
RangeCheck(index);
modCount++;
Object oldValue = elementData[index];
int numMoved = size - index - 1;
if (numMoved > 0)
System.arraycopy(elementData, index+1, elementData, index,
numMoved);
elementData[--size] = null; // Let gc do its work
return oldValue;
}
從中我們可以看出，numMoved代表了需要進行arraycopy操作的數量，它是由remove的位置決定的，如果index＝0，也就是刪除第一個元素，則需要arraycopy後面的所有數據，
而如果index＝size-1，則只需將最後一個元素設為null即可。所以從後面向前迴圈remove是比較好的寫法。
如果List中的確存在較多的add或remove操作，且容量較大（如存儲幾萬個對象），則應該採用LinkedList作為實現。LinkedList內部採用雙向鏈表作為數據結構，比ArrayList佔用較多記憶體空間，且隨機訪問操作較慢（需要從頭或尾迴圈到相應位置），但插入刪除操作很快（僅需進行鏈表操作，無須大量移動或拷貝）。
對於List操作如果迴圈規模較小，其實對性能影響非常小（ms級），遠遠不是性能瓶頸所在。但心中有著優化的意識，並力求寫出簡潔高效的程式應該是我們每個程式員的追求。而且一旦在迴圈規模較大時，如果有了這些意識，也就能有效的消除性能隱患。
再舉一個與優化無關但確實可能成為性能殺手（可以說是bug）的迴圈的例子。下面是源代碼：
for(; totalRead < m_totalBytes; totalRead += readBytes)
{
readBytes = m_request.getInputStream().read(m_binArray, totalRead, m_totalBytes - totalRead);
}
這個代碼意圖很清楚，就是將一個InputStream流讀到一個byte數組中去。它使用read方法迴圈讀取InputStream，該方法返回讀取的字節數。正常情況下，該迴圈運行良好，當totalRead＝m_totalBytes時，結束迴圈，byte數組被正常填充。但如果仔細看一下InputStream的read方法的說明，了解一下其返回值就會發現，返回值可能為－1，即已讀到InputStream末尾再繼續讀時。如果發生讀取異常，可能出現這個問題，而這個迴圈沒有檢查readBytes值是否為－1就往totalRead上加，這樣再次進入迴圈體繼續讀取InputStream，又返回－1，繼續迴圈。如此迴圈直到int溢出才會跳出迴圈。而這個迴圈也就成了實實在在的CPU殺手，可以佔去大量的CPU時間（取決於作業系統）。其實解決很簡單，對readBytes進行判斷，如果為-1則跳出迴圈。
這個例子告訴我們：對迴圈一定要搞清迴圈的迴圈規模、每次迴圈體執行時間、迴圈結束條件包括異常情況等，只有這樣才能寫出高效且沒有隱患的代碼。