三種常見的Java應用性能挑戰
Java是一種偉大的語言。它管理內存，傳授面向對象的編程(思想)，使我們更好地用它來編碼。另外，它確實是一種“編寫一次，到處運行“的語言。然而，Java應用程會遇到一些常見的開發者和應用者獨耳熟能詳的性能挑戰。
內存泄露
Java的最大的好處之一是它能夠管理內存模型。當對象不再使用時，Java會做清理工作。較舊的語言需要人工來管理內存，但開發者寧愿花時間專注于核心語言邏輯而不愿為內存分配而憂心。
話雖如此，卻不能保證Java的內存管理沒有問題，提供管理內存模型，或創建/銷毀未使用的對象，(這些對象)都放在Java的“堆(Heap)“中，內存泄露通常是不正確編程的結果–通常，開發者沒有消除某一對象的所有引用，因此，堆(空間)逐步耗盡，應用程序也將死機。
大多數人使用堆轉儲和/或事件探查器(profiler)來診斷內存泄漏。堆轉儲使你可看到哪個對象持有對集合的引用。它告訴你集合何處，但不能告訴你誰在存取該集合或其它能讓你探究根源的特性。堆轉儲通常占用的空間也相當大，在千兆字節，分析并打開一個堆轉儲需要大量資源，然后讀取它，并找出問題所在。
第二種方法，是組合堆轉儲和事件探查器，使你能接近點問題本質，但并不多。內存分析器盡力幫助您分析您的堆轉儲。他們有實時數據，現在可知道是誰創建的對象，但仍不知造成泄漏的真正根由。
堆轉儲和分析器都有益于開發和預生產，然而，一旦應用程序失控，分析器也不可用。隔離并解決內存泄漏最有效的方法來之一是通過事務(transaction)(管理)和代碼路徑分析。通過采取事務快照，可以獲得問題所在及其原因，這通常會導致更少的停機時間和更好的MTTR。
緩慢的SQL
幾乎每一應用程序都會使用JDBC數據庫。應用中一個非常普遍的問題是糟糕的SQL的性能，這可有時由于字段未創建索引、獲取的數據量太多或者其他原因所致。這會不利于應用的性能，因為大多數應用程序在每一應用請求中涉及很多SQL調用。
可能有很多造成SQL執行緩慢的原因，但是其中之一特別突出：對象-關系映射(ORM)。
ORM以成為將當今兩大業務應用基礎技術(面向對象的應用(Java,.NET)和關系數據庫(Oracle、MySQL和PostgreSQL等))整合在一起的首選方法。今天的大多數應用采用關系數據庫，對于許多開發人員而言，(ORM)這項技術可以消除需要升入探討著兩種技術如何相互作用的復雜度。然而，ORM使得應用需承受額外的負擔，并極大地影響應用的性能，而一切表面上看起來很好。
在大多數情況下，檢索數據所消耗的時間和占用資源的數量級遠大于數據處理所需的時間及資源，因此，性能方面的考慮常包含訪問和存儲數據的工具和方法就不足為奇了。
雖然開發人員直觀地使用(隱藏復雜性)，但ORM在應用性能方面應占據很大的比重，以確保(開發人員)明白問題的實質。
線程/同步
由同步所產生的問題往往很難辨認，但是其對性能的影響卻非常顯著。
對同步的最根本的需要在于Java對并發的支持，這通過在相同的過程中執行不同的線程(thread)代碼來實現。單獨的線程之間可以共享相同的資源，以及內存中的對象。雖然是一種完成更多工作的有效方法(當以線程在等待I/O操作完成期間，另一線程可利用CPU來進行計算)，但是也曝露出應用的干擾和一致性問題。
為防止這種情況，程序員在程序中引入“synchronized”關鍵字來強制并發線程的執行順序。利用“synchronized”來防止線程在同一時間獲得同一資源，并防止數據不一致。
然而在實踐中，這個簡單的機制卻帶來很大的副作用。現代企業的應用常采用多線程的實現模式，同時執行多個線程，對“共享”對象的爭奪也隨之加劇，同步將有效地強制并發處理轉而為順序執行。
目前，對于線程和同步問題沒有銀彈(silver bullet)。某些開發者依賴“防御”性編程方法，諸如加鎖;而另一些開發者，則依賴STM(Software Transactional Memory Systems)來緩解這個問題。最好的開發組織是那些可以平衡代碼審查/重寫負擔和性能問題的團隊。
這些只是Java開發人員每天必須面對的應用性能問題，有許多有用的性能工作可以大大減少此類問題。
原文鏈接：http://mavforcezt1008.iteye.com/blog/1002469
【編輯推薦】
