【正文】 老一代內(nèi)容是不是按一定的原理來(lái)增長(zhǎng)?　圖5。如果執(zhí)行完后并沒(méi)有發(fā)現(xiàn)內(nèi)存泄漏的情況，我一般會(huì)轉(zhuǎn)到步驟4再進(jìn)行多次類似的跟蹤。發(fā)生泄漏的session　　WEB請(qǐng)求經(jīng)常導(dǎo)致內(nèi)存泄漏，在一個(gè)WEB請(qǐng)求中，對(duì)象會(huì)被限制存儲(chǔ)在有限的幾個(gè)區(qū)域。一個(gè)類的所有實(shí)例共用一個(gè)存儲(chǔ)靜態(tài)變量的地方，因此在任何一個(gè)實(shí)例中修改靜態(tài)變量會(huì)影響這個(gè)類的其他實(shí)例。下面2種方法可以降低大會(huì)話和內(nèi)存的沖突:　　1. 增大堆的空間以支持你的大會(huì)話 　　2. 縮短會(huì)話的超時(shí)時(shí)間，讓它能夠快速的失效　　一個(gè)巨大的堆會(huì)導(dǎo)致垃圾回收花費(fèi)更多的時(shí)間，因此這不是一個(gè)好解決方法，但總比發(fā)生OutofMemoryError強(qiáng)。這個(gè)用戶維持了數(shù)千的JSP頁(yè)面，在裝載到內(nèi)存前把他們都編譯成了字節(jié)流文件放入持久空間。特別是，我在看到下面這些信息的時(shí)候:　　 　　(在隊(duì)列中等待處理)　　當(dāng)一個(gè)線程池被待處理的請(qǐng)求裝滿的時(shí)候，響應(yīng)的時(shí)間就變的極其糟糕，因?yàn)檫@些在隊(duì)列中等待處理的請(qǐng)求會(huì)消耗很多的額外時(shí)間。當(dāng)這些環(huán)境中的負(fù)載量不斷增大的時(shí)候，CPU的使用率會(huì)持續(xù)無(wú)法降低，就沒(méi)有什么響應(yīng)請(qǐng)求的時(shí)間了，因?yàn)镃PU只顧的在眾多的線程之間來(lái)回的切換跳動(dòng)，沒(méi)時(shí)間讓線程去做他們應(yīng)該做的事了。反過(guò)來(lái)，如果數(shù)據(jù)庫(kù)連接池太大程序服務(wù)器就會(huì)浪費(fèi)資源，并且程序有可能強(qiáng)迫數(shù)據(jù)庫(kù)承受過(guò)量的負(fù)荷。類似的，你考慮一個(gè)超市類似的情況，你需要個(gè)售貨員但他叫什么并不重要，任何售貨員都可以滿足你。當(dāng)你的程序需要使用這些BEAN的商業(yè)功能的時(shí)候，它就從一個(gè)池中取出一個(gè)BEAN實(shí)例，用這個(gè)實(shí)例來(lái)調(diào)用一個(gè)個(gè)方法，用完后再將BEAN的實(shí)例再放回到池中。　　另一方面，非程序回滾是非常糟糕的。我希望這個(gè)文章能對(duì)你排解JAVAEE環(huán)境問(wèn)題起到幫助。比如一個(gè)WEB程序做一個(gè)素描畫(huà)的價(jià)格的調(diào)查，程序可能讓用戶輸入年齡，并且商業(yè)規(guī)定18歲以上才可以進(jìn)入。因此，如果missratio的數(shù)量超過(guò)75%，那么不是你的緩存設(shè)置的太小就是你不需要緩存這個(gè)技術(shù)。這個(gè)增加的復(fù)雜性就產(chǎn)生了一個(gè)沖突:如果你有100個(gè)prepared statement需要去緩存，但你的連接池中有50個(gè)數(shù)據(jù)庫(kù)連接，這個(gè)時(shí)候你就需要有存放5000條預(yù)備語(yǔ)句的內(nèi)存。如果等待隊(duì)列大小實(shí)在無(wú)法控制，考慮下面2中建議:　　，調(diào)整程序代碼 　　　　如果你的用戶負(fù)載超過(guò)了環(huán)境能承受的范圍，你應(yīng)該考慮修正代碼減少和CPU的沖突或者增加CPU。多數(shù)情況下是做相同的事，但是應(yīng)該為他們劃分范圍?！　∶總€(gè)服務(wù)器都有一個(gè)SOCKET負(fù)責(zé)監(jiān)聽(tīng)。垃圾收集器清除堆，但它并不會(huì)對(duì)持久空間進(jìn)行任何操作，因此它的努力是白費(fèi)的。一個(gè)造成泄漏的會(huì)話并不是泄漏了內(nèi)存而是類似于泄漏，它消耗了內(nèi)存，但最終這些內(nèi)存都會(huì)被釋放的?！　≌鐂ession是為每個(gè)用戶管理對(duì)象一樣，ServletContext為整個(gè)程序管理對(duì)象。在分析堆之前，應(yīng)該讓?xiě)?yīng)用程序達(dá)到穩(wěn)定狀態(tài)。 　　4. 再次運(yùn)行使用方案。因此，在一個(gè)基于多用戶的WEB環(huán)境，如果許多請(qǐng)求造成了泄漏，你就會(huì)發(fā)現(xiàn)老一代的增長(zhǎng)?！　UN JVM的內(nèi)存管理方式　　SUN的JVM是類似人類家族，也就是在一個(gè)地方創(chuàng)建對(duì)象，在它長(zhǎng)期占據(jù)空間之前給它多次死亡的機(jī)會(huì)。在這一節(jié)，我分享我在這個(gè)領(lǐng)域遇過(guò)的常見(jiàn)問(wèn)題和他們的癥狀。希望這篇文章能成為你JAVAEE的故障檢測(cè)手冊(cè)?！　UN JVM會(huì)劃分為:　　1 年輕的一代(Young generation)，包括EDEN和2個(gè)幸存者空間(出發(fā)地和目的地the From space and the To space) 　　2 老一代(Old generation) 　　3 永久的一代(Permanent generation)圖1 解釋了SUN 堆的家族和空間的詳細(xì)分類對(duì)象在EDEN出生就是被創(chuàng)建，當(dāng)EDEN滿了的時(shí)候，垃圾收集器就把所有在EDEN中的對(duì)象掃描一次，把所有有效的對(duì)象拷貝到第一個(gè)幸存者空間，同時(shí)把無(wú)效的對(duì)象所占用的空間釋放?！　D5顯示了那些潛在可能造成泄漏的對(duì)象:主收集器收集后遺留下來(lái)占據(jù)空間的對(duì)象會(huì)越來(lái)越多。 　　5. 再次拍照，來(lái)捕獲使用方案運(yùn)行之后堆中所有對(duì)象的狀態(tài)?！　榱伺袛嗍欠襁^(guò)早的對(duì)堆進(jìn)行分析，持續(xù)2個(gè)小時(shí)對(duì)跟蹤到的分析快照進(jìn)行分析，看堆的使用率是上升還是下降。ServletContext的有效范圍是整個(gè)程序，因此你可以利用Servlet中的ServletContext或者JSP應(yīng)用程序?qū)ο笤谒械腟ervlet和JSP之間讓在這個(gè)程序中的所有用戶共享數(shù)據(jù)。如果程序服務(wù)器發(fā)生內(nèi)存溢出，判斷是內(nèi)存泄漏還是內(nèi)存缺乏的最好的方法就是:停止所有向這個(gè)服務(wù)器所發(fā)的請(qǐng)求的對(duì)象，等待會(huì)話超時(shí)，看內(nèi)存時(shí)候會(huì)被釋放出來(lái)。于是JVM就再重新檢測(cè)持久空間，看它是否滿，然后再次執(zhí)行程序，一遍的一遍重復(fù)。程序把接受到的請(qǐng)求放到待執(zhí)行隊(duì)列中，然后將這個(gè)請(qǐng)求從隊(duì)列移動(dòng)到線程中被程序處理。因此，我建議你為一個(gè)CPU分配50到75個(gè)左右的線程?！　DBC連接池　　很多JAVA EE 程序連接到一個(gè)后臺(tái)數(shù)據(jù)源，大多數(shù)是通過(guò)JDBC(JAVA DATABASE CONNECTIVITY)將程序和后臺(tái)連接起來(lái)?！　⊥ㄟ^(guò)跟蹤性能，確定出你程序所執(zhí)行的不重復(fù)的statement 的數(shù)量，并從這些statement 中找出哪些條是頻繁執(zhí)行的?！　∫坏┠阌X(jué)得你的緩存太小，就去嘗試著增大大小，并測(cè)試增加的性能。如果一個(gè)16歲的提交了信息，那么程序就會(huì)拋出一個(gè)錯(cuò)誤，打開(kāi)一個(gè)網(wǎng)頁(yè)告訴他，他年齡還不能參與到這個(gè)信息的調(diào)查。原文（英文）。這只是普通的程序回滾，只有當(dāng)發(fā)生大量的程序回滾才值得我們注意?！　taless session bean和messagedriven bean池　　Stateless session bean 和messagedriven bean 在商業(yè)應(yīng)用方面很重要，不要期望它們會(huì)保持自己特有的狀態(tài)信息。當(dāng)你需要一個(gè)有狀態(tài)對(duì)象時(shí)，你需要明確創(chuàng)建這個(gè)對(duì)象的特定實(shí)例，普通的實(shí)例是不能滿足的。如果一個(gè)請(qǐng)求需要連接到數(shù)據(jù)庫(kù)，但是數(shù)據(jù)庫(kù)的連接池?zé)o法為這個(gè)請(qǐng)求創(chuàng)建一個(gè)新連接，這個(gè)時(shí)候請(qǐng)求就會(huì)停下來(lái)等待連接池完成自己的操作再給她分配一個(gè)連接?！　【€程池太大　　除了線程池?cái)?shù)量太小之外的情況外，環(huán)境也可能把線程數(shù)量配置的過(guò)大。Figure 8. 服務(wù)器處理請(qǐng)求的次序結(jié)構(gòu)線程池太小　　每當(dāng)我碰到有人抱怨裝載速度的性能隨著裝載的數(shù)量的增加變的越來(lái)越糟糕的時(shí)候，我會(huì)首先檢查線程池。在我調(diào)查了詳細(xì)的關(guān)于堆和程序內(nèi)存利用的收集器的記錄后，我迅速發(fā)覺(jué)堆的狀態(tài)非常正常，但程序確發(fā)生了內(nèi)存溢出。　　通常來(lái)說(shuō)，如果你執(zhí)行了一個(gè)很大的會(huì)話，你應(yīng)該盡量去減少它所占用的內(nèi)存空間，如果可以的話最好能重構(gòu)程序，以減少session所占據(jù)