本文主要是基于Sun JDK 1.6 Garbage Collector（作者：畢玄）的整理與總結(jié)，原文請(qǐng)讀者在網(wǎng)上搜索。

1、Java虛擬機(jī)運(yùn)行時(shí)的數(shù)據(jù)區(qū)

2、常用的內(nèi)存區(qū)域調(diào)節(jié)參數(shù)

-Xms：初始堆大小，默認(rèn)為物理內(nèi)存的1/64(<1GB)；默認(rèn)(MinHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存小于40%時(shí)，JVM就會(huì)增大堆直到-Xmx的最大限制

-Xmx：最大堆大小，默認(rèn)(MaxHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存大于70%時(shí)，JVM會(huì)減少堆直到 -Xms的最小限制

-Xmn：新生代的內(nèi)存空間大小，注意：此處的大小是（eden+ 2 survivor space)。與jmap -heap中顯示的New gen是不同的。整個(gè)堆大小=新生代大小 + 老生代大小 + 永久代大小。
在保證堆大小不變的情況下，增大新生代后,將會(huì)減小老生代大小。此值對(duì)系統(tǒng)性能影響較大,Sun官方推薦配置為整個(gè)堆的3/8。

-XX:SurvivorRatio：新生代中Eden區(qū)域與Survivor區(qū)域的容量比值，默認(rèn)值為8。兩個(gè)Survivor區(qū)與一個(gè)Eden區(qū)的比值為2:8,一個(gè)Survivor區(qū)占整個(gè)年輕代的1/10。

-Xss：每個(gè)線程的堆棧大小。JDK5.0以后每個(gè)線程堆棧大小為1M,以前每個(gè)線程堆棧大小為256K。應(yīng)根據(jù)應(yīng)用的線程所需內(nèi)存大小進(jìn)行適當(dāng)調(diào)整。在相同物理內(nèi)存下,減小這個(gè)值能生成更多的線程。但是操作系統(tǒng)對(duì)一個(gè)進(jìn)程內(nèi)的線程數(shù)還是有限制的，不能無限生成，經(jīng)驗(yàn)值在3000~5000左右。一般小的應(yīng)用， 如果棧不是很深， 應(yīng)該是128k夠用的，大的應(yīng)用建議使用256k。這個(gè)選項(xiàng)對(duì)性能影響比較大，需要嚴(yán)格的測(cè)試。和threadstacksize選項(xiàng)解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"-Xss is translated in a VM flag named ThreadStackSize”一般設(shè)置這個(gè)值就可以了。

-XX:PermSize：設(shè)置永久代(perm gen)初始值。默認(rèn)值為物理內(nèi)存的1/64。

-XX:MaxPermSize：設(shè)置持久代最大值。物理內(nèi)存的1/4。

3、內(nèi)存分配方法

1）堆上分配   2）棧上分配  3）堆外分配（DirectByteBuffer或直接使用Unsafe.allocateMemory,但不推薦這種方式）

4、監(jiān)控方法

1）系統(tǒng)程序運(yùn)行時(shí)可通過jstat –gcutil來查看堆中各個(gè)內(nèi)存區(qū)域的變化以及GC的工作狀態(tài)；
2）啟動(dòng)時(shí)可添加-XX:+PrintGCDetails  –Xloggc:<file>輸出到日志文件來查看GC的狀況；
3）jmap –heap可用于查看各個(gè)內(nèi)存空間的大??；

5）斷代法可用GC匯總

一、新生代可用GC

1）串行GC(Serial Copying)：client模式下默認(rèn)GC方式，也可通過-XX:+UseSerialGC來強(qiáng)制指定；默認(rèn)情況下 eden、s0、s1的大小通過-XX:SurvivorRatio來控制，默認(rèn)為8，含義
為eden:s0的比例，啟動(dòng)后可通過jmap –heap [pid]來查看。

      默認(rèn)情況下，僅在TLAB或eden上分配，只有兩種情況下會(huì)在老生代分配：
      1、需要分配的內(nèi)存大小超過eden space大??；
      2、在配置了PretenureSizeThreshold的情況下，對(duì)象大小大于此值。

      默認(rèn)情況下，觸發(fā)Minor GC時(shí)：
      之前Minor GC晉級(jí)到old的平均大小 < 老生代的剩余空間 < eden+from Survivor的使用空間。當(dāng)HandlePromotionFailure為true，則僅觸發(fā)minor gc；如為false，則觸發(fā)full GC。

      默認(rèn)情況下，新生代對(duì)象晉升到老生代的規(guī)則：

     1、經(jīng)歷多次minor gc仍存活的對(duì)象，可通過以下參數(shù)來控制：以MaxTenuringThreshold值為準(zhǔn)，默認(rèn)為15。
     2、to space放不下的，直接放入老生代；

2）并行GC（ParNew）：CMS GC時(shí)默認(rèn)采用，也可采用-XX:+UseParNewGC強(qiáng)制指定；垃圾回收的時(shí)候采用多線程的方式。

3）并行回收GC(Parallel Scavenge)：server模式下默認(rèn)的GC方式，也可采用-XX:+UseParallelGC強(qiáng)制指定；eden、s0、s1的大小可通過-XX:SurvivorRatio來控制，但默認(rèn)情況下
以-XX:InitialSurivivorRatio為準(zhǔn)，此值默認(rèn)為8，代表的為新生代大小 : s0，這點(diǎn)要特別注意。

      默認(rèn)情況下，當(dāng)TLAB、eden上分配都失敗時(shí)，判斷需要分配的內(nèi)存大小是否 >= eden space的一半大小，如是就直接在老生代上分配；

      默認(rèn)情況下的垃圾回收規(guī)則：

      1、在回收前PS GC會(huì)先檢測(cè)之前每次PS GC時(shí)，晉升到老生代的平均大小是否大于老生代的剩余空間，如大于則直接觸發(fā)full GC；
      2、在回收后，也會(huì)按照上面的規(guī)則進(jìn)行檢測(cè)。

      默認(rèn)情況下的新生代對(duì)象晉升到老生代的規(guī)則：
     1、經(jīng)歷多次minor gc仍存活的對(duì)象，可通過以下參數(shù)來控制：AlwaysTenure，默認(rèn)false，表示只要minor GC時(shí)存活，就晉升到老生代；NeverTenure，默認(rèn)false，表示永不晉升到老生代；上面兩個(gè)都沒設(shè)置的情冴下，如UseAdaptiveSizePolicy，啟動(dòng)時(shí)以InitialTenuringThreshold值作為存活次數(shù)的閾值，在每次ps gc后會(huì)動(dòng)態(tài)調(diào)整，如不使用UseAdaptiveSizePolicy，則以MaxTenuringThreshold為準(zhǔn)。
     2、to space放不下的，直接放入老生代。

     在回收后，如UseAdaptiveSizePolicy，PS GC會(huì)根據(jù)運(yùn)行狀態(tài)動(dòng)態(tài)調(diào)整eden、to以及TenuringThreshold的大小。如果不希望動(dòng)態(tài)調(diào)整可設(shè)置-XX:-UseAdaptiveSizePolicy。如希望跟蹤每次的變化情況，可在啟勱參數(shù)上增加： PrintAdaptiveSizePolicy。

二、老生代可用GC

1、串行GC(Serial Copying)：client方式下默認(rèn)GC方式，可通過-XX:+UseSerialGC強(qiáng)制指定。

    觸發(fā)機(jī)制匯總：
   1）old gen空間不足；
   2）perm gen空間不足；
   3）minor gc時(shí)的悲觀策略；
   4）minor GC后在eden上分配內(nèi)存仍然失??；
   5）執(zhí)行heap dump時(shí)；
   6）外部調(diào)用System.gc，可通過-XX:+DisableExplicitGC來禁止。

2、并行回收GC(Parallel Scavenge)： server模式下默認(rèn)GC方式，可通過-XX:+UseParallelGC強(qiáng)制指定； 并行的線程數(shù)為當(dāng)cpu core<=8 ? cpu core : 3+(cpu core*5)/8或通過-XX:ParallelGCThreads=x來強(qiáng)制指定。如ScavengeBeforeFullGC為true（默認(rèn)值），則先執(zhí)行minor GC。

3、并行Compacting：可通過-XX:+UseParallelOldGC強(qiáng)制指定。

4、并發(fā)CMS：可通過-XX:+UseConcMarkSweepGC來強(qiáng)制指定。并發(fā)的線程數(shù)默認(rèn)為:( 并行GC線程數(shù)+3)/4，也可通過ParallelCMSThreads指定。

    觸發(fā)機(jī)制：
    1、當(dāng)老生代空間的使用到達(dá)一定比率時(shí)觸發(fā)；

     Hotspot V 1.6中默認(rèn)為65%，可通過PrintCMSInitiationStatistics（此參數(shù)在V 1.5中不能用）來查看這個(gè)值到底是多少；可通過CMSInitiatingOccupancyFraction來強(qiáng)制指定，默認(rèn)值并不是賦值在了這個(gè)值上，是根據(jù)如下公式計(jì)算出來的： ((100 - MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; 其中,MinHeapFreeRatio默認(rèn)值： 40   CMSTriggerRatio默認(rèn)值： 80。

     2、當(dāng)perm gen采用CMS收集且空間使用到一定比率時(shí)觸發(fā)；

     perm gen采用CMS收集需設(shè)置：-XX:+CMSClassUnloadingEnabled   Hotspot V 1.6中默認(rèn)為65%；可通過CMSInitiatingPermOccupancyFraction來強(qiáng)制指定，同樣，它是根據(jù)如下公式計(jì)算出來的：((100 - MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; 其中，MinHeapFreeRatio默認(rèn)值： 40    CMSTriggerPermRatio默認(rèn)值： 80。

      3、Hotspot根據(jù)成本計(jì)算決定是否需要執(zhí)行CMS GC；可通過-XX:+UseCMSInitiatingOccupancyOnly來去掉這個(gè)動(dòng)態(tài)執(zhí)行的策略。
      4、外部調(diào)用了System.gc，且設(shè)置了ExplicitGCInvokesConcurrent；需要注意，在hotspot 6中，在這種情況下如應(yīng)用同時(shí)使用了NIO，可能會(huì)出現(xiàn)bug。

6、GC組合

1）默認(rèn)GC組合

2）可選的GC組合

7、GC監(jiān)測(cè)

1）jstat –gcutil [pid] [intervel] [count]
2）-verbose:gc // 可以輔助輸出一些詳細(xì)的GC信息；-XX:+PrintGCDetails // 輸出GC詳細(xì)信息；-XX:+PrintGCApplicationStoppedTime // 輸出GC造成應(yīng)用暫停的時(shí)間
-XX:+PrintGCDateStamps // GC發(fā)生的時(shí)間信息；-XX:+PrintHeapAtGC // 在GC前后輸出堆中各個(gè)區(qū)域的大?。?Xloggc:[file] // 將GC信息輸出到單獨(dú)的文件中，建議都加上，這個(gè)消耗不大，而且對(duì)查問題和調(diào)優(yōu)有很大的幫助。gc的日志拿下來后可使用GCLogViewer或gchisto進(jìn)行分析。
3）圖形化的情況下可直接用jvisualvm進(jìn)行分析。

4）查看內(nèi)存的消耗狀況

      （1）長期消耗，可以直接dump，然后MAT(內(nèi)存分析工具)查看即可

      （2）短期消耗，圖形界面情況下，可使用jvisualvm的memory profiler或jprofiler。

8、系統(tǒng)調(diào)優(yōu)方法

步驟：1、評(píng)估現(xiàn)狀 2、設(shè)定目標(biāo) 3、嘗試調(diào)優(yōu) 4、衡量調(diào)優(yōu) 5、細(xì)微調(diào)整

設(shè)定目標(biāo)：

1）降低Full GC的執(zhí)行頻率？
2）降低Full GC的消耗時(shí)間？
3）降低Full GC所造成的應(yīng)用停頓時(shí)間？
4）降低Minor GC執(zhí)行頻率？
5）降低Minor GC消耗時(shí)間？
例如某系統(tǒng)的GC調(diào)優(yōu)目標(biāo)：降低Full GC執(zhí)行頻率的同時(shí)，盡可能降低minor GC的執(zhí)行頻率、消耗時(shí)間以及GC對(duì)應(yīng)用造成的停頓時(shí)間。

衡量調(diào)優(yōu)：

1、衡量工具
1）打印GC日志信息：-XX:+PrintGCDetails –XX:+PrintGCApplicationStoppedTime -Xloggc: {文件名}  -XX:+PrintGCTimeStamps
2）jmap：（由于每個(gè)版本jvm的默認(rèn)值可能會(huì)有改變，建議還是用jmap首先觀察下目前每個(gè)代的內(nèi)存大小、GC方式） ?
3）運(yùn)行狀況監(jiān)測(cè)工具：jstat、jvisualvm、sar 、gclogviewer

2、應(yīng)收集的信息
1）minor gc的執(zhí)行頻率；full gc的執(zhí)行頻率，每次GC耗時(shí)多少？
2）高峰期什么狀況？
3）minor gc回收的效果如何？survivor的消耗狀況如何，每次有多少對(duì)象會(huì)進(jìn)入老生代？
4）full gc回收的效果如何？（簡單的memory leak判斷方法）
5）系統(tǒng)的load、cpu消耗、qps or tps、響應(yīng)時(shí)間

QPS每秒查詢率：是對(duì)一個(gè)特定的查詢服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)。在因特網(wǎng)上，作為域名服務(wù)器的機(jī)器性能經(jīng)常用每秒查詢率來衡量。對(duì)應(yīng)fetches/sec，即每秒的響應(yīng)請(qǐng)求數(shù)，也即是最大吞吐能力。
TPS(Transaction Per Second)：每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量。

嘗試調(diào)優(yōu)：

注意Java RMI的定時(shí)GC觸發(fā)機(jī)制，可通過：-XX:+DisableExplicitGC來禁止或通過 -Dsun.rmi.dgc.server.gcInterval=3600000來控制觸發(fā)的時(shí)間。

1）降低Full GC執(zhí)行頻率 – 通常瓶頸
老生代本身占用的內(nèi)存空間就一直偏高，所以只要稍微放點(diǎn)對(duì)象到老生代，就full GC了；
通常原因：系統(tǒng)緩存的東西太多；
例如：使用oracle 10g驅(qū)動(dòng)時(shí)preparedstatement cache太大；
查找辦法：現(xiàn)執(zhí)行Dump然后再進(jìn)行MAT分析；

（1）Minor GC后總是有對(duì)象不斷的進(jìn)入老生代，導(dǎo)致老生代不斷的滿
通常原因：Survivor太小了
系統(tǒng)表現(xiàn)：系統(tǒng)響應(yīng)太慢、請(qǐng)求量太大、每次請(qǐng)求分配的內(nèi)存太多、分配的對(duì)象太大...
查找辦法：分析兩次minor GC之間到底哪些地方分配了內(nèi)存；
利用jstat觀察Survivor的消耗狀況，-XX:PrintHeapAtGC，輸出GC前后的詳細(xì)信息；
對(duì)于系統(tǒng)響應(yīng)慢可以采用系統(tǒng)優(yōu)化，不是GC優(yōu)化的內(nèi)容；

（2）老生代的內(nèi)存占用一直偏高
調(diào)優(yōu)方法：① 擴(kuò)大老生代的大?。p少新生代的大小或調(diào)大heap的 大?。?br>減少new注意對(duì)minor gc的影響并且同時(shí)有可能造成full gc還是嚴(yán)重；
調(diào)大heap注意full gc的時(shí)間的延長，cpu夠強(qiáng)悍嘛，os是32 bit的嗎？
② 程序優(yōu)化（去掉一些不必要的緩存）

（3）Minor GC后總是有對(duì)象不斷的進(jìn)入老生代
前提：這些進(jìn)入老生代的對(duì)象在full GC時(shí)大部分都會(huì)被回收
調(diào)優(yōu)方法：
① 降低Minor GC的執(zhí)行頻率；
② 讓對(duì)象盡量在Minor GC中就被回收掉：增大Eden區(qū)、增大survivor、增大TenuringThreshold；注意這些可能會(huì)造成minor gc執(zhí)行頻繁；
③ 切換成CMS GC：老生代還沒有滿就回收掉，從而降低Full GC觸發(fā)的可能性；
④ 程序優(yōu)化：提升響應(yīng)速度、降低每次請(qǐng)求分配的內(nèi)存、

（4）降低單次Full GC的執(zhí)行時(shí)間
通常原因：老生代太大了...
調(diào)優(yōu)方法：1）是并行GC嗎？   2）升級(jí)CPU  3）減小Heap或老生代

（5）降低Minor GC執(zhí)行頻率
通常原因：每次請(qǐng)求分配的內(nèi)存多、請(qǐng)求量大
通常辦法：1）擴(kuò)大heap、擴(kuò)大新生代、擴(kuò)大eden。注意點(diǎn)：降低每次請(qǐng)求分配的內(nèi)存；橫向增加機(jī)器的數(shù)量分擔(dān)請(qǐng)求的數(shù)量。

（6）降低Minor GC執(zhí)行時(shí)間
通常原因：新生代太大了，響應(yīng)速度太慢了，導(dǎo)致每次Minor GC時(shí)存活的對(duì)象多
通常辦法：1）減小點(diǎn)新生代吧；2）增加CPU的數(shù)量、升級(jí)CPU的配置；加快系統(tǒng)的響應(yīng)速度

細(xì)微調(diào)整：

首先需要了解以下情況：

① 當(dāng)響應(yīng)速度下降到多少或請(qǐng)求量上漲到多少時(shí)，系統(tǒng)會(huì)宕掉？

② 參數(shù)調(diào)整后系統(tǒng)多久會(huì)執(zhí)行一次Minor GC，多久會(huì)執(zhí)行一次Full GC，高峰期會(huì)如何？

需要計(jì)算的量：

①每次請(qǐng)求平均需要分配多少內(nèi)存？系統(tǒng)的平均響應(yīng)時(shí)間是多少呢？請(qǐng)求量是多少、多常時(shí)間執(zhí)行一次Minor GC、Full GC？

②現(xiàn)有參數(shù)下，應(yīng)該是多久一次Minor GC、Full GC，對(duì)比真實(shí)狀況，做一定的調(diào)整；

必殺技：提升響應(yīng)速度、降低每次請(qǐng)求分配的內(nèi)存？

9、系統(tǒng)調(diào)優(yōu)舉例

     現(xiàn)象：1、系統(tǒng)響應(yīng)速度大概為100ms；2、當(dāng)系統(tǒng)QPS增長到40時(shí)，機(jī)器每隔5秒就執(zhí)行一次minor gc，每隔3分鐘就執(zhí)行一次full gc，并且很快就一直full GC了；4、每次Full gc后舊生代大概會(huì)消耗400M，有點(diǎn)多了。

     解決方案：解決Full GC次數(shù)過多的問題

    （1）降低響應(yīng)時(shí)間或請(qǐng)求次數(shù)，這個(gè)需要重構(gòu)，比較麻煩；——這個(gè)是終極方法，往往能夠順利的解決問題，因?yàn)榇蟛糠值膯栴}均是由程序自身造成的。

    （2）減少老生代內(nèi)存的消耗，比較靠譜；——可以通過分析Dump文件（jmap dump），并利用MAT查找內(nèi)存消耗的原因，從而發(fā)現(xiàn)程序中造成老生代內(nèi)存消耗的原因。

    （3）減少每次請(qǐng)求的內(nèi)存的消耗，貌似比較靠譜；——這個(gè)是海市蜃樓，沒有太好的辦法。

    （4）降低GC造成的應(yīng)用暫停的時(shí)間——可以采用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的對(duì)象。可選方法：1） 調(diào)大新生代。2）調(diào)大Survivor。3）調(diào)大TenuringThreshold。

      調(diào)大Survivor：當(dāng)前采用PS GC，Survivor space會(huì)被動(dòng)態(tài)調(diào)整。由于調(diào)整幅度很小，導(dǎo)致了經(jīng)常有對(duì)象直接轉(zhuǎn)移到了老生代；于是禁止Survivor區(qū)的動(dòng)態(tài)調(diào)整了，-XX:-UseAdaptiveSizePolicy，并計(jì)算Survivor Space需要的大小，于是繼續(xù)觀察，并做微調(diào)…。最終將Full GC推遲到2小時(shí)1次。

10、垃圾回收的實(shí)現(xiàn)原理

      內(nèi)存回收的實(shí)現(xiàn)方法：1）引用計(jì)數(shù)：不適合復(fù)雜對(duì)象的引用關(guān)系，尤其是循環(huán)依賴的場景。2）有向圖Tracing：適合于復(fù)雜對(duì)象的引用關(guān)系場景，Hotspot采用這種。常用算法：Copying、Mark-Sweep、Mark-Compact。

      Hotspot從root set開始掃描有引用的對(duì)象并對(duì)Reference類型的對(duì)象進(jìn)行特殊處理。
      以下是Root Set的列表：1）當(dāng)前正在執(zhí)行的線程；2）全局/靜態(tài)變量；3）JVM Handles；4）JNI 【 Java Native Interface 】Handles；

      另外：minor GC只掃描新生代，當(dāng)老生代的對(duì)象引用了新生代的對(duì)象時(shí)，會(huì)采用如下的處理方式：在給對(duì)象賦引用時(shí)，會(huì)經(jīng)過一個(gè)write barrier的過程，以便檢查是否有老生代引用新生代對(duì)象的情況，如有則記錄到remember set中。并在minor gc時(shí)，remember set指向的新生代對(duì)象也作為root set。

     新生代串行GC(Serial Copying)：

     新生代串行GC(Serial Copying)完整內(nèi)存的分配策略：

     1）首先在TLAB（本地線程分配緩沖區(qū)）上嘗試分配；
     2）檢查是否需要在新生代上分配，如需要分配的大小小于PretenureSizeThreshold，則在eden區(qū)上進(jìn)行分配，分配成功則返回；分配失敗則繼續(xù)；
     3）檢查是否需要嘗試在老生代上分配，如需要，則遍歷所有代并檢查是否可在該代上分配，如可以則進(jìn)行分配；如不需要在老生代上嘗試分配，則繼續(xù)；
     4）根據(jù)策略決定執(zhí)行新生代GC或Full GC，執(zhí)行full gc時(shí)不清除soft Ref；
     5）如需要分配的大小大于PretenureSizeThreshold，嘗試在老生代上分配，否則嘗試在新生代上分配；
     6）嘗試擴(kuò)大堆并分配；
     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晉級(jí)到老生代的平均大小，如大于返回true，如小于返回false。
     3）如上面的結(jié)果為false，則執(zhí)行full gc；如上面的結(jié)果為true，執(zhí)行下面的步驟；
     4）掃描引用關(guān)系，將活的對(duì)象copy到to space，如對(duì)象在minor gc中的存活次數(shù)超過tenuring_threshold或分配失敗，則往老生代復(fù)制，如仍然復(fù)制失敗，則取決于HandlePromotionFailure，如不需要處理，直接拋出OOM，并退出vm，如需處理，則保持這些新生代對(duì)象不動(dòng)；

    新生代可用GC-PS

    完整內(nèi)存分配策略
    1）先在TLAB上分配，分配失敗則直接在eden上分配；
    2）當(dāng)eden上分配失敗時(shí)，檢查需要分配的大小是否 >= eden space的一半，如是，則直接在老生代分配；
    3）如分配仍然失敗，且gc已超過頻率，則拋出OOM；
    4）進(jìn)入基本分配策略失敗的模式；
    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í)行的時(shí)間超過，直接結(jié)束；
   2）先調(diào)用invoke_nopolicy
       2.1 先檢查是不是要嘗試scavenge；
       2.1.1 to space必須為空，如不為空，則返回false；
       2.1.2 獲取之前所有minor gc晉級(jí)到old的平均大小，并對(duì)比目前eden+from已使用的大小，取更小的一個(gè)值，如老生代剩余空間小于此值，則返回false，如大于則返回true；
       2.2 如不需要嘗試scavenge，則返回false，否則繼續(xù)；
       2.3 多線程掃描活的對(duì)象，并基亍copying算法回收，回收時(shí)相應(yīng)的晉升對(duì)象到舊生代；
       2.4 如UseAdaptiveSizePolicy，那么重新計(jì)算to space和tenuringThreshold的值，并調(diào)整。
   3）如invoke_nopolicy返回的是false，或之前所有minor gc晉級(jí)到老生代的平均大小 > 舊生代的剩余空間，那么繼續(xù)下面的步驟，否則結(jié)束；
   4）如UseParallelOldGC，則執(zhí)行PSParallelCompact，如不是UseParallelOldGC，則執(zhí)行PSMarkSweep。

    老生代并行CMS GC：

    優(yōu)缺點(diǎn)：

    1） 大部分時(shí)候和應(yīng)用并發(fā)進(jìn)行，因此只會(huì)造成很短的暫停時(shí)間；
    2）浮動(dòng)垃圾，沒辦法，所以內(nèi)存空間要稍微大一點(diǎn)；
    3）內(nèi)存碎片，-XX:+UseCMSCompactAtFullCollection 來解決；
    4） 爭搶CPU，這GC方式就這樣；
    5）多次remark，所以總的gc時(shí)間會(huì)比并行的長；
    6）內(nèi)存分配，free list方式，so性能稍差，對(duì)minor GC會(huì)有一點(diǎn)影響；
    7）和應(yīng)用并發(fā)，有可能分配和回收同時(shí)，產(chǎn)生競爭，引入了鎖，JVM分配優(yōu)先。

11、TLAB的解釋

     堆內(nèi)的對(duì)象數(shù)據(jù)是各個(gè)線程所共享的，所以當(dāng)在堆內(nèi)創(chuàng)建新的對(duì)象時(shí)，就需要進(jìn)行鎖操作。鎖操作是比較耗時(shí)，因此JVM為每個(gè)線在堆上分配了一塊“自留地”——TLAB(全稱是Thread Local Allocation Buffer)，位于堆內(nèi)存的新生代，也就是Eden區(qū)。每個(gè)線程在創(chuàng)建新的對(duì)象時(shí)，會(huì)首先嘗試在自己的TLAB里進(jìn)行分配，如果成功就返回，失敗了再到共享的Eden區(qū)里去申請(qǐng)空間。在線程自己的TLAB區(qū)域創(chuàng)建對(duì)象失敗一般有兩個(gè)原因：一是對(duì)象太大，二是自己的TLAB區(qū)剩余空間不夠。通常默認(rèn)的TLAB區(qū)域大小是Eden區(qū)域的1%，當(dāng)然也可以手工進(jìn)行調(diào)整，對(duì)應(yīng)的JVM參數(shù)是-XX:TLABWasteTargetPercent。

參考文獻(xiàn)：

1、Sun JDK 1.6 GC（Garbage Collector）  作者：畢玄

一、項(xiàng)目管理方面

1、業(yè)主、總集成商、監(jiān)理單位、承建單位、產(chǎn)品供貨單位的溝通協(xié)調(diào)問題。首先，在與業(yè)主的溝通方面，最初較為混亂，主要原因是沒有形成統(tǒng)一的溝通結(jié)構(gòu)與機(jī)制，在最初的近三個(gè)月的時(shí)間里導(dǎo)致項(xiàng)目推進(jìn)速度非常緩慢。經(jīng)與業(yè)主單位溝通，制定了工程的溝通方案，建立了溝通組織結(jié)構(gòu)。主要內(nèi)容是在業(yè)主單位方面建立了項(xiàng)目實(shí)施辦，項(xiàng)目實(shí)施辦對(duì)部領(lǐng)導(dǎo)組成的項(xiàng)目辦負(fù)責(zé)，明確了項(xiàng)目辦與實(shí)施辦的責(zé)任，由實(shí)施辦協(xié)調(diào)信息中心各處室共同推進(jìn)項(xiàng)目工作；并且在信息中心內(nèi)部推行“承諾書”也就是各處室均對(duì)工程的建設(shè)內(nèi)容進(jìn)行承諾并與績效掛鉤。其次，總集成商、總監(jiān)理商與實(shí)施辦溝通，實(shí)施辦與相關(guān)處室溝通，承建商與產(chǎn)品供貨單位在技術(shù)上接受總集成商的指導(dǎo)與約束；在流程的規(guī)范性上接受總監(jiān)理商的指導(dǎo)與約束；在業(yè)務(wù)上接受信息中心負(fù)責(zé)處室的約束。由此，通過溝通方案建立與推行，項(xiàng)目的溝通協(xié)調(diào)方面才進(jìn)入了正軌，項(xiàng)目的推進(jìn)速度明顯加快。

2、用戶單位對(duì)項(xiàng)目的支持度等方面的問題。某些用戶單位對(duì)所建設(shè)的項(xiàng)目并沒有強(qiáng)烈的需求，持可有可無或最好沒有的態(tài)度，但在工程的初設(shè)中這些項(xiàng)目又是必須建設(shè)的內(nèi)容。因此，在項(xiàng)目的實(shí)施的過程中，這寫用戶單位對(duì)項(xiàng)目的各項(xiàng)工作均持消極態(tài)度，使得項(xiàng)目無法正常推進(jìn)。例如，有些用戶單位不組織本單位人員配合需求調(diào)研，不組織下屬各省級(jí)單位進(jìn)行系統(tǒng)試運(yùn)行，不組織本單位人員進(jìn)行用戶測(cè)試等。對(duì)于這些問題往往系統(tǒng)承建商方面已無法推動(dòng)，需要通過實(shí)施辦與項(xiàng)目辦層面與用戶單位溝通協(xié)商一致后才能繼續(xù)開展工作。

3、部本級(jí)項(xiàng)目與省級(jí)項(xiàng)目的協(xié)調(diào)推進(jìn)問題。由于在工程的可研中包含各省的項(xiàng)目建設(shè)，各省建設(shè)的進(jìn)度對(duì)整體項(xiàng)目的最終驗(yàn)收具有制約作用。目前，各省的建設(shè)情況各不一致，有的已經(jīng)完成，有的正在建設(shè)過程中，有的資金尚未批復(fù)。。。

二、技術(shù)架構(gòu)方面

1、應(yīng)用系統(tǒng)部署架構(gòu)問題。在09年底的時(shí)候，在應(yīng)用系統(tǒng)部署架構(gòu)出現(xiàn)了一個(gè)“互聯(lián)網(wǎng)區(qū)應(yīng)用系統(tǒng)訪問Oracle RAC數(shù)據(jù)庫時(shí)斷時(shí)續(xù)問題”，此問題先后持續(xù)了4到5個(gè)月，制約了項(xiàng)目的建設(shè)進(jìn)度（期間采用了其他方式，盡量減少了損失）。原因1，在進(jìn)行整體應(yīng)用系統(tǒng)部署架構(gòu)設(shè)計(jì)時(shí)，尚未進(jìn)行相應(yīng)產(chǎn)品的招標(biāo)，因此無法明確具體的產(chǎn)品（各產(chǎn)品在具體的實(shí)現(xiàn)層面有差別，這些差別可能影響部署架構(gòu)的實(shí)現(xiàn)）。原因2，各廠商均具有專業(yè)領(lǐng)域的知識(shí)背景，但對(duì)各知識(shí)領(lǐng)域之間的把握較少，因此很可能在邊緣領(lǐng)域出現(xiàn)問題。原因3，由于本項(xiàng)目為大型的電子政務(wù)項(xiàng)目，涉及的專業(yè)知識(shí)領(lǐng)域和技術(shù)手段非常繁雜，在設(shè)計(jì)與測(cè)試過程中非常困難。在實(shí)施辦與總集的總體協(xié)調(diào)下，經(jīng)過多次的評(píng)審與大量的測(cè)試，對(duì)應(yīng)用系統(tǒng)部署架構(gòu)進(jìn)行了調(diào)整，使問題成功解決。此類問題的解決方法是由總集成商牽頭，召集相關(guān)的承建單位，如網(wǎng)絡(luò)集成商、安全集成商、數(shù)據(jù)庫提供商。。。共同討論分析，制定問題的排查方案，并按照方案查找問題的原因。待問題的原因查找清楚后，再由總集成商召集相關(guān)承建商共同討論提出解決方法，經(jīng)實(shí)施辦審核通過（如重大技術(shù)問題可由實(shí)施辦召集專家進(jìn)行評(píng)審確定）。

2、部分系統(tǒng)試運(yùn)行階段性能低下與生產(chǎn)環(huán)境問題排查困難等。一方面，工程所用到的技術(shù)非常復(fù)雜，采用了大量的設(shè)備，如 Oralce RAC集群，存儲(chǔ)，IBM小型機(jī)、負(fù)載均衡集群等，此種環(huán)境很難有一個(gè)企業(yè)（如承建單位或第三方測(cè)試單位）復(fù)制。因此，無論是承建單位還是第三方測(cè)試單位所進(jìn)行的測(cè)試均無法完全反映生產(chǎn)環(huán)境下的性能指標(biāo)。另一方面，此種生產(chǎn)環(huán)境也是初次搭建，其技術(shù)可行性只停留在理論層面，期間的技術(shù)細(xì)節(jié)無法完全在設(shè)計(jì)階段考慮到，只能通過一段時(shí)間的系統(tǒng)試運(yùn)行才能夠暴露與完善。當(dāng)然，如果能夠在系統(tǒng)進(jìn)行初步設(shè)計(jì)時(shí)，能夠考慮搭建一套與生產(chǎn)環(huán)境完全或基本一致的測(cè)試環(huán)境，此問題將能夠很方便的進(jìn)行解決，也就是可以在測(cè)試環(huán)境中進(jìn)行應(yīng)用系統(tǒng)的壓力測(cè)試與問題排查，待系統(tǒng)穩(wěn)定后并滿足用戶要求時(shí)，再將系統(tǒng)遷移至正式的生產(chǎn)環(huán)境中，這種方式可以最大程度的保持生產(chǎn)環(huán)境的穩(wěn)定性。

        以下內(nèi)容結(jié)合了其他網(wǎng)友發(fā)表的內(nèi)容，首先再次表示感謝。

        假設(shè)一個(gè)系統(tǒng)有2000個(gè)使用者（對(duì)于一般的企業(yè)系統(tǒng)，這個(gè)概念比較簡單，就是指數(shù)據(jù)庫中的用戶總數(shù)，但對(duì)于網(wǎng)站型的系統(tǒng)而言，相對(duì)較為復(fù)雜，一般為注冊(cè)用戶和游客的總和），也就是說，該系統(tǒng)的用戶總數(shù)是2000名，這個(gè)概念表示的是“系統(tǒng)用戶數(shù)”。如果該系統(tǒng)具有“ 在線統(tǒng)計(jì)”功能，該功能一般用于記錄系統(tǒng)中所有已經(jīng)登錄的用戶（當(dāng)然如果有一些系統(tǒng)功能同時(shí)也提供給未登錄的用戶使用，那么未登錄的當(dāng)前使用者也應(yīng)記錄進(jìn)來），如果根據(jù)此統(tǒng)計(jì)結(jié)果得到最高峰時(shí)有500人在線，那么這個(gè)500就是所說的“同時(shí)在線用戶數(shù)”。
    根據(jù)對(duì)業(yè)務(wù)并發(fā)用戶數(shù)的定義，這500就是整個(gè)系統(tǒng)使用時(shí)最大的業(yè)務(wù)并發(fā)用戶數(shù)。當(dāng)然，500這個(gè)數(shù)值只是表明在最高峰時(shí)刻有500個(gè)用戶登錄了系統(tǒng)，并不表示實(shí)際服務(wù)器承受的壓力。因?yàn)榉?wù)器承受的壓力還與具體的用戶訪問模式相關(guān)。例如，考察具體的某一個(gè)時(shí)間點(diǎn)，在這500個(gè)“同時(shí)在線用戶數(shù)”中，其中40%的用戶在較有興致地看系統(tǒng)公告（注意：“看”這個(gè)動(dòng)作是不會(huì)對(duì)服務(wù)端產(chǎn)生任何負(fù)擔(dān)的），20%的用戶在填寫復(fù)雜的表格（對(duì)用戶填寫的表格來說，只有在“提交”的時(shí)刻才會(huì)向服務(wù)端發(fā)送請(qǐng)求，填寫過程是不對(duì)服務(wù)端構(gòu)成壓力的），20%部分用戶在發(fā)呆（也就是什么也沒有做），剩下的 20%用戶在不停地從一個(gè)頁面跳轉(zhuǎn)到另一個(gè)頁面——在這種場景下，可以說，只有20%的用戶真正對(duì)服務(wù)器構(gòu)成了壓力。因此，從上面的例子中可以看出，服務(wù)器實(shí)際承受的壓力不只取決于業(yè)務(wù)并發(fā)用戶數(shù)，還取決于用戶的業(yè)務(wù)場景。
