為了讓俺這點可憐的經驗更有針對性，先做一點背景說明：
1、我這里說的性能調優主要是由資深開發人員完成的，性能調優的結果就是代碼的修改和優化。為什么說要資深開發人員來完成呢（^_^，本人也不是什么資深人員，趕鴨子上架），因為性能調優的過程一般伴隨這性能瓶頸的分析，這需要對產品代碼（尤其是核心模塊的代碼）比較熟悉而且比較有把握，這樣才能既能比較快速的分析出性能瓶頸，又能在做代碼修改的同時比較準確的估計代碼的修改可能引起的問題，給測試人員提供比較有針對性的建議。性能調優的代碼修改往往會引入讓你大跌眼鏡的bug
2、個人負責了兩次性能調優，經驗很淺。為了更方便大家參考，現在公司的產品是一個基于eclipse的IDE工具，純代碼行大約50萬行，插件規模大約70個左右（當然，不包含測試插件、國際化資源插件等），基于的主要平臺有：Eclipse平臺、JDT、WTP 1.5。
一時也整理不出合適的思路，下面就想到那寫到那吧。
【性能分析/監控工具的選擇】
在做性能分析的時候，主要做兩個方面的性能分析：時間占用瓶頸分析、內存占用瓶頸分析。工具自然是必不可少的，我手頭常用的工具有BEA JRockit和JProfile兩種。一般需要分析內存占用的時候，基本上是遇到內存溢出的問題了～_～，我們要分析的情況基本上兩種：堆內存溢出、PermGen內存溢出。
堆內存溢出分析：大膽的相信工具吧。尤其是工具中提供的調用關系分析功能，能夠幫你搞清楚到底那些對象在堆中一直持有，然后還可以方便看出特定類型的實例個數、實例的大小等等。如果你的產品中，底層的一些模型是基于xml建立的（尤其是可惡的dom），那就更要好好看看了～_～。堆內存泄漏分析的時候，一定要注意三個地方：一、-Xms -Xmx配置；二、垃圾回收策略的配置；三、所在機器的虛擬內存配置。要保持這三點統一，否則多次分析之間可能會有一定的誤差，耗費不必要的人力
PermGen內存區溢出分析：工具分析的作用不大。為什么這么說呢？PermGen內存區域是存放類型信息的，類型被虛擬機卸載的幾率是極其小的（具體可以參考我博客里面的相關隨筆），所以性能調優的時候唯一比較有效的方式是將產品中的功能模塊基本上都啟動一下，然后大致測試出PermGen區域需要的峰值是多少，然后在產品手冊中明確指明-XX:PermSize=** -XX:MaxPermSize**，這對用戶最重要。（用戶才不管你產品的技術實現怎樣怎樣呢，人家只要不發生內存泄漏就可以了 ～_～）
有關堆內存和PermGen內存調優的最重要成果應該是兩點：一是避免內存溢出的問題；二是經過測試，然后總結出適合你產品的配置參數（包括堆內存配置參數、PermGen內存配置參數、垃圾回收策略參數），重點要關注一下垃圾回收的頻率和單次回收時間之間做權衡，因為這會在無形中干擾你產品運行時候的性能表現。對于用戶來說，人家只需要知道怎么配置一下就ok了，具體里面的原理怎么樣等等，人家才懶得管呢！
系統資源（例如圖片資源句柄等）的泄漏：有專門的工具可以看，相信工具！！！根據工具提供的信息，能夠比較快速的定位到代碼。為了維護優化的效果，最好是通知所有寫代碼的人，怎么避免這種泄漏，否則你剛優化好了，人家有給你泄漏了
時間占用內存分析：工具有一定的輔助作用，但是最重要的工具是自己打時間戳?。?！。工具在用來分析時間占用的時候，一般會在兩種情況下出現較大的偏差：一、函數調用的層次過深；二、待分析的時間占用過長，工具統計出來的時間占用會有明顯的游離誤差。工具的大致作用就是宏觀上幫你確定一下可疑的點，然后具體的分析，最好是在代碼里面自己打時間戳分析。（分析時間占用的時候，上帝都可能靠不住，但是時間戳System.out.println(System.currentTimeMillis())還是可以信任一把的?。。。?br />
【測試環境】
測試環境一定要保持統一，個人覺得有如下幾點需要注意：
1、測試機器的物理配置不要發生變化，而且關于虛擬內存的設置保持不變
2、測試工程需要保持一致
3、在驗證優化效果時候，產品配置參數保持一致。如果想測試配置參數對性能的優化效果，那就只測試參數。
4、性能測試一般在產品開發較為穩定的時候進行。如果在產品還在大量代碼開發的時候進行，往往很難保證優化的成果。你的性能調優就是針對某一時間點的產品，盡量不要邊更新代碼邊做性能調優
【產品穩定性】
性能優化可能帶來的影響范圍一定要充分分析，提交給測試人員進行測試。寧可錯殺，也不能漏網。個人的經驗，整體的較大的性能優化往往帶來產品底層代碼的修改，如果讓測試人員對產品全部進行測試吧，那人家肯定不干；這就需要你大致的確定出來影響范圍，給測試人員一個可以接受的范圍，讓他們進行驗證。如果性能優化后，性能是提到了，結果給產品中引入的嚴重的而且是隱藏很深的bug，那這個性能優化的意義又有多大呢？？？例如你引入的緩存策略，來緩存重量級的模型，時間是快了，但是如果你忽視了被緩存對象的更新策略，那么可能就會引起隱藏的邏輯錯誤....
【減少工具帶來的入侵】
我們用測試平臺（例如JRockit、JProfile）進行性能分析的時候，盡量避免測試平臺對產品性能本身的影響。個人經驗是，結合本次監控和遠程監控兩種方式混用?，F在大部分專業的測試監控工具，一般都支持遠程監控。
··············先去吃飯了，午飯后回來接著寫。。。。。。。。。。
【基于插件的產品經常會遇到的內存占用瓶頸原因】
1、xml、emf等技術的引入
xml對內存占用來說絕對是個敏感字眼，尤其是dom實現方式，emf模型對象也類似。關于xml實現方式的選擇倒是可以說道說道，什么時候采用dom的方式呢？個人覺得一是應用場景要求具有較為豐富的語義，這是需求決定的，往往沒辦法；二是文件不會太大，例如如果你的目標xml文件的規模是不確定的，那最好在用dom方式之前好好斟酌斟酌。
2、編輯器等重量級對象的內存泄漏?。?！
在Eclipse里面有一些重量級別的對象，尤其是workbench中，對這些對象資源的釋放一定要小心，否則帶來的后果絕對是很嚴重的。例如測試編輯器相關資源的釋放情況，你可以打開一次編輯器，用工具檢測一下堆內存的實例對象的變化情況，然后關閉，再監測一把，這樣就可以看看相關的未釋放的資源，然后排查一下代碼，找個合適的地方dispose掉。Eclipse中類似的場景很多，一定要小心....
3、緩存策略的不恰當使用
我們引入緩存策略的初衷往往是基于“以空間換時間”的概念出發的，那么一定要對空間的管理加倍小心，對一個性能敏感的產品軟件來說，內存一定是最昂貴的資源。個人經驗，首先要關注的是，你的緩存規模真正需要多大，例如如果你的緩沖池持有的大對象一直較多，而整個堆內存空間又不富裕，那么肯定會大大提升垃圾收集的頻率，而且往往這種問題不仔細分析很難判斷出來～_～ 其次要關注的是，你的緩存策略是否需要相應的實效策略、更新策略、銷毀策略呢？？？
4、設計的考慮不周到
對于較為復雜的場景，我們完全可以模仿Eclipse中的設計做法，設計多個層面的對象。例如，我們可以在重量級模型的基礎上搭建輕量級對象，很多場景下，我們的輕量級對象完全可以提供足夠的信息了，而且如果對輕量級模型的進行緩存策略的代價也會明顯小很多，這在JDT core、Eclipse一些底層模塊中都有很類似的引用。Eclipse中的“有樣學樣”法則，不但是教會我們怎么去實現一個功能點，它的設計我們也可以去模仿。
5、內存參數配置不合理
有幾個經驗直接說一下吧。首先，有關PermGen區域大小的設定最好基于峰值的測量，過小會明顯增大PermGen區域內存溢出的頻率，過大會浪費寶貴的內存資源，擠占實例堆的空間，用工具檢測就會發現，會明顯增大堆空間的垃圾回收的次數，而且每次回收的效果并不顯著；其次，關于垃圾回收策略的配置參數，一定要選取自己合適的。（各種策略都相關的文檔說明）；第三，為了有效的排查內存溢出的問題，最好默認配置一下XX:+HeapDumpOnOutOfMemoryError參數，方便排查。
【基于插件的產品經常會遇到的時間占用瓶頸原因】
1、Eclipse懶加載法則的違背
首先，有關擴展收集的問題。例如你在Host插件中定義了擴展點，里面有class屬性制定了特定接口類型，有很多個Extension插件都提供了這種擴展。你在Host插件中收集擴展的時候，往往會不小心調用了IConfigurationElement.createExecutableExtension(String propertyName)，這種不經意間的調用會導致很多類型的加載初始化＋相應插件的啟動，。。。。往往性能瓶頸出來了
其次，把懶加載法則進一步延伸，其實很多場景可以模仿Eclipse中代碼的做法，利用代理對象＋懶加載的方式。例如我們給類似Navigator視圖準備一個模型，那完全可以在模型設計上就引入懶加載的思路
2、設計是否合理
對于做一個產品軟件來說，如果整體架構設計出現了問題，那帶來的性能問題可能是后面性能優化不能簡單解決的。舉一個假設的場景，例如你的產品中底層模型全面基于emf，那么emf的反序列化（模型解析）就是非常耗時，你可以引入緩存策略；其次，你可以在emf模型層面的基礎上再搭建一層輕量級的模型（類似于JDT中的IType等），一方面為有些并不需要重量級模型的場景提供服務，另外可以作為重量級模型的代理使用...
從更高一點的層面來將，Eclipse以現在的規模（而且是java做的產品軟件）性能還能接受，某種程度上得益于其micro kernel + core plug-ins + application plug-ins的架構，它的內核和核心插件規模是很小的，否則，可能性能上就要犧牲不少了...
3、Job的錯誤使用
例如過多的Job會明顯加重系統線程管理、調度的開銷。再排查時間占用瓶頸點的時候，不要以為使用了Job就肯定更快了，要再撒一眼，往往很多剛接觸Eclipse Job的人狂用Job～_～
其實可能是ISchedulingRule機制的不正確使用，例如鎖定的范圍過大，動不動就鎖定整個工作區等等。其實ISchedulingRule的使用和java中synchronized關鍵字的使用有異曲同工之妙，鎖定范圍過大往往會大大傷害性能，而且會造成不必要的線程死鎖等問題
追蹤這類問題，可以在發現產品運行感覺有點不流暢的情形下，掛起調試實例，排查一下各個線程都在搞什么名堂。。。。。。。。
4、監聽器的錯誤使用
例如各種change listener的使用，排查一下里面是否有耗時的操作。很多監聽器機制的實現者都提供了調試跟蹤的機制，例如org.eclipse.jdt.core就提供了如下豐富的調試跟蹤選項：
例如打開相應的調試跟蹤選項，就可以把真個應用中的所有的IElementChangedListener和所耗時間等等都給他搞出來。很多Eclipse底層插件中都提供了很多跟蹤調試選項，對開發人員做性能分析特別有用，省得自己去打過多不必要的時間戳了（以前還真發現跟蹤調試選項有點畫餅充饑的意思，但確實還是挺有用的~_~）
5、插件的依賴是否合理
對于你自己的插件所依賴的插件，需要有一定的了解，當然Eclipse默認提供的一些插件可以放松一點。舉個例子，我遇到過一個開發人員為了使用WTP中一個很簡單的功能，竟然依賴了wtp中的一個ui層面的插件，引起的效果那就。。。
不寫了，腦子有點糊涂了。。。。。。。。。。
本博客中的所有文章、隨筆除了標題中含有引用或者轉載字樣的，其他均為原創。轉載請注明出處，謝謝！