Java 垃圾回收機制詳解(動力節(jié)點Java學(xué)院整理)

1. 垃圾回收的意義

　　在C++中，對象所占的內(nèi)存在程序結(jié)束運行之前一直被占用，在明確釋放之前不能分配給其它對象；而在Java中，當沒有對象引用指向原先分配給某個對象的內(nèi)存時，該內(nèi)存便成為垃圾。JVM的一個系統(tǒng)級線程會自動釋放該內(nèi)存塊。垃圾回收意味著程序不再需要的對象是"無用信息"，這些信息將被丟棄。當一個對象不再被引用的時候，內(nèi)存回收它占領(lǐng)的空間，以便空間被后來的新對象使用。事實上，除了釋放沒用的對象，垃圾回收也可以清除內(nèi)存記錄碎片。由于創(chuàng)建對象和垃圾回收器釋放丟棄對象所占的內(nèi)存空間，內(nèi)存會出現(xiàn)碎片。碎片是分配給對象的內(nèi)存塊之間的空閑內(nèi)存洞。碎片整理將所占用的堆內(nèi)存移到堆的一端，JVM將整理出的內(nèi)存分配給新的對象。

　　垃圾回收能自動釋放內(nèi)存空間，減輕編程的負擔。這使Java 虛擬機具有一些優(yōu)點。首先，它能使編程效率提高。在沒有垃圾回收機制的時候，可能要花許多時間來解決一個難懂的存儲器問題。在用Java語言編程的時候，靠垃圾回收機制可大大縮短時間。其次是它保護程序的完整性， 垃圾回收是Java語言安全性策略的一個重要部份。

　　垃圾回收的一個潛在的缺點是它的開銷影響程序性能。Java虛擬機必須追蹤運行程序中有用的對象，而且最終釋放沒用的對象。這一個過程需要花費處理器的時間。其次垃圾回收算法的不完備性，早先采用的某些垃圾回收算法就不能保證100%收集到所有的廢棄內(nèi)存。當然隨著垃圾回收算法的不斷改進以及軟硬件運行效率的不斷提升，這些問題都可以迎刃而解。

2. 垃圾收集的算法分析

　　Java語言規(guī)范沒有明確地說明JVM使用哪種垃圾回收算法，但是任何一種垃圾回收算法一般要做2件基本的事情：

（1）發(fā)現(xiàn)無用信息對象；

（2）回收被無用對象占用的內(nèi)存空間，使該空間可被程序再次使用。

　　大多數(shù)垃圾回收算法使用了根集(root set)這個概念；所謂根集就是正在執(zhí)行的Java程序可以訪問的引用變量的集合(包括局部變量、參數(shù)、類變量)，程序可以使用引用變量訪問對象的屬性和調(diào)用對象的方法。垃圾回收首先需要確定從根開始哪些是可達的和哪些是不可達的，從根集可達的對象都是活動對象，它們不能作為垃圾被回收，這也包括從根集間接可達的對象。而根集通過任意路徑不可達的對象符合垃圾收集的條件，應(yīng)該被回收。下面介紹幾個常用的算法。

　　2.1. 引用計數(shù)法(Reference Counting Collector)

　　引用計數(shù)法是唯一沒有使用根集的垃圾回收的法，該算法使用引用計數(shù)器來區(qū)分存活對象和不再使用的對象。一般來說，堆中的每個對象對應(yīng)一個引用計數(shù)器。當每一次創(chuàng)建一個對象并賦給一個變量時，引用計數(shù)器置為1。當對象被賦給任意變量時，引用計數(shù)器每次加1當對象出了作用域后(該對象丟棄不再使用)，引用計數(shù)器減1，一旦引用計數(shù)器為0，對象就滿足了垃圾收集的條件。

　　基于引用計數(shù)器的垃圾收集器運行較快，不會長時間中斷程序執(zhí)行，適宜地必須實時運行的程序。但引用計數(shù)器增加了程序執(zhí)行的開銷，因為每次對象賦給新的變量，計數(shù)器加1，而每次現(xiàn)有對象出了作用域生，計數(shù)器減1。

　　2.2. tracing算法(Tracing Collector)

