優化一般意義上說是提高已有系統的效能，減少如記憶體、資料庫、網路頻寬等資源的佔用，是在系統開發告一段落的前提下進行。一般是通過壓力測試或具體使用發現效能方面的問題，然後尋找效能瓶頸，並結合專案進度、人員安排、技術儲備等因素，提出相應的優化策略。
下面結合一些案例，進行具體的討論，總結出兩個有代表性的條例：
條例一：儘量重用物件，避免建立過多短時物件
物件在物件導向程式設計中隨處可見，甚至可以毫不誇張的說是：“一切都是物件”。如何更好的建立和使用物件，是優化中要考慮的一個重要方面。筆者將物件按使用分為兩大類：獨享物件和共享物件。獨享物件指由某個執行緒單獨擁有並維護其生命週期的物件，一般是通過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=();i=0;i--){ve(i);}。經過測試，如果採用ArrayList，兩種寫法在迴圈次數較少時沒有太大的區別，迴圈次數為1000，均為1ms以內，次數為10000，前一種為60ms左右，後一種為1ms以內，，而次數上到100000，前一種為6000ms左右，後一種為15ms，隨著迴圈次數的增多，後一種較前一種的效率優勢明顯提高。
這是由Collection庫ArrayList的實現決定的，以下是jdk1.3的ArrayList原始碼：
從中我們可以看出，numMoved代表了需要進行arraycopy操作的數量，它是由remove的位置決定的，如果index=0，也就是刪除第一個元素，則需要arraycopy後面的所有資料，而如果index=size-1，則只需將最後一個元素設為null即可。所以從後面向前迴圈remove是比較好的寫法。
如果List中的確存在較多的add或remove操作，且容量較大(如儲存幾萬個物件)，則應該採用LinkedList作為實現。LinkedList內部採用雙向連結串列作為資料結構，比ArrayList佔用較多記憶體空間，且隨機訪問操作較慢(需要從頭或尾迴圈到相應位置)，但插入刪除操作很快(僅需進行連結串列操作，無須大量移動或拷貝)。
對於List操作如果迴圈規模較小，其實對效能影響非常小(ms級)，遠遠不是效能瓶頸所在。但心中有著優化的意識，併力求寫出簡潔高效的程式應該是我們每個程式設計師的追求。而且一旦在迴圈規模較大時，如果有了這些意識，也就能有效的消除效能隱患。
再舉一個與優化無關但確實可能成為效能殺手(可以說是bug)的迴圈的例子。下面是原始碼：
這個程式碼意圖很清楚，就是將一個InputStream流讀到一個byte陣列中去。它使用read方法迴圈讀取InputStream，該方法返回讀取的位元組數。正常情況下，該迴圈執行良好，當totalRead=m_totalBytes時，結束迴圈，byte陣列被正常填充。但如果仔細看一下InputStream的read方法的說明，瞭解一下其返回值就會發現，返回值可能為-1，即已讀到InputStream末尾再繼續讀時。如果發生讀取異常，可能出現這個問題，而這個迴圈沒有檢查readBytes值是否為-1就往totalRead上加，這樣再次進入迴圈體繼續讀取InputStream，又返回-1，繼續迴圈。如此迴圈直到int溢位才會跳出迴圈。而這個迴圈也就成了實實在在的CPU殺手，可以佔去大量的CPU時間(取決於作業系統)。其實解決很簡單，對readBytes進行判斷，如果為-1則跳出迴圈。
這個例子告訴我們：對迴圈一定要搞清迴圈的迴圈規模、每次迴圈體執行時間、迴圈結束條件包括異常情況等，只有這樣才能寫出高效且沒有隱患的程式碼。