java垃圾回識訓制

1、垃圾收集器概述

       垃圾收集器是垃圾回收演算法（標記-清除演算法、復制演算法、標記-整理演算法、火車演算法）的具體實作，不同商家、不同版本的JVM所提供的垃圾收集器可能會有很在差別，本文主要介紹HotSpot虛擬機中的垃圾收集器，

1-1、垃圾收集器組合

       JDK7/8后，HotSpot虛擬機所有收集器及組合（連線），如下圖：

    

（A）、圖中展示了7種不同分代的收集器：        Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1； （B）、而它們所處區域，則表明其是屬于新生代收集器還是老年代收集器：       新生代收集器：Serial、ParNew、Parallel Scavenge；       老年代收集器：Serial Old、Parallel Old、CMS；       整堆收集器：G1； （C）、兩個收集器間有連線，表明它們可以搭配使用：        Serial/Serial Old、Serial/CMS、ParNew/Serial Old、ParNew/CMS、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old、G1； （D）、其中Serial Old作為CMS出現"Concurrent Mode Failure"失敗的后備預案（后面介紹）；

1-2、并發垃圾收集和并行垃圾收集的區別

（A）、并行（Parallel）        指多條垃圾收集執行緒并行作業，但此時用戶執行緒仍然處于等待狀態；        如ParNew、Parallel Scavenge、Parallel Old； （B）、并發（Concurrent）        指用戶執行緒與垃圾收集執行緒同時執行（但不一定是并行的，可能會交替執行）；       用戶程式在繼續運行，而垃圾收集程式執行緒運行于另一個CPU上；            如CMS、G1（也有并行）；

1-3、Minor GC和Full GC的區別

（A）、Minor GC        又稱新生代GC，指發生在新生代的垃圾收集動作；        因為Java物件大多是朝生夕滅，所以Minor GC非常頻繁，一般回收速度也比較快； （B）、Full GC        又稱Major GC或老年代GC，指發生在老年代的GC；        出現Full GC經常會伴隨至少一次的Minor GC（不是絕對，Parallel Sacvenge收集器就可以選擇設定Major GC策略）；       Major GC速度一般比Minor GC慢10倍以上；

        

下面將介紹這些收集器的特性、基本原理和使用場景，并重點分析CMS和G1這兩款相對復雜的收集器；但需要明確一個觀點：        沒有最好的收集器，更沒有萬能的收集；       選擇的只能是適合具體應用場景的收集器，

2、Serial收集器

       Serial（串行）垃圾收集器是最基本、發展歷史最悠久的收集器；        JDK1.3.1前是HotSpot新生代收集的唯一選擇； 1、特點       針對新生代；       采用復制演算法；       單執行緒收集；        進行垃圾收集時，必須暫停所有作業執行緒，直到完成；                    即會"Stop The World"；       Serial/Serial Old組合收集器運行示意圖如下：

       

2、應用場景       依然是HotSpot在Client模式下默認的新生代收集器；       也有優于其他收集器的地方：

      簡單高效（與其他收集器的單執行緒相比）；       對于限定單個CPU的環境來說，Serial收集器沒有執行緒互動（切換）開銷，可以獲得最高的單執行緒收集效率；       在用戶的桌面應用場景中，可用記憶體一般不大（幾十M至一兩百M），可以在較短時間內完成垃圾收集（幾十MS至一百多MS）,只要不頻繁發生，這是可以接受的

3、設定引數       "-XX:+UseSerialGC"：添加該引數來顯式的使用串行垃圾收集器； 4、Stop TheWorld說明       JVM在后臺自動發起和自動完成的，在用戶不可見的情況下，把用戶正常的作業執行緒全部停掉，即GC停頓；       會帶給用戶不良的體驗；

      從JDK1.3到現在，從Serial收集器-》Parallel收集器-》CMS-》G1，用戶執行緒停頓時間不斷縮短，但仍然無法完全消除；

      更多"Stop The World"資訊請參考：《Java虛擬機垃圾回收(一) 基礎》"2-2、可達性分析演算法" 更多Serial收集器請參考：       《Memory Management in the Java HotSpot? Virtual Machine》 4.3節 Serial Collector（記憶體管理白皮書）：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf       《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》 第5節 Available Collectors（官方的垃圾收集調優指南）：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref27