　　tracing算法是為了解決引用計數(shù)法的問題而提出，它使用了根集的概念?；趖racing算法的垃圾收集器從根集開始掃描，識別出哪些對象可達，哪些對象不可達，并用某種方式標記可達對象，例如對每個可達對象設(shè)置一個或多個位。在掃描識別過程中，基于tracing算法的垃圾收集也稱為標記和清除(mark-and-sweep)垃圾收集器.

　　2.3. compacting算法(Compacting Collector)

　　為了解決堆碎片問題，基于tracing的垃圾回收吸收了Compacting算法的思想，在清除的過程中，算法將所有的對象移到堆的一端，堆的另一端就變成了一個相鄰的空閑內(nèi)存區(qū)，收集器會對它移動的所有對象的所有引用進行更新，使得這些引用在新的位置能識別原來的對象。在基于Compacting算法的收集器的實現(xiàn)中，一般增加句柄和句柄表。

　　2.4. copying算法(Coping Collector)

　　該算法的提出是為了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分成一個對象區(qū)和多個空閑區(qū)，程序從對象區(qū)為對象分配空間，當對象滿了，基于coping算法的垃圾回收就從根集中掃描活動對象，并將每個活動對象復(fù)制到空閑區(qū)(使得活動對象所占的內(nèi)存之間沒有空閑間隔)，這樣空閑區(qū)變成了對象區(qū)，原來的對象區(qū)變成了空閑區(qū)，程序會在新的對象區(qū)中分配內(nèi)存。

　　一種典型的基于coping算法的垃圾回收是stop-and-copy算法，它將堆分成對象區(qū)和空閑區(qū)域區(qū)，在對象區(qū)與空閑區(qū)域的切換過程中，程序暫停執(zhí)行。

　　2.5. generation算法(Generational Collector)

　　stop-and-copy垃圾收集器的一個缺陷是收集器必須復(fù)制所有的活動對象，這增加了程序等待時間，這是coping算法低效的原因。在程序設(shè)計中有這樣的規(guī)律：多數(shù)對象存在的時間比較短，少數(shù)的存在時間比較長。因此，generation算法將堆分成兩個或多個，每個子堆作為對象的一代 (generation)。由于多數(shù)對象存在的時間比較短，隨著程序丟棄不使用的對象，垃圾收集器將從最年輕的子堆中收集這些對象。在分代式的垃圾收集器運行后，上次運行存活下來的對象移到下一最高代的子堆中，由于老一代的子堆不會經(jīng)常被回收，因而節(jié)省了時間。

　　2.6. adaptive算法(Adaptive Collector)

　　在特定的情況下，一些垃圾收集算法會優(yōu)于其它算法。基于Adaptive算法的垃圾收集器就是監(jiān)控當前堆的使用情況，并將選擇適當算法的垃圾收集器。

3. System.gc()方法

       命令行參數(shù)透視垃圾收集器的運行

　　使用System.gc()可以不管JVM使用的是哪一種垃圾回收的算法，都可以請求Java的垃圾回收。在命令行中有一個參數(shù)-verbosegc可以查看Java使用的堆內(nèi)存的情況，它的格式如下：

　　java -verbosegc classfile


　　可以看個例子：

class TestGC 
{ 
 public static void main(String[] args) 
 { 
　　 new TestGC(); 
　　 System.gc(); 
　　 System.runFinalization(); 
　　 } 
} 

 在這個例子中，一個新的對象被創(chuàng)建，由于它沒有使用，所以該對象迅速地變?yōu)椴豢蛇_，程序編譯后，執(zhí)行命令：

    　java -verbosegc TestGC 后結(jié)果為：

　　[Full GC 168K->97K(1984K)， 0.0253873 secs]

　　機器的環(huán)境為，Windows 2000 + JDK1.3.1，箭頭前后的數(shù)據(jù)168K和97K分別表示垃圾收集GC前后所有存活對象使用的內(nèi)存容量，說明有168K-97K=71K的對象容量被回收，括號內(nèi)的數(shù)據(jù)1984K為堆內(nèi)存的總?cè)萘?，收集所需要的時間是0.0253873秒（這個時間在每次執(zhí)行的時候會有所不同）。

      需要注意的是，調(diào)用System.gc()也僅僅是一個請求(建議)。JVM接受這個消息后，并不是立即做垃圾回收，而只是對幾個垃圾回收算法做了加權(quán)，使垃圾回收操作容易發(fā)生，或提早發(fā)生，或回收較多而已。

