java虛擬機(jī)(jvm)調(diào)優(yōu)案例分析與myeclipse性能調(diào)優(yōu)實(shí)戰(zhàn)

《java虛擬機(jī)(jvm)調(diào)優(yōu)案例分析與myeclipse性能調(diào)優(yōu)實(shí)戰(zhàn)》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫(kù)。

1、第6講-Java虛擬機(jī)調(diào)優(yōu)案例分析與MyEclipse性能調(diào)優(yōu)實(shí)戰(zhàn)軟件工程系潘正軍主要內(nèi)容大綱案例分析實(shí)戰(zhàn)：MyEclipse運(yùn)行性能調(diào)優(yōu)本節(jié)內(nèi)容引入前面課程介紹了處理Java虛擬機(jī)內(nèi)存問(wèn)題的知識(shí)與工具，在處理實(shí)際項(xiàng)目的問(wèn)題時(shí)，除了知識(shí)與工具外，經(jīng)驗(yàn)同樣是一個(gè)很重要的因素。因此本章將與讀者分享幾個(gè)比較有代表性的實(shí)際案例?？紤]到虛擬機(jī)故障處理和調(diào)優(yōu)主要面向各類服務(wù)端應(yīng)用，而大部分Java程序員較少有機(jī)會(huì)直接接觸生產(chǎn)環(huán)境的服務(wù)器，因此本章還準(zhǔn)備了一個(gè)所有開發(fā)人員都能夠進(jìn)行“親身實(shí)戰(zhàn)”的練習(xí)，希望通過(guò)

2、實(shí)踐使讀者獲得故障處理和調(diào)優(yōu)的經(jīng)驗(yàn)。一、案例分析1-高性能硬件上的程序部署策略1.高性能硬件上的程序部署策略例如，一個(gè)15萬(wàn)PV（pageview）/天左右的在線文檔類型網(wǎng)站最近更換了硬件系統(tǒng)，新的硬件為4個(gè)CPU、16GB物理內(nèi)存，操作系統(tǒng)為64位CentOS5.4，Resin作為Web服務(wù)器。整個(gè)服務(wù)器暫時(shí)沒(méi)有部署別的應(yīng)用，所有硬件資源都可以提供給這訪問(wèn)量并不算太大的網(wǎng)站使用。管理員為了盡量利用硬件資源選用了64位的JDK1.5，并通過(guò)-Xmx和-Xms參數(shù)將Java堆固定在12GB。使用一

3、段時(shí)間后發(fā)現(xiàn)使用效果并不理想，網(wǎng)站經(jīng)常不定期出現(xiàn)長(zhǎng)時(shí)間失去響應(yīng)的情況。監(jiān)控服務(wù)器運(yùn)行狀況后發(fā)現(xiàn)網(wǎng)站失去響應(yīng)是由GC停頓導(dǎo)致的，虛擬機(jī)運(yùn)行在Server模式，默認(rèn)使用吞吐量?jī)?yōu)先收集器，回收12GB的堆，一次FullGC的停頓時(shí)間高達(dá)14秒。并且由于程序設(shè)計(jì)的關(guān)系，訪問(wèn)文檔時(shí)要把文檔從磁盤提取到內(nèi)存中，導(dǎo)致內(nèi)存中出現(xiàn)很多由文檔序列化產(chǎn)生的大對(duì)象，這些大對(duì)象很多都進(jìn)入了老年代，沒(méi)有在MinorGC中清理掉。這種情況下即使有12GB的堆，內(nèi)存也很快被消耗殆盡，由此導(dǎo)致每隔十幾分鐘出現(xiàn)十幾秒的停頓，令網(wǎng)站

4、開發(fā)人員和管理員感到很沮喪。一、案例分析1-高性能硬件上的程序部署策略在高性能硬件上部署程序，目前主要有兩種方式：1.通過(guò)64位JDK來(lái)使用大內(nèi)存。2.使用若干個(gè)32位虛擬機(jī)建立邏輯集群來(lái)利用硬件資源。此案例中的管理員采用了第一種部署方式。對(duì)于用戶交互性強(qiáng)、對(duì)停頓時(shí)間敏感的系統(tǒng)，可以給Java虛擬機(jī)分配超大堆的前提是有把握把應(yīng)用程序的FullGC頻率控制得足夠低，至少要低到不會(huì)影響用戶使用，譬如十幾個(gè)小時(shí)乃至一天才出現(xiàn)一次FullGC，這樣可以通過(guò)在深夜執(zhí)行定時(shí)任務(wù)的方式觸發(fā)FullGC甚至自動(dòng)

