【正文】 應(yīng)收集的信息1）minor gc的執(zhí)行頻率；full gc的執(zhí)行頻率，每次GC耗時多少？2）高峰期什么狀況？3）minor gc回收的效果如何？survivor的消耗狀況如何，每次有多少對象會進入老生代？4）full gc回收的效果如何？（簡單的memory leak判斷方法）5）系統(tǒng)的load、cpu消耗、qps or tps、響應(yīng)時間QPS每秒查詢率：是對一個特定的查詢服務(wù)器在規(guī)定時間內(nèi)所處理流量多少的衡量標準。在因特網(wǎng)上，作為域名服務(wù)器的機器性能經(jīng)常用每秒查詢率來衡量。對應(yīng)fetches/sec，即每秒的響應(yīng)請求數(shù)，也即是最大吞吐能力。TPS(Transaction Per Second)：每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量。嘗試調(diào)優(yōu)：注意Java RMI的定時GC觸發(fā)機制，可通過：XX:+DisableExplicitGC來禁止或通過 =3600000來控制觸發(fā)的時間。1）降低Full GC執(zhí)行頻率 – 通常瓶頸老生代本身占用的內(nèi)存空間就一直偏高，所以只要稍微放點對象到老生代，就full GC了；通常原因：系統(tǒng)緩存的東西太多；例如：使用oracle 10g驅(qū)動時preparedstatement cache太大；查找辦法：現(xiàn)執(zhí)行Dump然后再進行MAT分析；（1）Minor GC后總是有對象不斷的進入老生代，導(dǎo)致老生代不斷的滿通常原因：Survivor太小了系統(tǒng)表現(xiàn)：系統(tǒng)響應(yīng)太慢、請求量太大、每次請求分配的內(nèi)存太多、分配的對象太大...查找辦法：分析兩次minor GC之間到底哪些地方分配了內(nèi)存；利用jstat觀察Survivor的消耗狀況，XX:PrintHeapAtGC，輸出GC前后的詳細信息；對于系統(tǒng)響應(yīng)慢可以采用系統(tǒng)優(yōu)化，不是GC優(yōu)化的內(nèi)容；（2）老生代的內(nèi)存占用一直偏高調(diào)優(yōu)方法：① 擴大老生代的大?。p少新生代的大小或調(diào)大heap的 大?。?；減少new注意對minor gc的影響并且同時有可能造成full gc還是嚴重；調(diào)大heap注意full gc的時間的延長，cpu夠強悍嘛，os是32 bit的嗎？② 程序優(yōu)化（去掉一些不必要的緩存）（3）Minor GC后總是有對象不斷的進入老生代前提：這些進入老生代的對象在full GC時大部分都會被回收調(diào)優(yōu)方法：① 降低Minor GC的執(zhí)行頻率；② 讓對象盡量在Minor GC中就被回收掉：增大Eden區(qū)、增大survivor、增大TenuringThreshold；注意這些可能會造成minor gc執(zhí)行頻繁；③ 切換成CMS GC：老生代還沒有滿就回收掉，從而降低Full GC觸發(fā)的可能性；④ 程序優(yōu)化：提升響應(yīng)速度、降低每次請求分配的內(nèi)存、（4）降低單次Full GC的執(zhí)行時間通常原因：老生代太大了...調(diào)優(yōu)方法：1）是并行GC嗎？ 2）升級CPU 3）減小Heap或老生代（5）降低Minor GC執(zhí)行頻率通常原因：每次請求分配的內(nèi)存多、請求量大通常辦法：1）擴大heap、擴大新生代、擴大eden。注意點：降低每次請求分配的內(nèi)存；橫向增加機器的數(shù)量分擔(dān)請求的數(shù)量。（6）降低Minor GC執(zhí)行時間通常原因：新生代太大了，響應(yīng)速度太慢了，導(dǎo)致每次Minor GC時存活的對象多通常辦法：1）減小點新生代吧；2）增加CPU的數(shù)量、升級CPU的配置；加快系統(tǒng)的響應(yīng)速度細微調(diào)整：首先需要了解以下情況：① 當(dāng)響應(yīng)速度下降到多少或請求量上漲到多少時，系統(tǒng)會宕掉？② 參數(shù)調(diào)整后系統(tǒng)多久會執(zhí)行一次Minor GC，多久會執(zhí)行一次Full GC，高峰期會如何？需要計算的量：①每次請求平均需要分配多少內(nèi)存？系統(tǒng)的平均響應(yīng)時間是多少呢？請求量是多少、多常時間執(zhí)行一次Minor GC、Full GC？②現(xiàn)有參數(shù)下，應(yīng)該是多久一次Minor GC、Full GC，對比真實狀況，做一定的調(diào)整；必殺技：提升響應(yīng)速度、降低每次請求分配的內(nèi)存？系統(tǒng)調(diào)優(yōu)舉例 現(xiàn)象：系統(tǒng)響應(yīng)速度大概為100ms；當(dāng)系統(tǒng)QPS增長到40時，機器每隔5秒就執(zhí)行一次minor gc，每隔3分鐘就執(zhí)行一次full gc，并且很快就一直full GC了；每次Full gc后舊生代大概會消耗400M，有點多了。 解決方案：解決Full GC次數(shù)過多的問題 （1）降低響應(yīng)時間或請求次數(shù)，這個需要重構(gòu)，比較麻煩；——這個是終極方法，往往能夠順利的解決問題，因為大部分的問題均是由程序自身造成的。 （2）減少老生代內(nèi)存的消耗，比較靠譜；——可以通過分析Dump文件（jmap dump），并利用MAT查找內(nèi)存消耗的原因，從而發(fā)現(xiàn)程序中造成老生代內(nèi)存消耗的原因。 （3）減少每次請求的內(nèi)存的消耗，貌似比較靠譜；——這個是海市蜃樓，沒有太好的辦法。 （4）降低GC造成的應(yīng)用暫停的時間——可以采用CMS GS垃圾回收器。參數(shù)設(shè)置如下： Xms1536m Xmx1536m Xmn700m XX:SurvivorRatio=7 XX:+UseConcMarkSweepGC XX:+UseCMSCompactAtFullCollection XX:CMSMaxAbortablePrecleanTime=1000 XX:+CMSClassUnloadingEnabled XX:+UseCMSInitiatingOccupancyOnly XX:+DisableExplicitGC （5）減少每次minor gc晉升到old的對象?？蛇x方法：1） 調(diào)大新生代。2）調(diào)大Survivor。3）調(diào)大TenuringThreshold。 調(diào)大Survivor：當(dāng)前采用PS GC，Survivor space會被動態(tài)調(diào)整。由于調(diào)整幅度很小，導(dǎo)致了經(jīng)常有對象直接轉(zhuǎn)移到了老生代；于是禁止Survivor區(qū)的動態(tài)調(diào)整了，XX:UseAdaptiveSizePolicy，并計算Survivor Space需要的大小，于是繼續(xù)觀察，并做微調(diào)…。最終將Full GC推遲到2小時1次。垃圾回收的實現(xiàn)原理 內(nèi)存回收的實現(xiàn)方法：1）引用計數(shù)：不適合復(fù)雜對象的引用關(guān)系，尤其是循環(huán)依賴的場景。2）有向圖Tracing：適合于復(fù)雜對象的引用關(guān)系場景，Hotspot采用這種。常用算法：Copying、MarkSweep、MarkCompact。 Hotspot從root set開始掃描有引用的對象并對Reference類型的對象進行特殊處理。 以下是Root Set的列表：1）當(dāng)前正在執(zhí)行的線程；2）全局/靜態(tài)變量；3）JVM Handles；4）JNI 【 Java Native Interface 】Handles； 另外：minor GC只掃描新生代，當(dāng)老生代的對象引用了新生代的對象時，會采用如下的處理方式：在給對象賦引用時，會經(jīng)過一個write barrier的過程，以便檢查是否有老生代引用新生代對象的情況，如有則記錄到remember set中。并在minor gc時，remember set指向的新生代對象也作為root set。 新生代串行GC(Serial Copying)： 新生代串行GC(Serial Copying)完整內(nèi)存的分配策略： 1）首先在TLAB（本地線程分配緩沖區(qū)）上嘗試分配； 2）檢查是否需要在新生代上分配，如需要分配的大小小于PretenureSizeThreshold，則在eden區(qū)上進行分配，分配成功則返回；分配失敗則繼續(xù)； 3）檢查是否需要嘗試在老生代上分配，如需要，則遍歷所有代并檢查是否可在該代上分配，如可以則進行分配；如不需要在老生代上嘗試分配，則繼續(xù)； 4）根據(jù)策略決定執(zhí)行新生代GC或Full GC，執(zhí)行full gc時不清除soft Ref； 5）如需要分配的大小大于PretenureSizeThreshold，嘗試在老生代上分配，否則嘗試在新生代上分配； 6）嘗試擴大堆并分配； 7）執(zhí)行full gc，并清除所有soft Ref，按步驟5繼續(xù)嘗試分配。 新生代串行GC(Serial Copying)完整內(nèi)存回收策略 1）檢查to是否為空，不為空返回false； 2）檢查老生代剩余空間是否大于當(dāng)前eden+from已用的大小，如大于則返回true，如小于且HandlePromotionFailure為true，則檢查剩余空間是否大于之前每次minor gc晉級到老生代的平均大小，如大于返回true，如小于返回false。 3）如上面的結(jié)果為false，則執(zhí)行full gc；如上面的結(jié)果為true，執(zhí)行下面的步驟； 4）掃描引用關(guān)系，將活的對象copy到to space，如對象在minor gc中的存活次數(shù)超過tenuring_threshold或分配失敗，則往老生代復(fù)制，如仍然復(fù)制失敗，則取決于HandlePromotionFailure，如不需要處理，直接拋出OOM，并退出vm，如需處理，則保持這些新生代對象不動； 新生代可用GCPS 完整內(nèi)存分配策略 1）先在TLAB上分配，分配失敗則直接在eden上分配； 2）當(dāng)eden上分配失敗時，檢查需要分配的大小是否 = eden space的一半，如是，則直接在老生代分配； 3）如分配仍然失敗，且gc已超過頻率，則拋出OOM； 4）進入基本分配策略失敗的模式； 5）執(zhí)行PS GC，在eden上分配； 6）執(zhí)行非最大壓縮的full gc，在eden上分配； 7）在舊生代上分配； 8）執(zhí)行最大壓縮full gc，在eden上分配； 9）在舊生代上分配； 10）如還失敗，回到2。 最悲慘的情況，分配觸發(fā)多次PS GC和多次Full GC，直到OOM。 完整內(nèi)存回收策略 1）如gc所執(zhí)行的時間超過，直接結(jié)束； 2）先調(diào)用invoke_nopolicy 先檢查是不是要嘗試scavenge； to space必須為空，如不為空，則返回false； 獲取之前所有minor gc晉級到old的平均大小，并對比目前eden+from已使用的大小，取更小的一個值，如老生代剩余空間小于此值，則返回false，如大于則返回true； 如不需要嘗試scavenge，則返回false，否則繼續(xù)； 多線程掃描活的對象，并基亍copying算法回收，回收時相應(yīng)的晉升對象到舊生代； 如UseAdaptiveSizePolicy，那么重新計算to space和tenuringThreshold的值，并調(diào)整。 3）如invoke