Java是一種偉大的語(yǔ)言。它管理內(nèi)存，傳授面向?qū)ο蟮木幊?思想)，使我們更好地用它來(lái)編碼。另外，它確實(shí)是一種“編寫(xiě)一次，到處運(yùn)行“的語(yǔ)言。然而，Java應(yīng)用程會(huì)遇到一些常見(jiàn)的開(kāi)發(fā)者和應(yīng)用者獨(dú)耳熟能詳?shù)男阅芴魬?zhàn)。

內(nèi)存泄露

Java的最大的好處之一是它能夠管理內(nèi)存模型。當(dāng)對(duì)象不再使用時(shí)，Java會(huì)做清理工作。較舊的語(yǔ)言需要人工來(lái)管理內(nèi)存，但開(kāi)發(fā)者寧愿花時(shí)間專(zhuān)注于核心語(yǔ)言邏輯而不愿為內(nèi)存分配而憂(yōu)心。

話(huà)雖如此，卻不能保證Java的內(nèi)存管理沒(méi)有問(wèn)題，提供管理內(nèi)存模型，或創(chuàng)建/銷(xiāo)毀未使用的對(duì)象，(這些對(duì)象)都放在Java的“堆(Heap)“中，內(nèi)存泄露通常是不正確編程的結(jié)果–通常，開(kāi)發(fā)者沒(méi)有消除某一對(duì)象的所有引用，因此，堆(空間)逐步耗盡，應(yīng)用程序也將死機(jī)。

大多數(shù)人使用堆轉(zhuǎn)儲(chǔ)和/或事件探查器(profiler)來(lái)診斷內(nèi)存泄漏。堆轉(zhuǎn)儲(chǔ)使你可看到哪個(gè)對(duì)象持有對(duì)集合的引用。它告訴你集合何處，但不能告訴你誰(shuí)在存取該集合或其它能讓你探究根源的特性。堆轉(zhuǎn)儲(chǔ)通常占用的空間也相當(dāng)大，在千兆字節(jié)，分析并打開(kāi)一個(gè)堆轉(zhuǎn)儲(chǔ)需要大量資源，然后讀取它，并找出問(wèn)題所在。

第二種方法，是組合堆轉(zhuǎn)儲(chǔ)和事件探查器，使你能接近點(diǎn)問(wèn)題本質(zhì)，但并不多。內(nèi)存分析器盡力幫助您分析您的堆轉(zhuǎn)儲(chǔ)。他們有實(shí)時(shí)數(shù)據(jù)，現(xiàn)在可知道是誰(shuí)創(chuàng)建的對(duì)象，但仍不知造成泄漏的真正根由。

堆轉(zhuǎn)儲(chǔ)和分析器都有益于開(kāi)發(fā)和預(yù)生產(chǎn)，然而，一旦應(yīng)用程序失控，分析器也不可用。隔離并解決內(nèi)存泄漏最有效的方法來(lái)之一是通過(guò)事務(wù)(transaction)(管理)和代碼路徑分析。通過(guò)采取事務(wù)快照，可以獲得問(wèn)題所在及其原因，這通常會(huì)導(dǎo)致更少的停機(jī)時(shí)間和更好的MTTR。

緩慢的SQL

幾乎每一應(yīng)用程序都會(huì)使用JDBC數(shù)據(jù)庫(kù)。應(yīng)用中一個(gè)非常普遍的問(wèn)題是糟糕的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ì)于許多開(kāi)發(fā)人員而言，(ORM)這項(xiàng)技術(shù)可以消除需要升入探討著兩種技術(shù)如何相互作用的復(fù)雜度。然而，ORM使得應(yīng)用需承受額外的負(fù)擔(dān)，并極大地影響應(yīng)用的性能，而一切表面上看起來(lái)很好。

在大多數(shù)情況下，檢索數(shù)據(jù)所消耗的時(shí)間和占用資源的數(shù)量級(jí)遠(yuǎn)大于數(shù)據(jù)處理所需的時(shí)間及資源，因此，性能方面的考慮常包含訪(fǎng)問(wèn)和存儲(chǔ)數(shù)據(jù)的工具和方法就不足為奇了。

雖然開(kāi)發(fā)人員直觀地使用(隱藏復(fù)雜性)，但ORM在應(yīng)用性能方面應(yīng)占據(jù)很大的比重，以確保(開(kāi)發(fā)人員)明白問(wèn)題的實(shí)質(zhì)。

線(xiàn)程/同步

由同步所產(chǎn)生的問(wèn)題往往很難辨認(rèn)，但是其對(duì)性能的影響卻非常顯著。

對(duì)同步的最根本的需要在于Java對(duì)并發(fā)的支持，這通過(guò)在相同的過(guò)程中執(zhí)行不同的線(xiàn)程(thread)代碼來(lái)實(shí)現(xiàn)。單獨(dú)的線(xiàn)程之間可以共享相同的資源，以及內(nèi)存中的對(duì)象。雖然是一種完成更多工作的有效方法(當(dāng)以線(xiàn)程在等待I/O操作完成期間，另一線(xiàn)程可利用CPU來(lái)進(jìn)行計(jì)算)，但是也曝露出應(yīng)用的干擾和一致性問(wèn)題。

為防止這種情況，程序員在程序中引入“synchronized”關(guān)鍵字來(lái)強(qiáng)制并發(fā)線(xiàn)程的執(zhí)行順序。利用“synchronized”來(lái)防止線(xiàn)程在同一時(shí)間獲得同一資源，并防止數(shù)據(jù)不一致。

然而在實(shí)踐中，這個(gè)簡(jiǎn)單的機(jī)制卻帶來(lái)很大的副作用。現(xiàn)代企業(yè)的應(yīng)用常采用多線(xiàn)程的實(shí)現(xiàn)模式，同時(shí)執(zhí)行多個(gè)線(xiàn)程，對(duì)“共享”對(duì)象的爭(zhēng)奪也隨之加劇，同步將有效地強(qiáng)制并發(fā)處理轉(zhuǎn)而為順序執(zhí)行。

目前，對(duì)于線(xiàn)程和同步問(wèn)題沒(méi)有銀彈(silver bullet)。某些開(kāi)發(fā)者依賴(lài)“防御”性編程方法，諸如加鎖;而另一些開(kāi)發(fā)者，則依賴(lài)STM(Software Transactional Memory Systems)來(lái)緩解這個(gè)問(wèn)題。最好的開(kāi)發(fā)組織是那些可以平衡代碼審查/重寫(xiě)負(fù)擔(dān)和性能問(wèn)題的團(tuán)隊(duì)。

這些只是Java開(kāi)發(fā)人員每天必須面對(duì)的應(yīng)用性能問(wèn)題，有許多有用的性能工作可以大大減少此類(lèi)問(wèn)題。

原文鏈接：http://mavforcezt1008.iteye.com/blog/1002469

【編輯推薦】

1. 全面解析Java的垃圾回收機(jī)制
2. 你不知道的5個(gè)JVM命令行標(biāo)志
3. Eclipse中進(jìn)行JVM內(nèi)存設(shè)置
4. 解析JVM和JIT診斷技術(shù)的用法