3、ParNew收集器

      ParNew垃圾收集器是Serial收集器的多執行緒版本， 1、特點       除了多執行緒外，其余的行為、特點和Serial收集器一樣；       如Serial收集器可用控制引數、收集演算法、Stop The World、記憶體分配規則、回收策略等；       兩個收集器共用了不少代碼；       ParNew/Serial Old組合收集器運行示意圖如下：

      

2、應用場景       在Server模式下，ParNew收集器是一個非常重要的收集器，因為除Serial外，目前只有它能與CMS收集器配合作業；       但在單個CPU環境中，不會比Serail收集器有更好的效果，因為存在執行緒互動開銷， 3、設定引數       "-XX:+UseConcMarkSweepGC"：指定使用CMS后，會默認使用ParNew作為新生代收集器；       "-XX:+UseParNewGC"：強制指定使用ParNew；           "-XX:ParallelGCThreads"：指定垃圾收集的執行緒數量，ParNew默認開啟的收集執行緒與CPU的數量相同； 4、為什么只有ParNew能與CMS收集器配合       CMS是HotSpot在JDK1.5推出的第一款真正意義上的并發（Concurrent）收集器，第一次實作了讓垃圾收集執行緒與用戶執行緒（基本上）同時作業；       CMS作為老年代收集器，但卻無法與JDK1.4已經存在的新生代收集器Parallel Scavenge配合作業；       因為Parallel Scavenge（以及G1）都沒有使用傳統的GC收集器代碼框架，而另外獨立實作；而其余幾種收集器則共用了部分的框架代碼；       關于CMS收集器后面會詳細介紹，

4、Parallel Scavenge收集器

      Parallel Scavenge垃圾收集器因為與吞吐量關系密切，也稱為吞吐量收集器（Throughput Collector）， 1、特點

（A）、有一些特點與ParNew收集器相似       新生代收集器；       采用復制演算法；       多執行緒收集； （B）、主要特點是：它的關注點與其他收集器不同       CMS等收集器的關注點是盡可能地縮短垃圾收集時用戶執行緒的停頓時間；       而Parallel Scavenge收集器的目標則是達一個可控制的吞吐量（Throughput）；       關于吞吐量與收集器關注點說明詳見本節后面；

2、應用場景       高吞吐量為目標，即減少垃圾收集時間，讓用戶代碼獲得更長的運行時間；       當應用程式運行在具有多個CPU上，對暫停時間沒有特別高的要求時，即程式主要在后臺進行計算，而不需要與用戶進行太多互動；       例如，那些執行批量處理、訂單處理、工資支付、科學計算的應用程式； 3、設定引數       Parallel Scavenge收集器提供兩個引數用于精確控制吞吐量：

（A）、"-XX:MaxGCPauseMillis"       控制最大垃圾收集停頓時間，大于0的毫秒數；       MaxGCPauseMillis設定得稍小，停頓時間可能會縮短，但也可能會使得吞吐量下降；       因為可能導致垃圾收集發生得更頻繁； （B）、"-XX:GCTimeRatio"       設定垃圾收集時間占總時間的比率，0<n<100的整數；       GCTimeRatio相當于設定吞吐量大小；       垃圾收集執行時間占應用程式執行時間的比例的計算方法是：

      1 / (1 + n)       例如，選項-XX:GCTimeRatio=19，設定了垃圾收集時間占總時間的5%--1/(1+19)；

      默認值是1%--1/(1+99)，即n=99；

垃圾收集所花費的時間是年輕一代和老年代收集的總時間； 如果沒有滿足吞吐量目標，則增加代的記憶體大小以盡量增加用戶程式運行的時間；

      此外，還有一個值得關注的引數：