在實(shí)際的性能測(cè)試工作中，測(cè)試人員一般比較關(guān)心的是業(yè)務(wù)并發(fā)用戶數(shù)，也就是從業(yè)務(wù)角度關(guān)注究竟應(yīng)該設(shè)置多少個(gè)并發(fā)數(shù)比較合理，因此，在后面的討論中，也是主要針對(duì)業(yè)務(wù)并發(fā)用戶數(shù)進(jìn)行討論，而且為了方便，直接將業(yè)務(wù)并發(fā)用戶數(shù)稱為并發(fā)用戶數(shù)。
（1） 計(jì)算平均的并發(fā)用戶數(shù)： C = nL/T
（2） 并發(fā)用戶數(shù)峰值： C’ ≈ C+3根號(hào)C
公式（1）中C是平均的并發(fā)用戶數(shù)；n是login session的數(shù)量；L是login session的平均長度；T指考察的時(shí)間段長度。
公式（2）給出了并發(fā)用戶數(shù)峰值的計(jì)算方式，其中C’指并發(fā)用戶數(shù)的峰值，C就是公式（1）中得到的平均的并發(fā)用戶數(shù)。該公式的得出是假設(shè)用戶的login session產(chǎn)生符合泊松分布而估算得到的。
實(shí)例：
假設(shè)有一個(gè)OA系統(tǒng)，該系統(tǒng)有3000個(gè)用戶，平均每天大約有400個(gè)用戶要訪問該系統(tǒng)，對(duì)一個(gè)典型用戶來說，一天之內(nèi)用戶從登錄到退出該系統(tǒng)的平均時(shí)間為4小時(shí)，在一天的時(shí)間內(nèi)，用戶只在8小時(shí)內(nèi)使用該系統(tǒng)。
則根據(jù)公式（1）和公式（2），可以得到：
C = 400*4/8 = 200
C’≈200+3*根號(hào)200 = 242

       以下是測(cè)試所需的一些常用公式，僅供參考

        F=VU * R / T   R = T / TS

       其中F為吞吐量，VU表示虛擬用戶個(gè)數(shù)，R表示每個(gè)虛擬用戶發(fā)出的請(qǐng)求數(shù)，T表示性能測(cè)試所用的時(shí)間，TS為用戶思考時(shí)間 。