4. finalize()方法

      在JVM垃圾回收器收集一個對象之前，一般要求程序調(diào)用適當?shù)姆椒ㄡ尫刨Y源，但在沒有明確釋放資源的情況下，Java提供了缺省機制來終止該對象心釋放資源，這個方法就是finalize（）。它的原型為：

　　protected void finalize() throws Throwable

　　在finalize()方法返回之后，對象消失，垃圾收集開始執(zhí)行。原型中的throws Throwable表示它可以拋出任何類型的異常。

　　之所以要使用finalize()，是存在著垃圾回收器不能處理的特殊情況。假定你的對象（并非使用new方法）獲得了一塊“特殊”的內(nèi)存區(qū)域，由于垃圾回收器只知道那些顯示地經(jīng)由new分配的內(nèi)存空間，所以它不知道該如何釋放這塊“特殊”的內(nèi)存區(qū)域，那么這個時候java允許在類中定義一個由finalize()方法。

      特殊的區(qū)域例如：

1）由于在分配內(nèi)存的時候可能采用了類似 C語言的做法，而非JAVA的通常new做法。這種情況主要發(fā)生在native method中，比如native method調(diào)用了C/C++方法malloc()函數(shù)系列來分配存儲空間，但是除非調(diào)用free()函數(shù)，否則這些內(nèi)存空間將不會得到釋放，那么這個時候就可能造成內(nèi)存泄漏。但是由于free()方法是在C/C++中的函數(shù)，所以finalize()中可以用本地方法來調(diào)用它。以釋放這些“特殊”的內(nèi)存空間。

2）又或者打開的文件資源，這些資源不屬于垃圾回收器的回收范圍。

      換言之，finalize()的主要用途是釋放一些其他做法開辟的內(nèi)存空間，以及做一些清理工作。因為在JAVA中并沒有提夠像“析構(gòu)”函數(shù)或者類似概念的函數(shù)，要做一些類似清理工作的時候，必須自己動手創(chuàng)建一個執(zhí)行清理工作的普通方法，也就是override Object這個類中的finalize()方法。例如，假設(shè)某一個對象在創(chuàng)建過程中會將自己繪制到屏幕上，如果不是明確地從屏幕上將其擦出，它可能永遠都不會被清理。如果在finalize()加入某一種擦除功能，當GC工作時，finalize()得到了調(diào)用，圖像就會被擦除。要是GC沒有發(fā)生，那么這個圖像就會被一直保存下來。

      一旦垃圾回收器準備好釋放對象占用的存儲空間，首先會去調(diào)用finalize()方法進行一些必要的清理工作。只有到下一次再進行垃圾回收動作的時候，才會真正釋放這個對象所占用的內(nèi)存空間。

　　在普通的清除工作中，為清除一個對象，那個對象的用戶必須在希望進行清除的地點調(diào)用一個清除方法。這與C++"析構(gòu)函數(shù)"的概念稍有抵觸。在C++中，所有對象都會破壞（清除）?；蛘邠Q句話說，所有對象都"應(yīng)該"破壞。若將C++對象創(chuàng)建成一個本地對象，比如在堆棧中創(chuàng)建（在Java中是不可能的，Java都在堆中），那么清除或破壞工作就會在"結(jié)束花括號"所代表的、創(chuàng)建這個對象的作用域的末尾進行。若對象是用new創(chuàng)建的（類似于Java），那么當程序員調(diào)用C++的 delete命令時（Java沒有這個命令），就會調(diào)用相應(yīng)的析構(gòu)函數(shù)。若程序員忘記了，那么永遠不會調(diào)用析構(gòu)函數(shù)，我們最終得到的將是一個內(nèi)存"漏洞"，另外還包括對象的其他部分永遠不會得到清除。

