【正文】 池太小，請求就需要在隊列中等待程序處理，如果太大，CPU就需要花費太多的時間在這些眾多的線程之間來回的切換。把持久空間設(shè)置成512M大小就象給一個腳痛的人吃止痛藥，雖然暫時緩解了痛，但是腳還是沒有好，依然需要醫(yī)生把痛治療好，否則只是把問題延遲了而已?！　≌駡D7顯示的，當持久空間變滿了的時候，就引發(fā)垃圾收集，清理了樂園和幸存者空間，但是并不釋放持久空間中的一點內(nèi)存。在我調(diào)查了詳細的關(guān)于堆和程序內(nèi)存利用的收集器的記錄后，我迅速發(fā)覺堆的狀態(tài)非常正常，但程序確發(fā)生了內(nèi)存溢出。這個參數(shù)選項很聰明，但是會引起一個問題:當持久空間滿了以后依然需要裝載新文件的時候JVM會怎么處理呢?我觀測到的資料說明:如果JVM檢測到持久空間還需要內(nèi)存，就會調(diào)用主垃圾收集程序。JVM利用程序的內(nèi)存來裝載字節(jié)流文件，這個內(nèi)存空間稱為持久空間?？偨Y(jié)下，你應(yīng)該依據(jù)合理性和重要性按下面的步驟依次去執(zhí)行:　　1. 重構(gòu)程序，盡量減少擁有session范圍的變量所存儲的信息量 　　2. 鼓勵你的客戶在他們使用完后，明確的釋放會話 　　3. 縮短超時的時間，以便于讓你內(nèi)存盡快的得到回收 　　4. 增加你堆空間的大小　　無論如何，不要讓程序范圍級的變量，靜態(tài)變量，長生命周期的類存儲對象，事實上，你需要在內(nèi)存模擬器中去分析泄漏?！　⊥ǔ碚f，如果你執(zhí)行了一個很大的會話，你應(yīng)該盡量去減少它所占用的內(nèi)存空間，如果可以的話最好能重構(gòu)程序，以減少session所占據(jù)的內(nèi)存空間?！　『芏嗫雌饋硐髢?nèi)存泄漏的情況都是上面的那些會話中的泄漏。在他們自己內(nèi)部本身存貯這些緩存配置是個不錯的選擇，但存貯在SERVLET中是最糟糕的情況?！　∽詈螅瑢ο竽軌虮环诺絻?nèi)部數(shù)據(jù)類型或者長生命周期類中的成員變量中，例如SERVLET?！　∪绻麛?shù)據(jù)不是存儲這個四個地方(頁面范圍，請求范圍，會話范圍，程序范圍)那就可能存儲在下面的對象中:　　1. 靜態(tài)變量 　　2. 長生命周期的類變量　　每個類的靜態(tài)變量被JVM(JAVA虛擬機)所控制，他們存在與否和類是否已經(jīng)被初始化無關(guān)。除非明確的要求釋放對象或者這個會話失效，否則在會話超時之前會話中的對象會一直存在。屬性和參數(shù)被放在各自用戶的HttpSession對象中，并通過它讓程序的SERVLET和JSP交流。你的動態(tài)頁面依靠HttpServletRequest在不同的組件之間傳輸信息，但當請求完成或者socket結(jié)束的時候，SERVLET控制器會釋放所有在HttpServletRequest 中的對象。如果是上升，這個時候就需要分析內(nèi)存中的SESSION了。危險是:一些生命周期長的對象需要裝載到堆中，因此在堆達到穩(wěn)定狀態(tài)且包含了核心對象之前具有很大的欺騙性。這個報告并不能告訴你造成泄漏的是代碼還是某個對象，而是告訴你在內(nèi)存模擬器中應(yīng)該留意那些類型的請求。　　如果你無法明確的判斷泄漏是因為請求引發(fā)的，你有2個選擇:　　1. 模擬每一個被懷疑的請求直至發(fā)現(xiàn)內(nèi)存泄漏 　　2. 存配置一個內(nèi)存性能跟蹤工具　　第一個選項在小應(yīng)用程序中是確實可用的或者你非常走運的解決了問題，但對大型應(yīng)用程序不太有用?！　∵@個時候，你需要去和開發(fā)者交流，告訴他你所碰到的棘手的請求，他們可以判斷究竟是對象泄漏還是為了某個目的特地讓對象保留下來的。把你的程序放入到運行環(huán)境中，并在內(nèi)存模擬器中運行，按下面的步驟來:　　1. 在內(nèi)存模擬器中運行你的應(yīng)用程序 　　2. 執(zhí)行使用方案(制造請求)以便讓程序在內(nèi)存中裝載請求所需要的所有的對象，這可以為以后詳細的分析排除不必要的干擾 　　3. 在執(zhí)行使用方案前對堆進行拍照以便捕獲其中所有運行的對象。IBM JVM內(nèi)存管理模式　　IBM的JVM的機制有一點不同。為了能夠判斷內(nèi)存是否泄漏，我使用了能夠顯示輩分之間所有的不同的較權(quán)威的技術(shù)來顯示他們的區(qū)別，并以此來得到結(jié)果。如果內(nèi)存泄漏的確存在，這些造成泄漏的對象就會不斷的占據(jù)空間，直至造成內(nèi)存溢出。采用這種機制的SUN 虛擬機，對象不會被丟棄，而是利用自己特有的方法把他們從樂園和幸存者空間移動到老一代地區(qū)?！　∫陨暇褪荢UN實現(xiàn)的垃圾收集器機制，你可以看出在老一代中的對象會被大幅度調(diào)整器收集清除。對象在EDEN被創(chuàng)建一直到這個空間變滿。如果填充到第二個生存者空間中的有效對象被第一個生存者空間或EDEN中的對象引用，那么這些對象就是長期存在的(也就是說，他們被拷貝到老一代)。我使用以下2種方法來判斷:　　深入分析內(nèi)存數(shù)據(jù) 　　觀察堆的增長方式　　不同JVM(JAVA虛擬機)的調(diào)整程序的運作方式是不相同的，例如SUN和IBM的JVM，但都有相同的的地方。而且，大多數(shù)這些泄漏的對象并不是象DOUBLE或者INTEGER這樣的簡單對象，而可能是存在于堆中一系列相關(guān)的對象?；貞浬厦嫠懻摰膬?nèi)容，內(nèi)存泄漏的原因是一個對象雖然不被使用了，但是依然還有對象引用他?！　∫l(fā)outofmemory 錯誤的原因　　在你打算解決outofmemory 錯誤之前，首先了解為什么會引發(fā)這個錯誤對你有很大的幫助。了解應(yīng)用程序的體系結(jié)構(gòu)和問題表現(xiàn)出的癥狀，這些工作很夠很大程度上提高我解決問題的幾率。作為一個JAVAEE問題解決專家，我曾經(jīng)面對過眾多的環(huán)境同時也寫了不少常見問題的觀察報告?！　ava EE(Java企業(yè)開發(fā)平臺)應(yīng)用程序，無論應(yīng)用程序服務(wù)器如何部署，所面對的一系列問題大致相同?！　”姸嘟鉀Q問題的方法思路基本相同，第一天我同要解決問題的客戶接觸，接觸的時候，我會尋找已經(jīng)出現(xiàn)的問題以及造成的負面的影響?！　?nèi)存溢出錯誤　　最常見的折磨著企業(yè)級應(yīng)用程序的錯誤是讓人恐懼的outofmemoryError(內(nèi)存溢出錯誤)　　這個錯誤引起下面這些典型的癥狀:　　應(yīng)用服務(wù)器崩潰 　　性能下降 　　一個看起來好像無法結(jié)束的死循環(huán)在重復(fù)不斷的執(zhí)行垃圾收集，它會導致程序停止運行，并且經(jīng)常導致應(yīng)用服務(wù)器崩潰　　不管癥狀是什么，如果你想讓程序恢復(fù)正常運行，你一般都需要重新啟動應(yīng)用服務(wù)器?！　utofmemory錯誤一般是JAVA內(nèi)存泄漏引起的。在WEB REQUESTS中這種類型的的內(nèi)存泄漏很典型，一兩個內(nèi)存對象的泄漏可能不會導致程序服務(wù)器的崩潰，但是10000或者20000個就可能會導致這個惡果。　　為了尋找這個問題的真正根源，你需要判斷是內(nèi)存泄漏還是以O(shè)utOfMemoryError形式出現(xiàn)的其他一些故障。當EDEN再次變滿了的時候，就啟動移動程序把EDEN中有效的對象拷貝到第二個幸存者空間，同時，也將第一個幸存者空間中的有效對象拷貝到第二個幸存者空間?！　D2和圖3展示的是了小幅度收集如何運行圖2。圖4展示了一個小幅度調(diào)