???UML隨想及UML2.0的圖分類：
???使用 UML 上的差異共有以下三種： 1 、分別將 UML 視為草稿、藍(lán)圖與程序語言三種不同用法。 2 、以軟件觀點(diǎn)和概念性觀點(diǎn)來看待 UML 。 3 、 UML 的本質(zhì)在于圖或超模型。

1 、搭配草稿、藍(lán)圖兩種用法的步驟為

1）? 先畫出 UML 草稿

2）? 以 CASE 工具用正向工程轉(zhuǎn)出程序碼大綱

3）? 修改程序碼

4）? 定期從程序碼已 CASE 工具用反向工程轉(zhuǎn)出 UML 設(shè)計(jì)模型

將 UML 視為草稿是在談 [ 選擇性 ] 。選擇主要的模塊進(jìn)行討論。

將 UML 視為藍(lán)圖是在談 [ 完整性 ] 。這種做法可以用在所有 [ 細(xì)節(jié) ] 的工作上，也可以針對(duì)特定的部分化出藍(lán)圖。

模型驅(qū)動(dòng)開發(fā)架構(gòu)（ Model Driven Architecture ， MDA ）： MDA 將 UML 視為程序語言的標(biāo)準(zhǔn)用法。 MDA 將開發(fā)分為兩個(gè)主要部分，模型建立者會(huì)負(fù)責(zé)產(chǎn)生于平臺(tái)無關(guān)的模型 （ Platform Independent Model ， PIM ）， PIM 代表與任何與特定格式無關(guān)的 UML 模型。然后工具可以把 PIM 轉(zhuǎn)換為平臺(tái)特有模型（ PSM ）， PSM 是在某個(gè)特定執(zhí)行環(huán)境之上的模型，其他工具可以將 PSM 轉(zhuǎn)換為某個(gè)平臺(tái)之上的程序碼。

