【正文】 出足夠的空間，就是象這樣的拷貝收集(copy collection)，就運行大幅度的收集，就是讓所有的東西停止(stoptheworld collection)。例如，你可能在不經(jīng)意間引用了一個Person對象，但是這個對象包含一個Profile對象，此對象還包含了許多擁有一系列數(shù)據(jù)的PerformanceReview對象。如果JVM里運行的程序, 它的內(nèi)存堆和持久存儲區(qū)域的都滿了，這個時候程序還想創(chuàng)建對象實例的話，垃圾收集器就會啟動，試圖釋放足夠的內(nèi)存來創(chuàng)建這個對象。在這方面，我覺得我很象一個汽車修理工人:你告訴修理工人發(fā)動機有聲音，他就會詢問你一系列的問題，幫你回憶發(fā)動機運行的情形。從這些信息中，他尋找到可能引起問題的原因。這個時候如果垃圾收集器沒有能力釋放出足夠的內(nèi)存，它就會拋出OutOfMemoryError內(nèi)存溢出錯誤。這樣不只是丟失了那個Person對象所占據(jù)的100 bytes的內(nèi)存，你丟失了這一系列相關對象所占據(jù)的內(nèi)存空間，可能是高達500KB甚至更多。運行這個大幅度的調(diào)整收集時，垃圾收集器就停止所有在堆中運行的線程并執(zhí)行清除動作(markandsweep collection)，把新一代空間釋放空并準備重啟程序?！　∩厦嫠v解的東西是為了更好的幫助我們識別出內(nèi)存泄漏。陰影表示在經(jīng)過大幅度的收集后幸存下來的對象，這些對象是潛在可能引發(fā)內(nèi)存泄漏的對象　　一部分這些相關的信息是可以通過跟蹤API得到，更詳細的信息通過詳細的垃圾收集器的日志也可以看到。這個堆是這樣運行的:在一開始運行的時候，它會很小，隨著對象實例不斷的填充，在需要執(zhí)行垃圾收集的地方清除掉無效的對象同時把所有有效的對象緊湊的放置到堆的底部。比如，我可能會將我的請求反復運行17次，希望我的泄漏分析能夠得到17個情況(或更多)?！　√摷賰?nèi)存泄漏　　少數(shù)的一些問題看起來是內(nèi)存泄漏實際上并非如此。這些區(qū)域就是:　　1. 頁面區(qū)域 　　2. 請求區(qū)域 　　3. 上下文區(qū)域 　　4. 應用程序區(qū)域 　　5. 靜態(tài)變量 　　6. 長生命周期的變量，例如SERVLET　　當實現(xiàn)一些JSP(JAVASERVER頁面)時，在頁面上聲明的變量在頁面結(jié)束的時候就被釋放，這些變量僅僅在這個單獨的頁面存在時存在。作為一個無狀態(tài)的協(xié)議，它總是客戶端發(fā)起連接請求，服務器需要知道一個會話存在多長時間，到時候就應該釋放這個用戶的數(shù)據(jù)。因此，如果一個程序在靜態(tài)變量中存放了一個對象，如果這個變量生命周期沒有到，那么這個對象就不會被JVM釋放?！　‘斣陧撁婊蛘哒埱蠓秶欣米兞看娣艑ο蟮臅r候，在他們結(jié)束的時候這些對象會自動釋放。增加足夠的堆空間以使它能夠存儲所有應該保存的有效值，也意味著你必須有足夠的內(nèi)存去存儲所有訪問你站點的用戶的有效會話。Figure 6. The relationship between the permanent space and the heap　　通常，你可能想讓你的持久空間足夠大以便于它能夠裝載你程序所有的類，因為很明顯，從文件系統(tǒng)中讀取類文件比從內(nèi)存中裝載代價高很多。他的環(huán)境已經(jīng)造成了持久空間溢出，但是在堆中由于用了 noclassgc 選項，于是JVM并不去釋放類文件來裝載新的類文件。和內(nèi)存最大的沖突就是程序服務器所設置的線程池的大小。這個時候，CPU的利用率會非常低，因為程序服務器沒有時間去指揮CPU工作。因此，為第一個程序配置的池大小是100就有點太小了，因為程序能夠同時處理200個?！　∵B接池過大的最主要的跡象就是CPU的使用率一直很高。如果所有的車輛都同時涌向公里，我們就動彈不得，但是只要減緩涌向高速公路車輛的速度，交通遲早會暢通。我們調(diào)試的目的就是盡量減少請求的等待時間和飽和的資源之間之間的沖突，讓一個請求在數(shù)據(jù)庫外等待要比強迫數(shù)據(jù)庫好的多。prepared statement 緩存區(qū)設置不恰當最主要的癥狀就是花費大量的時間去連接相同的statement。也就是，售貨員被放入池中共享，因為你只需要是售貨員就可以，而不是一個叫做史締夫的這個售貨員。初始化以后，你應該跟蹤passivation的數(shù)量并把它和與向緩存請求對象的請求的總量相比較，因為passivations只會發(fā)生在緩存被初始化以后。如果你的程序過了一會又需要這個一摸一樣的BEAN，就從池中再得到一個實例，但不能保證你得到的就是上一個實例。通過JAVAEE 5 EJB(Enterprise javaBeans)的注釋，你可以控制事務中方法的使用。有三種情形的非程序回滾:　　1. 系統(tǒng)回滾 　　2. 超時回滾 　　3. 資源回滾　　系統(tǒng)回滾意味著程序服務器中的一些東西非常的糟糕，恢復的幾率很渺茫。這篇文章的注意力并不是放在程序代碼的問題上，因為把注意力放在因為環(huán)境的問題而導致的低性能的問題上:　　 　　 　　 　　 　　 　　 　　　　為了有效的診斷性能的問題，你應該了解什么問題會導致什么樣的癥狀。　　問題的根源依賴于很多要素，但是一些指示器可以增加一些你處理問題時候的一些信心，依靠他們可以完全排除一些其他的原因。除非你把超時設置的很短才會出現(xiàn)這種錯誤?；貪L會是下面2種情況:　　1. 程序造成的回滾(程序回滾) 　　2. 非程序造成的回滾(非程序回滾)　　通常，程序回滾是因為商業(yè)的規(guī)定。如果你無法從池中得到想要的BEAN，請求就會等待，一直到這個BEAN被放入到池中。如果miss ratio超過25%，那么緩存可能是太小了。這個時候，孩子就需要被緩存?！　∈虑樽兊纳晕碗s了點，緩存prepared statement 是每個statement的基礎，就是說在一個statement連接之前都應當緩存起來。當你的程序在數(shù)據(jù)庫中運行SQL statement 的時候三下面3個步驟進行:　　 　　 　　　　在準備階段，數(shù)據(jù)庫驅(qū)動器讓數(shù)據(jù)庫完成隊列中的執(zhí)行計劃。設置一個飽和的池，然后逐步減少連接池大小，一直到CPU占用率為75%到85%之間，同時用戶負載正常?！　∵@個情況發(fā)生的時候，請求會被放在隊列中不被處理，但是不會始終如此，因為請求占用CPU的情況和程序占用的情況造成的后果不同?！　〉?，很多程序并沒有在這種情況下動態(tài)的去調(diào)整的功能。當你觀測吞吐量的時候，如果你發(fā)現(xiàn)吞吐量降低了，你就應該把池的大小下調(diào)一個幅度，一直到找到讓它保持最大吞吐量的大小為止。如果池太小，請求就需要在隊列中等待程序處理，如果太大，CPU就需要花費太多的時間在這些眾多的線程之間來回的切換?！　≌駡D7顯示的，當持久空間變滿了的時候，就引發(fā)垃圾收集，清理了樂園和幸存者空間，但是并不釋放持久空間中的一點內(nèi)存。這個參數(shù)選項很聰明，但是會引起一個問題:當持久空間滿了以后依然需要裝載新文件的時候JVM