（C）、"-XX:+UseAdptiveSizePolicy"       開啟這個引數后，就不用手工指定一些細節引數，如：

      新生代的大小（-Xmn）、Eden與Survivor區的比例（-XX:SurvivorRation）、晉升老年代的物件年齡（-XX:PretenureSizeThreshold）等；

      JVM會根據當前系統運行情況收集性能監控資訊，動態調整這些引數，以提供最合適的停頓時間或最大的吞吐量，這種調節方式稱為GC自適應的調節策略（GC Ergonomiscs）；    

      這是一種值得推薦的方式：

      (1)、只需設定好記憶體資料大小（如"-Xmx"設定最大堆）；       (2)、然后使用"-XX:MaxGCPauseMillis"或"-XX:GCTimeRatio"給JVM設定一個優化目標；       (3)、那些具體細節引數的調節就由JVM自適應完成；        

      這也是Parallel Scavenge收集器與ParNew收集器一個重要區別；    

      更多目標調優和GC自適應的調節策略說明請參考：            

      《Memory Management in the Java HotSpot? Virtual Machine》 5節 Ergonomics -- Automatic Selections and Behavior Tuning：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf       《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》 第2節 Ergonomics：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/ergonomics.html#ergonomics

4、吞吐量與收集器關注點說明

（A）、吞吐量（Throughput）       CPU用于運行用戶代碼的時間與CPU總消耗時間的比值；       即吞吐量=運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間）；           高吞吐量即減少垃圾收集時間，讓用戶代碼獲得更長的運行時間； （B）、垃圾收集器期望的目標（關注點）

（1）、停頓時間           停頓時間越短就適合需要與用戶互動的程式；       良好的回應速度能提升用戶體驗； （2）、吞吐量       高吞吐量則可以高效率地利用CPU時間，盡快完成運算的任務；       主要適合在后臺計算而不需要太多互動的任務； （3）、覆寫區（Footprint）       在達到前面兩個目標的情況下，盡量減少堆的記憶體空間；       可以獲得更好的空間區域性；

更多Parallel Scavenge收集器的資訊請參考：       官方的垃圾收集調優指南 第6節：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html#parallel_collector   上面介紹的都是新生代收集器，接下來開始介紹老年代收集器；

5、Serial Old收集器

      Serial Old是 Serial收集器的老年代版本； 1、特點       針對老年代；       采用"標記-整理"演算法（還有壓縮，Mark-Sweep-Compact）；       單執行緒收集；       Serial/Serial Old收集器運行示意圖如下：

      

2、應用場景       主要用于Client模式；       而在Server模式有兩大用途：

      （A）、在JDK1.5及之前，與Parallel Scavenge收集器搭配使用（JDK1.6有Parallel Old收集器可搭配）；       （B）、作為CMS收集器的后備預案，在并發收集發生Concurrent Mode Failure時使用（后面詳解）；

更多Serial Old收集器資訊請參考：       記憶體管理白皮書 4.3.2節：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf

6、Parallel Old收集器

      Parallel Old垃圾收集器是Parallel Scavenge收集器的老年代版本；       JDK1.6中才開始提供； 1、特點       針對老年代；       采用"標記-整理"演算法；       多執行緒收集；       Parallel Scavenge/Parallel Old收集器運行示意圖如下：

       

2、應用場景       JDK1.6及之后用來代替老年代的Serial Old收集器；       特別是在Server模式，多CPU的情況下；       這樣在注重吞吐量以及CPU資源敏感的場景，就有了Parallel Scavenge加Parallel Old收集器的"給力"應用組合； 3、設定引數       "-XX:+UseParallelOldGC"：指定使用Parallel Old收集器； 更多Parallel Old收集器收集程序介紹請參考：       《記憶體管理白皮書》 4.5.2節：        http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf

7、CMS收集器

      并發標記清理（Concurrent Mark Sweep，CMS）收集器也稱為并發低停頓收集器（Concurrent Low Pause Collector）或低延遲（low-latency）垃圾收集器；       在前面ParNew收集器曾簡單介紹過其特點； 1、特點       針對老年代；       基于"標記-清除"演算法(不進行壓縮操作，產生記憶體碎片)；                   以獲取最短回收停頓時間為目標；       并發收集、低停頓；       需要更多的記憶體（看后面的缺點）；                    是HotSpot在JDK1.5推出的第一款真正意義上的并發（Concurrent）收集器；       第一次實作了讓垃圾收集執行緒與用戶執行緒（基本上）同時作業； 2、應用場景       與用戶互動較多的場景；               希望系統停頓時間最短，注重服務的回應速度；       以給用戶帶來較好的體驗；       如常見WEB、B/S系統的服務器上的應用；

3、設定引數       "-XX:+UseConcMarkSweepGC"：指定使用CMS收集器； 4、CMS收集器運作程序       比前面幾種收集器更復雜，可以分為4個步驟:

（A）、初始標記（CMS initial mark）       僅標記一下GC Roots能直接關聯到的物件；       速度很快；       但需要"Stop The World"； （B）、并發標記（CMS concurrent mark）       進行GC Roots Tracing的程序；       剛才產生的集合中標記出存活物件；       應用程式也在運行；       并不能保證可以標記出所有的存活物件； （C）、重新標記（CMS remark）       為了修正并發標記期間因用戶程式繼續運作而導致標記變動的那一部分物件的標記記錄；       需要"Stop The World"，且停頓時間比初始標記稍長，但遠比并發標記短；       采用多執行緒并行執行來提升效率； （D）、并發清除（CMS concurrent sweep）       回收所有的垃圾物件；

      整個程序中耗時最長的并發標記和并發清除都可以與用戶執行緒一起作業；       所以總體上說，CMS收集器的記憶體回收程序與用戶執行緒一起并發執行；       CMS收集器運行示意圖如下：

                  5、CMS收集器3個明顯的缺點                      （A）、對CPU資源非常敏感

      并發收集雖然不會暫停用戶執行緒，但因為占用一部分CPU資源，還是會導致應用程式變慢，總吞吐量降低，       CMS的默認收集執行緒數量是=(CPU數量+3)/4；       當CPU數量多于4個，收集執行緒占用的CPU資源多于25%，對用戶程式影響可能較大；不足4個時，影響更大，可能無法接受，         增量式并發收集器：

      針對這種情況，曾出現了"增量式并發收集器"（Incremental Concurrent Mark Sweep/i-CMS）；       類似使用搶占式來模擬多任務機制的思想，讓收集執行緒和用戶執行緒交替運行，減少收集執行緒運行時間；       但效果并不理想，JDK1.6后就官方不再提倡用戶使用， 更多請參考：       官方的《垃圾收集調優指南》8.8節 Incremental Mode：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#CJAGIIEJ       《記憶體管理白皮書》 4.6.3節可以看到一些描述；

（B）、無法處理浮動垃圾,可能出現"Concurrent Mode Failure"失敗

（1）、浮動垃圾（Floating Garbage）       在并發清除時，用戶執行緒新產生的垃圾，稱為浮動垃圾；       這使得并發清除時需要預留一定的記憶體空間，不能像其他收集器在老年代幾乎填滿再進行收集；       也要可以認為CMS所需要的空間比其他垃圾收集器大；       "-XX:CMSInitiatingOccupancyFraction"：設定CMS預留記憶體空間；       JDK1.5默認值為68%；       JDK1.6變為大約92%；               

（2）、"Concurrent Mode Failure"失敗       如果CMS預留記憶體空間無法滿足程式需要，就會出現一次"Concurrent Mode Failure"失敗；       這時JVM啟用后備預案：臨時啟用Serail Old收集器，而導致另一次Full GC的產生；       這樣的代價是很大的，所以CMSInitiatingOccupancyFraction不能設定得太大，