UML 的創(chuàng)造者認(rèn)為 UML 的本質(zhì)在于超模型，圖僅僅是超模型的展現(xiàn)而已。

個(gè)人推薦將UML作為草稿的用法，

UML2.0 中的圖共有如下11種：

1、? 活動(dòng)圖（activity diagram）

2、? 類圖（Class diagram）

3、? 合作圖（ communicationdiagram diagram ）：對(duì)象件的互動(dòng)情形，焦點(diǎn)在連接關(guān)系上

4、? 元件圖（component diagram）元件結(jié)構(gòu)與連接關(guān)系

5、? 合成結(jié)構(gòu)（composite structure）類別在執(zhí)行期的合成情形（UML2 新增 ）

6、? 配置圖（deployment diagram）將工作成果配置到節(jié)點(diǎn)上

7、? 互動(dòng)概圖（interaction overview diagram）混合時(shí)序圖與活動(dòng)圖兩者（UML2新增）

8、? 對(duì)象圖（object diagram）

9、? 套件圖（package diagram）編譯器的階層結(jié)構(gòu)

10、? 時(shí)序圖（sequence diagram）對(duì)象間的互動(dòng)情形，焦點(diǎn)在信息的先后順序。

11、????????????? 狀態(tài)機(jī)圖（state machine diagram）說明事件在對(duì)象中的生命力，如何改變狀態(tài)