　　相反，Java不允許我們創(chuàng)建本地（局部）對象--無論如何都要使用new。但在Java中，沒有"delete"命令來釋放對象，因為垃圾回收器會幫助我們自動釋放存儲空間。所以如果站在比較簡化的立場，我們可以說正是由于存在垃圾回收機制，所以Java沒有析構(gòu)函數(shù)。然而，隨著以后學(xué)習(xí)的深入，就會知道垃圾收集器的存在并不能完全消除對析構(gòu)函數(shù)的需要，或者說不能消除對析構(gòu)函數(shù)代表的那種機制的需要（原因見下一段。另外finalize()函數(shù)是在垃圾回收器準備釋放對象占用的存儲空間的時候被調(diào)用的，絕對不能直接調(diào)用finalize()，所以應(yīng)盡量避免用它）。若希望執(zhí)行除釋放存儲空間之外的其他某種形式的清除工作，仍然必須調(diào)用Java中的一個方法。它等價于C++的析構(gòu)函數(shù)，只是沒后者方便。

      在C++中所有的對象運用delete()一定會被銷毀，而JAVA里的對象并非總會被垃圾回收器回收。In another word, 1 對象可能不被垃圾回收，2 垃圾回收并不等于“析構(gòu)”，3 垃圾回收只與內(nèi)存有關(guān)。也就是說，并不是如果一個對象不再被使用，是不是要在finalize()中釋放這個對象中含有的其它對象呢？不是的。因為無論對象是如何創(chuàng)建的，垃圾回收器都會負責(zé)釋放那些對象占有的內(nèi)存。

5. 觸發(fā)主GC（Garbage Collector）的條件

　　JVM進行次GC的頻率很高,但因為這種GC占用時間極短,所以對系統(tǒng)產(chǎn)生的影響不大。更值得關(guān)注的是主GC的觸發(fā)條件,因為它對系統(tǒng)影響很明顯?？偟膩碚f,有兩個條件會觸發(fā)主GC:

　　1)當應(yīng)用程序空閑時,即沒有應(yīng)用線程在運行時,GC會被調(diào)用。因為GC在優(yōu)先級最低的線程中進行,所以當應(yīng)用忙時,GC線程就不會被調(diào)用,但以下條件除外。

　　2)Java堆內(nèi)存不足時,GC會被調(diào)用。當應(yīng)用線程在運行,并在運行過程中創(chuàng)建新對象,若這時內(nèi)存空間不足,JVM就會強制地調(diào)用GC線程,以便回收內(nèi)存用于新的分配。若GC一次之后仍不能滿足內(nèi)存分配的要求,JVM會再進行兩次GC作進一步的嘗試,若仍無法滿足要求,則 JVM將報“out of memory”的錯誤,Java應(yīng)用將停止。

　　由于是否進行主GC由JVM根據(jù)系統(tǒng)環(huán)境決定,而系統(tǒng)環(huán)境在不斷的變化當中,所以主GC的運行具有不確定性,無法預(yù)計它何時必然出現(xiàn),但可以確定的是對一個長期運行的應(yīng)用來說,其主GC是反復(fù)進行的。

6. 減少GC開銷的措施

　　根據(jù)上述GC的機制,程序的運行會直接影響系統(tǒng)環(huán)境的變化,從而影響GC的觸發(fā)。若不針對GC的特點進行設(shè)計和編碼,就會出現(xiàn)內(nèi)存駐留等一系列負面影響。為了避免這些影響,基本的原則就是盡可能地減少垃圾和減少GC過程中的開銷。

具體措施包括以下幾個方面:

　　(1)不要顯式調(diào)用System.gc()

　　此函數(shù)建議JVM進行主GC,雖然只是建議而非一定,但很多情況下它會觸發(fā)主GC,從而增加主GC的頻率,也即增加了間歇性停頓的次數(shù)。

　　(2)盡量減少臨時對象的使用

　　臨時對象在跳出函數(shù)調(diào)用后,會成為垃圾,少用臨時變量就相當于減少了垃圾的產(chǎn)生,從而延長了出現(xiàn)上述第二個觸發(fā)條件出現(xiàn)的時間,減少了主GC的機會。

　　(3)對象不用時最好顯式置為Null

　　一般而言,為Null的對象都會被作為垃圾處理,所以將不用的對象顯式地設(shè)為Null,有利于GC收集器判定垃圾,從而提高了GC的效率。

　　(4)盡量使用StringBuffer,而不用String來累加字符串

　　由于String是固定長的字符串對象,累加String對象時,并非在一個String對象中擴增,而是重新創(chuàng)建新的String對象,如Str5=Str1+Str2+Str3+Str4,這條語句執(zhí)行過程中會產(chǎn)生多個垃圾對象,因為對次作“+”操作時都必須創(chuàng)建新的String對象,但這些過渡對象對系統(tǒng)來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字符串,因StringBuffer是可變長的,它在原有基礎(chǔ)上進行擴增,不會產(chǎn)生中間對象。

