-XX:SurvivorRatio：新生代中Eden區(qū)域與Survivor區(qū)域的容量比值，默認(rèn)值為8。兩個Survivor區(qū)與一個Eden區(qū)的比值為2:8,一個Survivor區(qū)占整個年輕代的1/10。
-Xss： 每個線程的堆棧大小。JDK5.0以后每個線程堆棧大小為1M,以前每個線程堆棧大小為256K。應(yīng)根據(jù)應(yīng)用的線程所需內(nèi)存大小進(jìn)行適當(dāng)調(diào)整。在相同物理 內(nèi)存下,減小這個值能生成更多的線程。但是操作系統(tǒng)對一個進(jìn)程內(nèi)的線程數(shù)還是有限制的，不能無限生成，經(jīng)驗值在3000~5000左右。一般小的應(yīng)用， 如果棧不是很深， 應(yīng)該是128k夠用的，大的應(yīng)用建議使用256k。這個選項對性能影響比較大，需要嚴(yán)格的測試。和threadstacksize選項解釋很類似,官方文 檔似乎沒有解釋,在論壇中有這樣一句話:"-Xss is translated in a VM flag named ThreadStackSize”一般設(shè)置這個值就可以了。
-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)程序運行時可通過jstat –gcutil來查看堆中各個內(nèi)存區(qū)域的變化以及GC的工作狀態(tài)；
2）啟動時可添加-XX: PrintGCDetails –Xloggc:<file>輸出到日志文件來查看GC的狀況；
3）jmap –heap可用于查看各個內(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的比例，啟動后可通過jmap –heap [pid]來查看。
默認(rèn)情況下，僅在TLAB或eden上分配，只有兩種情況下會在老生代分配：
1、需要分配的內(nèi)存大小超過eden space大小；
2、在配置了PretenureSizeThreshold的情況下，對象大小大于此值。
默認(rèn)情況下，觸發(fā)Minor GC時：
之前Minor GC晉級到old的平均大小 < 老生代的剩余空間 < eden from Survivor的使用空間。當(dāng)HandlePromotionFailure為true，則僅觸發(fā)minor gc；如為false，則觸發(fā)full GC。
默認(rèn)情況下，新生代對象晉升到老生代的規(guī)則：
1、經(jīng)歷多次minor gc仍存活的對象，可通過以下參數(shù)來控制：以MaxTenuringThreshold值為準(zhǔn)，默認(rèn)為15。
2、to space放不下的，直接放入老生代；
2）并行GC（ParNew）：CMS GC時默認(rèn)采用，也可采用-XX: UseParNewGC強(qiáng)制指定；垃圾回收的時候采用多線程的方式。
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，這點要特別注意。
默認(rèn)情況下，當(dāng)TLAB、eden上分配都失敗時，判斷需要分配的內(nèi)存大小是否 >= eden space的一半大小，如是就直接在老生代上分配；
默認(rèn)情況下的垃圾回收規(guī)則：
1、在回收前PS GC會先檢測之前每次PS GC時，晉升到老生代的平均大小是否大于老生代的剩余空間，如大于則直接觸發(fā)full GC；
2、在回收后，也會按照上面的規(guī)則進(jìn)行檢測。
默認(rèn)情況下的新生代對象晉升到老生代的規(guī)則：
1、經(jīng)歷多次minor gc仍存活的對象，可通過以下參數(shù)來控制：AlwaysTenure，默認(rèn)false，表示只要minor GC時存活，就晉升到老生代；NeverTenure，默認(rèn)false，表示永不晉升到老生代；上面兩個都沒設(shè)置的情冴下，如 UseAdaptiveSizePolicy，啟動時以InitialTenuringThreshold值作為存活次數(shù)的閾值，在每次ps gc后會動態(tài)調(diào)整，如不使用UseAdaptiveSizePolicy，則以MaxTenuringThreshold為準(zhǔn)。
2、to space放不下的，直接放入老生代。
在回收后，如UseAdaptiveSizePolicy，PS GC會根據(jù)運行狀態(tài)動態(tài)調(diào)整eden、to以及TenuringThreshold的大小。如果不希望動態(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時的悲觀策略；
4）minor GC后在eden上分配內(nèi)存仍然失敗；
5）執(zhí)行heap dump時；
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á)一定比率時觸發(fā)；
Hotspot V 1.6中默認(rèn)為65%%uFF0C可通過PrintCMSInitiationStatistics（此參數(shù)在V 1.5中不能用）來查看這個值到底是多少；可通過CMSInitiatingOccupancyFraction來強(qiáng)制指定，默認(rèn)值并不是賦值在了這個值 上，是根據(jù)如下公式計算出來的： ((100 – MinHeapFreeRatio) (double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; 其中,MinHeapFreeRatio默認(rèn)值： 40 CMSTriggerRatio默認(rèn)值： 80。
2、當(dāng)perm gen采用CMS收集且空間使用到一定比率時觸發(fā)；
perm gen采用CMS收集需設(shè)置：-XX: CMSClassUnloadingEnabled Hotspot V 1.6中默認(rèn)為65%%uFF1B可通過CMSInitiatingPermOccupancyFraction來強(qiáng)制指定，同樣，它是根據(jù)如下公式計算出來的： ((100 – MinHeapFreeRatio) (double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; 其中，MinHeapFreeRatio默認(rèn)值： 40 CMSTriggerPermRatio默認(rèn)值： 80。
3、Hotspot根據(jù)成本計算決定是否需要執(zhí)行CMS GC；可通過-XX: UseCMSInitiatingOccupancyOnly來去掉這個動態(tài)執(zhí)行的策略。
4、外部調(diào)用了System.gc，且設(shè)置了ExplicitGCInvokesConcurrent；需要注意，在hotspot 6中，在這種情況下如應(yīng)用同時使用了NIO，可能會出現(xiàn)bug。
6、GC組合
1）默認(rèn)GC組合
2）可選的GC組合
7、GC監(jiān)測
1）jstat –gcutil [pid] [intervel] [count]
2）-verbose:gc // 可以輔助輸出一些詳細(xì)的GC信息；-XX: PrintGCDetails // 輸出GC詳細(xì)信息；-XX: PrintGCApplicationStoppedTime // 輸出GC造成應(yīng)用暫停的時間
-XX: PrintGCDateStamps // GC發(fā)生的時間信息；-XX: PrintHeapAtGC // 在GC前后輸出堆中各個區(qū)域的大小；-Xloggc:[file] // 將GC信息輸出到單獨的文件中，建議都加上，這個消耗不大，而且對查問題和調(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、評估現(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的消耗時間？
3）降低Full GC所造成的應(yīng)用停頓時間？
4）降低Minor GC執(zhí)行頻率？
5）降低Minor GC消耗時間？
例如某系統(tǒng)的GC調(diào)優(yōu)目標(biāo)：降低Full GC執(zhí)行頻率的同時，盡可能降低minor GC的執(zhí)行頻率、消耗時間以及GC對應(yīng)用造成的停頓時間。
衡量調(diào)優(yōu)：
1、衡量工具
1）打印GC日志信息：-XX: PrintGCDetails –XX: PrintGCApplicationStoppedTime -Xloggc: {文件名} -XX: PrintGCTimeStamps
2）jmap：（由于每個版本jvm的默認(rèn)值可能會有改變，建議還是用jmap首先觀察下目前每個代的內(nèi)存大小、GC方式） ?
3）運行狀況監(jiān)測工具：jstat、jvisualvm、sar 、gclogviewer
2、應(yīng)收集的信息
1）minor gc的執(zhí)行頻率；full gc的執(zhí)行頻率，每次GC耗時多少？
2）高峰期什么狀況？
3）minor gc回收的效果如何？survivor的消耗狀況如何，每次有多少對象會進(jìn)入老生代？
4）full gc回收的效果如何？（簡單的memory leak判斷方法）
5）系統(tǒng)的load、cpu消耗、qps or tps、響應(yīng)時間
QPS每秒查詢率：是對一個特定的查詢服務(wù)器在規(guī)定時間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)。在因特網(wǎng)上，作為域名服務(wù)器的機(jī)器性能經(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ā)機(jī)制，可通過：-XX: DisableExplicitGC來禁止或通過 -Dsun.rmi.dgc.server.gcInterval=3600000來控制觸發(fā)的時間。
1）降低Full GC執(zhí)行頻率 – 通常瓶頸
老生代本身占用的內(nèi)存空間就一直偏高，所以只要稍微放點對象到老生代，就full GC了；
通常原因：系統(tǒng)緩存的東西太多；
例如：使用oracle 10g驅(qū)動時preparedstatement cache太大；
查找辦法：現(xiàn)執(zhí)行Dump然后再進(jìn)行MAT分析；
（1）Minor GC后總是有對象不斷的進(jìn)入老生代，導(dǎo)致老生代不斷的滿
通常原因：Survivor太小了
系統(tǒng)表現(xiàn)：系統(tǒng)響應(yīng)太慢、請求量太大、每次請求分配的內(nèi)存太多、分配的對象太大…
查找辦法：分析兩次minor GC之間到底哪些地方分配了內(nèi)存；
利用jstat觀察Survivor的消耗狀況，-XX:PrintHeapAtGC，輸出GC前后的詳細(xì)信息；
對于系統(tǒng)響應(yīng)慢可以采用系統(tǒng)優(yōu)化，不是GC優(yōu)化的內(nèi)容；
（2）老生代的內(nèi)存占用一直偏高
調(diào)優(yōu)方法：① 擴(kuò)大老生代的大小（減少新生代的大小或調(diào)大heap的 大小）；
減少new注意對minor gc的影響并且同時有可能造成full gc還是嚴(yán)重；
調(diào)大heap注意full gc的時間的延長，cpu夠強(qiáng)悍嘛，os是32 bit的嗎？
② 程序優(yōu)化（去掉一些不必要的緩存）
（3）Minor GC后總是有對象不斷的進(jìn)入老生代
前提：這些進(jìn)入老生代的對象在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）擴(kuò)大heap、擴(kuò)大新生代、擴(kuò)大eden。注意點：降低每次請求分配的內(nèi)存；橫向增加機(jī)器的數(shù)量分擔(dān)請求的數(shù)量。
（6）降低Minor GC執(zhí)行時間
通常原因：新生代太大了，響應(yīng)速度太慢了，導(dǎo)致每次Minor GC時存活的對象多
通常辦法：1）減小點新生代吧；2）增加CPU的數(shù)量、升級CPU的配置；加快系統(tǒng)的響應(yīng)速度
細(xì)微調(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)存？
9、系統(tǒng)調(diào)優(yōu)舉例
現(xiàn)象：1、系統(tǒng)響應(yīng)速度大概為100ms；2、當(dāng)系統(tǒng)QPS增長到40時，機(jī)器每隔5秒就執(zhí)行一次minor gc，每隔3分鐘就執(zhí)行一次full gc，并且很快就一直full GC了；4、每次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的對象。可選方法：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次。
10、垃圾回收的實現(xiàn)原理
內(nèi)存回收的實現(xiàn)方法：1）引用計數(shù)：不適合復(fù)雜對象的引用關(guān)系，尤其是循環(huán)依賴的場景。2）有向圖Tracing：適合于復(fù)雜對象的引用關(guān)系場景，Hotspot采用這種。常用算法：Copying、Mark-Sweep、Mark-Compact。
Hotspot從root set開始掃描有引用的對象并對Reference類型的對象進(jìn)行特殊處理。
以下是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ū)上進(jìn)行分配，分配成功則返回；分配失敗則繼續(xù)；
3）檢查是否需要嘗試在老生代上分配，如需要，則遍歷所有代并檢查是否可在該代上分配，如可以則進(jìn)行分配；如不需要在老生代上嘗試分配，則繼續(xù)；
4）根據(jù)策略決定執(zhí)行新生代GC或Full GC，執(zhí)行full gc時不清除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晉級到老生代的平均大小，如大于返回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，如需處理，則保持這些新生代對象不動；
新生代可用GC-PS
完整內(nèi)存分配策略
1）先在TLAB上分配，分配失敗則直接在eden上分配；
2）當(dāng)eden上分配失敗時，檢查需要分配的大小是否 >= 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í)行的時間超過，直接結(jié)束；
2）先調(diào)用invoke_nopolicy
2.1 先檢查是不是要嘗試scavenge；
2.1.1 to space必須為空，如不為空，則返回false；
2.1.2 獲取之前所有minor gc晉級到old的平均大小，并對比目前eden from已使用的大小，取更小的一個值，如老生代剩余空間小于此值，則返回false，如大于則返回true；
2.2 如不需要嘗試scavenge，則返回false，否則繼續(xù)；
2.3 多線程掃描活的對象，并基亍copying算法回收，回收時相應(yīng)的晉升對象到舊生代；
2.4 如UseAdaptiveSizePolicy，那么重新計算to space和tenuringThreshold的值，并調(diào)整。
3）如invoke_nopolicy返回的是false，或之前所有minor gc晉級到老生代的平均大小 > 舊生代的剩余空間，那么繼續(xù)下面的步驟，否則結(jié)束；
4）如UseParallelOldGC，則執(zhí)行PSParallelCompact，如不是UseParallelOldGC，則執(zhí)行PSMarkSweep。
老生代并行CMS GC：
優(yōu)缺點：
1） 大部分時候和應(yīng)用并發(fā)進(jìn)行，因此只會造成很短的暫停時間；
2）浮動垃圾，沒辦法，所以內(nèi)存空間要稍微大一點；
3）內(nèi)存碎片，-XX: UseCMSCompactAtFullCollection 來解決；
4） 爭搶CPU，這GC方式就這樣；
5）多次remark，所以總的gc時間會比并行的長；
6）內(nèi)存分配，free list方式，so性能稍差，對minor GC會有一點影響；
7）和應(yīng)用并發(fā)，有可能分配和回收同時，產(chǎn)生競爭，引入了鎖，JVM分配優(yōu)先。
11、TLAB的解釋
堆內(nèi)的對象數(shù)據(jù)是各個線程所共享的，所以當(dāng)在堆內(nèi)創(chuàng)建新的對象時，就需要進(jìn)行鎖操作。鎖操作是比較耗時，因此JVM為每個線在堆上分配了一塊“自留地” ——TLAB(全稱是Thread Local Allocation Buffer)，位于堆內(nèi)存的新生代，也就是Eden區(qū)。每個線程在創(chuàng)建新的對象時，會首先嘗試在自己的TLAB里進(jìn)行分配，如果成功就返回，失敗了再到 共享的Eden區(qū)里去申請空間。在線程自己的TLAB區(qū)域創(chuàng)建對象失敗一般有兩個原因：一是對象太大，二是自己的TLAB區(qū)剩余空間不夠。通常默認(rèn)的 TLAB區(qū)域大小是Eden區(qū)域的1%%uFF0C當(dāng)然也可以手工進(jìn)行調(diào)整，對應(yīng)的JVM參數(shù)是-XX:TLABWasteTargetPercent。
參考文獻(xiàn)：
1、Sun JDK 1.6 GC（Garbage Collector） 作者：畢玄
更多關(guān)于云服務(wù)器，域名注冊，虛擬主機(jī)的問題，請訪問三五互聯(lián)官網(wǎng)：m.shinetop.cn