12、????????????? 時(shí)序圖（timing diagrame）對(duì)象間的互動(dòng)情形（UML2新增）

13、????????????? 用例圖（use case diagrame）說明使用者如何與系統(tǒng)進(jìn)行交互

?

     摘要: Apache Jakarta Log4J(學(xué)習(xí)筆記) 注:這些筆記來源于恨的網(wǎng)上資料,如與您的文章相沖突,望請(qǐng)見諒.一〉log4j的組件：記錄器、存放器和布局 下面分別講述這幾種組件： 1〉記錄器：log4j允許程序員定義多個(gè)記錄器，每個(gè)記錄器有自己的名字，記錄器之間通過名字來表示隸屬關(guān)系（或家族關(guān)系）。例如記錄器a.b與記錄器a.b.c是父子關(guān)系，而記錄器a與記錄器a.b.c是祖先與后代的...  閱讀全文

Jakarta Commons Logging(JCL)學(xué)習(xí)筆記

簡介：JCL提供一個(gè)日志接口，同時(shí)兼顧輕量級(jí)和不依賴于具體的日志實(shí)現(xiàn)工具。

入門：JCL有兩個(gè)基本的抽象類：Log(基本紀(jì)錄器)和LogFactory(負(fù)責(zé)創(chuàng)建Log實(shí)例)。JCL尋找日志工具的過程如下：