　　(5)能用基本類型如Int,Long,就不用Integer,Long對象

　　基本類型變量占用的內(nèi)存資源比相應(yīng)對象占用的少得多,如果沒有必要,最好使用基本變量。

　　(6)盡量少用靜態(tài)對象變量

　　靜態(tài)變量屬于全局變量,不會被GC回收,它們會一直占用內(nèi)存。

　　(7)分散對象創(chuàng)建或刪除的時間

　　集中在短時間內(nèi)大量創(chuàng)建新對象,特別是大對象,會導(dǎo)致突然需要大量內(nèi)存,JVM在面臨這種情況時,只能進行主GC,以回收內(nèi)存或整合內(nèi)存碎片,從而增加主GC的頻率。集中刪除對象,道理也是一樣的。它使得突然出現(xiàn)了大量的垃圾對象,空閑空間必然減少,從而大大增加了下一次創(chuàng)建新對象時強制主GC的機會。 

      下面這個例子向大家展示了垃圾收集所經(jīng)歷的過程，并對前面的陳述進行了總結(jié)。  

class Chair { 
　　static boolean gcrun = false; 
　　static boolean f = false; 
　　static int created = 0; 
　　static int finalized = 0; 
　　int i; 
　　Chair() { 
　　 i = ++created; 
　　 if(created == 47) 
　　　  System.out.println("Created 47"); 
　　} 
　　protected void finalize() { 
　　 if(!gcrun) { 
　　　  gcrun = true; 
　　　  System.out.println("Beginning to finalize after " + created + " Chairs have been created"); 
　　 } 
　　 if(i == 47) { 
　　　  System.out.println("Finalizing Chair #47， " +"Setting flag to stop Chair creation"); 
　　　  f = true; 
　　 } 
　　 finalized++; 
　　 if(finalized >= created) 
　　　  System.out.println("All " + finalized + " finalized"); 
　　} 
} 
 
public class Garbage { 
　　public static void main(String[] args) { 
　　if(args.length == 0) { 
　　　 System.err.println("Usage: /n" + "<a  rel="external nofollow" class='replace_word' title="Java 知識庫" target='_blank' style='color:#df3434; font-weight:bold;'>Java </a>Garbage before/n or:/n" + "java Garbage after"); 
　　　 return; 
　　} 
　　while(!Chair.f) { 
　　　 new Chair(); 
　　　 new String("To take up space"); 
　　} 
　　System.out.println("After all Chairs have been created:/n" + "total created = " + Chair.created + 
　　"， total finalized = " + Chair.finalized); 
　　if(args[0].equals("before")) { 
　　　　System.out.println("gc():"); 
　　　　System.gc(); 
　　　　System.out.println("runFinalization():"); 
　　　　System.runFinalization(); 
　　} 
　　System.out.println("bye!"); 
　　if(args[0].equals("after")) 
　　　 System.runFinalizersOnExit(true); 
　　} 
} 

上面這個程序創(chuàng)建了許多Chair對象，而且在垃圾收集器開始運行后的某些時候，程序會停止創(chuàng)建Chair。由于垃圾收集器可能在任何時間運行，所以我們不能準確知道它在何時啟動。因此，程序用一個名為gcrun的標記來指出垃圾收集器是否已經(jīng)開始運行。利用第二個標記f，Chair可告訴main()它應(yīng)停止對象的生成。這兩個標記都是在finalize()內(nèi)部設(shè)置的，它調(diào)用于垃圾收集期間。另兩個static變量--created以及 finalized--分別用于跟蹤已創(chuàng)建的對象數(shù)量以及垃圾收集器已進行完收尾工作的對象數(shù)量。最后，每個Chair都有它自己的（非 static）int i，所以能跟蹤了解它具體的編號是多少。編號為47的Chair進行完收尾工作后，標記會設(shè)為true，最終結(jié)束Chair對象的創(chuàng)建過程。

7. 關(guān)于垃圾回收的幾點補充

　　經(jīng)過上述的說明，可以發(fā)現(xiàn)垃圾回收有以下的幾個特點：

