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