一〉????????????? 尋找當(dāng)前的factory中名叫org.apache. commons.logging.Log配置屬性的值。

二〉????????????? 尋找系統(tǒng)屬性中名叫org.apache.commons.logging.Log的值。

三〉????????????? 如果應(yīng)用程序的CLASSPATH中有Log4j,這是用相關(guān)的包裝類（wrapper）類（Log4Jlogger）.

四〉????????????? 如果應(yīng)用程序運(yùn)行在jdk1.4的系統(tǒng)中，使用相關(guān)的包裝類(JDK1.4logger).

五〉????????????? 使用簡易日志包裝類（SimpleLog）.

使用logging:

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

public class MyClass{

private static Log log=LogFactory.getLog(this.CLASS);

…………………………

}

這些日志信息被送往日志器，如上例中的log。

Log接口中的方法：

定義日志信息的級(jí)別，按嚴(yán)重性有：

log.fatal(Object message);

log.fatal(Object message,Throwable t);

log.error(Object message);

log.error(Object message,Throwable t);

log.warn(Object message);

log.warn(Object message,Throwable t);

log.info(Object message);

log.info(Object message,Throwable t);

log.debug(Object message);

log.debug(Object message,Throwable t);

log.trace(Object message);

log.trace(Object message,Throwable t);