　　（1）垃圾收集發(fā)生的不可預(yù)知性：由于實現(xiàn)了不同的垃圾回收算法和采用了不同的收集機制，所以它有可能是定時發(fā)生，有可能是當出現(xiàn)系統(tǒng)空閑CPU資源時發(fā)生，也有可能是和原始的垃圾收集一樣，等到內(nèi)存消耗出現(xiàn)極限時發(fā)生，這與垃圾收集器的選擇和具體的設(shè)置都有關(guān)系。

　?。?）垃圾收集的精確性：

主要包括2 個方面：

（a）垃圾收集器能夠精確標記活著的對象；

（b）垃圾收集器能夠精確地定位對象之間的引用關(guān)系。前者是完全地回收所有廢棄對象的前提，否則就可能造成內(nèi)存泄漏。而后者則是實現(xiàn)歸并和復(fù)制等算法的必要條件。所有不可達對象都能夠可靠地得到回收，所有對象都能夠重新分配，允許對象的復(fù)制和對象內(nèi)存的縮并，這樣就有效地防止內(nèi)存的支離破碎。

　?。?）現(xiàn)在有許多種不同的垃圾收集器，每種有其算法且其表現(xiàn)各異，既有當垃圾收集開始時就停止應(yīng)用程序的運行，又有當垃圾收集開始時也允許應(yīng)用程序的線程運行，還有在同一時間垃圾收集多線程運行。

　?。?）垃圾收集的實現(xiàn)和具體的JVM 以及JVM的內(nèi)存模型有非常緊密的關(guān)系。不同的JVM 可能采用不同的垃圾收集，而JVM 的內(nèi)存模型決定著該JVM可以采用哪些類型垃圾收集。現(xiàn)在，HotSpot 系列JVM中的內(nèi)存系統(tǒng)都采用先進的面向?qū)ο蟮目蚣茉O(shè)計，這使得該系列JVM都可以采用最先進的垃圾收集。

　?。?）隨著技術(shù)的發(fā)展，現(xiàn)代垃圾收集技術(shù)提供許多可選的垃圾收集器，而且在配置每種收集器的時候又可以設(shè)置不同的參數(shù)，這就使得根據(jù)不同的應(yīng)用環(huán)境獲得最優(yōu)的應(yīng)用性能成為可能。

　　針對以上特點，我們在使用的時候要注意：

　　（1）不要試圖去假定垃圾收集發(fā)生的時間，這一切都是未知的。比如，方法中的一個臨時對象在方法調(diào)用完畢后就變成了無用對象，這個時候它的內(nèi)存就可以被釋放。

　　（2）Java中提供了一些和垃圾收集打交道的類，而且提供了一種強行執(zhí)行垃圾收集的方法--調(diào)用System.gc()，但這同樣是個不確定的方法。Java 中并不保證每次調(diào)用該方法就一定能夠啟動垃圾收集，它只不過會向JVM發(fā)出這樣一個申請，到底是否真正執(zhí)行垃圾收集，一切都是個未知數(shù)。

　?。?）挑選適合自己的垃圾收集器。一般來說，如果系統(tǒng)沒有特殊和苛刻的性能要求，可以采用JVM的缺省選項。否則可以考慮使用有針對性的垃圾收集器，比如增量收集器就比較適合實時性要求較高的系統(tǒng)之中。系統(tǒng)具有較高的配置，有比較多的閑置資源，可以考慮使用并行標記/清除收集器。

　?。?）關(guān)鍵的也是難把握的問題是內(nèi)存泄漏。良好的編程習(xí)慣和嚴謹?shù)木幊虘B(tài)度永遠是最重要的，不要讓自己的一個小錯誤導(dǎo)致內(nèi)存出現(xiàn)大漏洞。

　?。?）盡早釋放無用對象的引用。大多數(shù)程序員在使用臨時變量的時候，都是讓引用變量在退出活動域(scope)后，自動設(shè)置為null，暗示垃圾收集器來收集該對象，還必須注意該引用的對象是否被監(jiān)聽，如果有，則要去掉監(jiān)聽器，然后再賦空值。

以上所述是小編給大家介紹的Java 垃圾回收機制(動力節(jié)點Java學(xué)院整理)，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對億速云網(wǎng)站的支持！