（C）、產生大量記憶體碎片       由于CMS基于"標記-清除"演算法，清除后不進行壓縮操作；       前面《Java虛擬機垃圾回收(二) 垃圾回收演算法》"標記-清除"演算法介紹時曾說過：

      產生大量不連續的記憶體碎片會導致分配大記憶體物件時，無法找到足夠的連續記憶體，從而需要提前觸發另一次Full GC動作，

      解決方法：                

（1）、"-XX:+UseCMSCompactAtFullCollection"       使得CMS出現上面這種情況時不進行Full GC，而開啟記憶體碎片的合并整理程序；       但合并整理程序無法并發，停頓時間會變長；       默認開啟（但不會進行，結合下面的CMSFullGCsBeforeCompaction）； （2）、"-XX:+CMSFullGCsBeforeCompaction"       設定執行多少次不壓縮的Full GC后，來一次壓縮整理；       為減少合并整理程序的停頓時間；       默認為0，也就是說每次都執行Full GC，不會進行壓縮整理；

      由于空間不再連續，CMS需要使用可用"空閑串列"記憶體分配方式，這比簡單實用"碰撞指標"分配記憶體消耗大；       更多關于記憶體分配方式請參考：《Java物件在Java虛擬機中的創建程序》

      總體來看，與Parallel Old垃圾收集器相比，CMS減少了執行老年代垃圾收集時應用暫停的時間；       但卻增加了新生代垃圾收集時應用暫停的時間、降低了吞吐量而且需要占用更大的堆空間；

更多CMS收集器資訊請參考：       《垃圾收集調優指南》 8節 Concurrent Mark Sweep (CMS) Collector：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector       《記憶體管理白皮書》 4.6節 Concurrent Mark-Sweep (CMS) Collector：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf

8、G1收集器

      G1（Garbage-First）是JDK7-u4才推出商用的收集器； 1、特點

（A）、并行與并發       能充分利用多CPU、多核環境下的硬體優勢；       可以并行來縮短"Stop The World"停頓時間；       也可以并發讓垃圾收集與用戶程式同時進行； （B）、分代收集，收集范圍包括新生代和老年代           能獨立管理整個GC堆（新生代和老年代），而不需要與其他收集器搭配；       能夠采用不同方式處理不同時期的物件；                        雖然保留分代概念，但Java堆的記憶體布局有很大差別；       將整個堆劃分為多個大小相等的獨立區域（Region）；       新生代和老年代不再是物理隔離，它們都是一部分Region（不需要連續）的集合；       更多G1記憶體布局資訊請參考：

      《垃圾收集調優指南》 9節：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection

（C）、結合多種垃圾收集演算法，空間整合，不產生碎片       從整體看，是基于標記-整理演算法；       從區域（兩個Region間）看，是基于復制演算法；       這是一種類似火車演算法的實作；         都不會產生記憶體碎片，有利于長時間運行； （D）、可預測的停頓：低停頓的同時實作高吞吐量       G1除了追求低停頓處，還能建立可預測的停頓時間模型；       可以明確指定M毫秒時間片內，垃圾收集消耗的時間不超過N毫秒；

2、應用場景       面向服務端應用，針對具有大記憶體、多處理器的機器；       最主要的應用是為需要低GC延遲，并具有大堆的應用程式提供解決方案；       如：在堆大小約6GB或更大時，可預測的暫停時間可以低于0.5秒；                    用來替換掉JDK1.5中的CMS收集器；       在下面的情況時，使用G1可能比CMS好：

      （1）、超過50％的Java堆被活動資料占用；       （2）、物件分配頻率或年代提升頻率變化很大；       （3）、GC停頓時間過長（長于0.5至1秒），

      是否一定采用G1呢？也未必：

      如果現在采用的收集器沒有出現問題，不用急著去選擇G1；       如果應用程式追求低停頓，可以嘗試選擇G1；       是否代替CMS需要實際場景測驗才知道，