fatal:非常嚴(yán)重的錯(cuò)誤，導(dǎo)致系統(tǒng)終止。期望這類信息被立即顯示到狀態(tài)控制臺(tái)上。

Error:其他運(yùn)行期錯(cuò)誤或不是預(yù)期的條件。期望這類信息被立即顯示到狀態(tài)控制臺(tái)上。

Warn:使用了不贊成使用的API、非常拙劣的使用了API、‘幾乎就是錯(cuò)誤’其他運(yùn)行期不合需要和不合預(yù)期的狀態(tài)（但沒必要將其稱為錯(cuò)誤）。期望這類信息被立即顯示到狀態(tài)控制臺(tái)上。

Info:運(yùn)行期產(chǎn)生的有意義的事件。期望這類信息被立即顯示到狀態(tài)控制臺(tái)上。

Debug:系統(tǒng)流程中的細(xì)節(jié)信息。期望這類信息僅被寫入日志文件中。

Trace:更加細(xì)節(jié)的信息。期望這類信息僅被寫入日志文件中。

用于代碼保護(hù)(表示如果啟用了某種日志信息級(jí)別)：

log.isFatalEnabled();

log.isErrorEnabled();

log.isWarnEnabled();

log.isInfoEnabled();

log.isDebugEnabled();

log.isTraceEnabled();

通常情況下，記錄器的級(jí)別不低于info,通常情況下debug信息不應(yīng)被寫入log文件中。

工作機(jī)理：

一〉???????????? 生命周期：JCL LogFactory必須實(shí)現(xiàn)建立/斷開到日志工具的連接，實(shí)例化/初始化/解構(gòu)一個(gè)日志工具。

二〉???????????? 異常處理：JCL Log接口沒有實(shí)現(xiàn)任何異常處理，對(duì)接口的實(shí)現(xiàn)必須捕獲并處理異常。

記錄器的設(shè)置：log4j時(shí)JCL的首選記錄器：

參數(shù)	值域	默認(rèn)值	說明
Log4j.configuration	?	Log4j.properties	指定配置文件的名字
Log4j.rootCategory	Priority[,appender].*	?	設(shè)定根記錄器級(jí)別
Log4j.logger.	Debug,info,trace,error,fatal	設(shè)定這個(gè)記錄器的級(jí)別	?
Log4j.appender..Threshold	priority	指定紀(jì)錄設(shè)備的最低級(jí)別（console,files,sockets,others）	?