5、重啟應(yīng)用服務(wù)器來(lái)保持內(nèi)存可用空間在一個(gè)穩(wěn)定的水平?？刂艶ullGC頻率的關(guān)鍵是看應(yīng)用中絕大多數(shù)對(duì)象能否符合“朝生夕滅”的原則，即大多數(shù)對(duì)象的生存時(shí)間不應(yīng)太長(zhǎng)，尤其是不能有成批量的、長(zhǎng)生存時(shí)間的大對(duì)象產(chǎn)生，這樣才能保障老年代空間的穩(wěn)定。一、案例分析1-高性能硬件上的程序部署策略在大多數(shù)網(wǎng)站形式的應(yīng)用里，主要對(duì)象的生存周期都應(yīng)該是請(qǐng)求級(jí)或者頁(yè)面級(jí)的，會(huì)話級(jí)和全局級(jí)的長(zhǎng)生命對(duì)象相對(duì)很少。只要代碼寫得合理，應(yīng)當(dāng)都能實(shí)現(xiàn)在超大堆中正常使用而沒(méi)有FullGC，這樣的話，使用超大堆內(nèi)存時(shí)，網(wǎng)站響應(yīng)速度才會(huì)比較

6、有保證。除此之外，如果讀者計(jì)劃使用64位JDK來(lái)管理大內(nèi)存，還需要考慮下面可能面臨的問(wèn)題：內(nèi)存回收導(dǎo)致的長(zhǎng)時(shí)間停頓?，F(xiàn)階段，64位JDK的性能測(cè)試結(jié)果普遍低于32位JDK。需要保證程序足夠穩(wěn)定，因?yàn)檫@種應(yīng)用要是產(chǎn)生堆溢出幾乎就無(wú)法產(chǎn)生堆轉(zhuǎn)儲(chǔ)快照（因?yàn)橐a(chǎn)生十幾GB乃至更大的Dump文件），哪怕產(chǎn)生了快照也幾乎無(wú)法進(jìn)行分析。相同程序在64位JDK消耗的內(nèi)存一般比32位JDK大，這是由于指針膨脹，以及數(shù)據(jù)類型對(duì)齊補(bǔ)白等因素導(dǎo)致的。一、案例分析2-集群間同步導(dǎo)致的內(nèi)存溢出例如，有一個(gè)基于B/S的MIS

7、系統(tǒng)，硬件為兩臺(tái)2個(gè)CPU、8GB內(nèi)存的HP小型機(jī)，服務(wù)器是WebLogic9.2，每臺(tái)機(jī)器啟動(dòng)了3個(gè)WebLogic實(shí)例，構(gòu)成一個(gè)6個(gè)節(jié)點(diǎn)的親合式集群。由于是親合式集群，節(jié)點(diǎn)之間沒(méi)有進(jìn)行Session同步，但是有一些需求要實(shí)現(xiàn)部分?jǐn)?shù)據(jù)在各個(gè)節(jié)點(diǎn)間共享。開始這些數(shù)據(jù)存放在數(shù)據(jù)庫(kù)中，但由于讀寫頻繁競(jìng)爭(zhēng)很激烈，性能影響較大，后面使用JBossCache構(gòu)建了一個(gè)全局緩存。全局緩存啟用后，服務(wù)正常使用了一段較長(zhǎng)的時(shí)間，但最近卻不定期地出現(xiàn)了多次的內(nèi)存溢出問(wèn)題。一、案例分析2-集群間同步導(dǎo)致的內(nèi)存溢出在

8、內(nèi)存溢出異常不出現(xiàn)的時(shí)候，服務(wù)內(nèi)存回收狀況一直正常，每次內(nèi)存回收后都能恢復(fù)到一個(gè)穩(wěn)定的可用空間，開始懷疑是程序某些不常用的代碼路徑中存在內(nèi)存泄漏，但管理員反映最近程序并未更新、升級(jí)過(guò)，也沒(méi)有進(jìn)行什么特別操作。只好讓服務(wù)帶著-XX：+HeapDumpOnOutOfMemoryError參數(shù)運(yùn)行了一段時(shí)間。在最近一次溢出之后，管理員發(fā)回了heapdump文件，發(fā)現(xiàn)里面存在著大量org.jgroups.protocols.pbcast.NAKACK對(duì)象。JBossCache是基于自家的JGroups進(jìn)