3、設定引數       "-XX:+UseG1GC"：指定使用G1收集器；       "-XX:InitiatingHeapOccupancyPercent"：當整個Java堆的占用率達到引數值時，開始并發標記階段；默認為45；       "-XX:MaxGCPauseMillis"：為G1設定暫停時間目標，默認值為200毫秒；       "-XX:G1HeapRegionSize"：設定每個Region大小，范圍1MB到32MB；目標是在最小Java堆時可以擁有約2048個Region；       更多關于G1引數設定請參考：

      《垃圾收集調優指南》 10.5節：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#important_defaults

4、為什么G1收集器可以實作可預測的停頓       G1可以建立可預測的停頓時間模型，是因為：

      可以有計劃地避免在Java堆的進行全區域的垃圾收集；       G1跟蹤各個Region獲得其收集價值大小，在后臺維護一個優先串列；       每次根據允許的收集時間，優先回收價值最大的Region（名稱Garbage-First的由來）；       這就保證了在有限的時間內可以獲取盡可能高的收集效率；

5、一個物件被不同區域參考的問題       一個Region不可能是孤立的，一個Region中的物件可能被其他任意Region中物件參考，判斷物件存活時，是否需要掃描整個Java堆才能保證準確？       在其他的分代收集器，也存在這樣的問題（而G1更突出）：

      回收新生代也不得不同時掃描老年代？

      這樣的話會降低Minor GC的效率；       解決方法：

      無論G1還是其他分代收集器，JVM都是使用Remembered Set來避免全域掃描：

      每個Region都有一個對應的Remembered Set；       每次Reference型別資料寫操作時，都會產生一個Write Barrier暫時中斷操作；       然后檢查將要寫入的參考指向的物件是否和該Reference型別資料在不同的Region（其他收集器：檢查老年代物件是否參考了新生代物件）；       如果不同，通過CardTable把相關參考資訊記錄到參考指向物件的所在Region對應的Remembered Set中；                     

      當進行垃圾收集時，在GC根節點的列舉范圍加入Remembered Set；       就可以保證不進行全域掃描，也不會有遺漏，

6、G1收集器運作程序       不計算維護Remembered Set的操作，可以分為4個步驟（與CMS較為相似），

（A）、初始標記（Initial Marking）       僅標記一下GC Roots能直接關聯到的物件；       且修改TAMS（Next Top at Mark Start）,讓下一階段并發運行時，用戶程式能在正確可用的Region中創建新物件；       需要"Stop The World"，但速度很快； （B）、并發標記（Concurrent Marking）       進行GC Roots Tracing的程序；       剛才產生的集合中標記出存活物件；       耗時較長，但應用程式也在運行；       并不能保證可以標記出所有的存活物件； （C）、最終標記（Final Marking）       為了修正并發標記期間因用戶程式繼續運作而導致標記變動的那一部分物件的標記記錄；       上一階段物件的變化記錄在執行緒的Remembered Set Log；       這里把Remembered Set Log合并到Remembered Set中；                            需要"Stop The World"，且停頓時間比初始標記稍長，但遠比并發標記短；       采用多執行緒并行執行來提升效率； （D）、篩選回收（Live Data Counting and Evacuation）       首先排序各個Region的回收價值和成本；       然后根據用戶期望的GC停頓時間來制定回收計劃；       最后按計劃回收一些價值高的Region中垃圾物件；                            回收時采用"復制"演算法，從一個或多個Region復制存活物件到堆上的另一個空的Region，并且在此程序中壓縮和釋放記憶體；       可以并發進行，降低停頓時間，并增加吞吐量；

      G1收集器運行示意圖如下：

        更多G1收集器資訊請參考：       《垃圾收集調優指南》 9節 Garbage-First Garbage Collector：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection       《垃圾收集調優指南》 10節 Garbage-First Garbage Collector Tuning：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#g1_gc_tuning  

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/174419.html

標籤：其他

上一篇：0.96寸OLED顯示屏驅動手冊（SSD1306）

下一篇：無所不能的Embedding1 - Word2vec模型詳解&代碼實作