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