GC算法精解（五分鍾讓你徹底明白標記/清除算法）
相信不少猿友看到標題就認為LZ是標題黨了，不過既然您已經被LZ忽悠進來了，那就好好的享受一頓算法大餐吧。不過LZ丑話說前面哦，這篇文章應該能讓各位徹底理解標記/清除算法，不過倘若各位猿友不能在五分鍾內看完，那就不是LZ的錯啦。
好了，前面只是小小開個玩笑，讓各位猿友放松下心情。下面即將與各位分享的，是GC算法中最基礎的算法------標記/清除算法。如果搞清楚這個算法，那么后面兩個就完全是小菜一碟了。
首先，我們回想一下上一章提到的根搜索算法，它可以解決我們應該回收哪些對象的問題，但是它顯然還不能承擔垃圾搜集的重任，因為我們在程序（程序也就是指我們運行在JVM上的JAVA程序）運行期間如果想進行垃圾回收，就必須讓GC線程與程序當中的線程互相配合，才能在不影響程序運行的前提下，順利的將垃圾進行回收。
為了達到這個目的，標記/清除算法就應運而生了。它的做法是當堆中的有效內存空間（available memory）被耗盡的時候，就會停止整個程序（也被成為stop the world），然后進行兩項工作，第一項則是標記，第二項則是清除。
下面LZ具體解釋一下標記和清除分別都會做些什么。
標記：標記的過程其實就是，遍歷所有的GC Roots，然后將所有GC Roots可達的對象標記為存活的對象。
清除：清除的過程將遍歷堆中所有的對象，將沒有標記的對象全部清除掉。
其實這兩個步驟並不是特別復雜，也很容易理解。LZ用通俗的話解釋一下標記/清除算法，就是當程序運行期間，若可以使用的內存被耗盡的時候，GC線程就會被觸發並將程序暫停，隨后將依舊存活的對象標記一遍，最終再將堆中所有沒被標記的對象全部清除掉，接下來便讓程序恢復運行。
下面LZ給各位制作了一組描述上面過程的圖片，結合着圖片，我們來直觀的看下這一過程，首先是第一張圖。
這張圖代表的是程序運行期間所有對象的狀態，它們的標志位全部是0（也就是未標記，以下默認0就是未標記，1為已標記），假設這會兒有效內存空間耗盡了，JVM將會停止應用程序的運行並開啟GC線程，然后開始進行標記工作，按照根搜索算法，標記完以后，對象的狀態如下圖。
可以看到，按照根搜索算法，所有從root對象可達的對象就被標記為了存活的對象，此時已經完成了第一階段標記。接下來，就要執行第二階段清除了，那么清除完以后，剩下的對象以及對象的狀態如下圖所示。
可以看到，沒有被標記的對象將會回收清除掉，而被標記的對象將會留下，並且會將標記位重新歸0。接下來就不用說了，喚醒停止的程序線程，讓程序繼續運行即可。
其實這一過程並不復雜，甚至可以說非常簡單，各位說對嗎。不過其中有一點值得LZ一提，就是為什么非要停止程序的運行呢？
這個其實也不難理解，LZ舉個最簡單的例子，假設我們的程序與GC線程是一起運行的，各位試想這樣一種場景。
假設我們剛標記完圖中最右邊的那個對象，暫且記為A，結果此時在程序當中又new了一個新對象B，且A對象可以到達B對象。但是由於此時A對象已經標記結束，B對象此時的標記位依然是0，因為它錯過了標記階段。因此當接下來輪到清除階段的時候，新對象B將會被苦逼的清除掉。如此一來，不難想象結果，GC線程將會導致程序無法正常工作。
上面的結果當然令人無法接受，我們剛new了一個對象，結果經過一次GC，忽然變成null了，這還怎么玩？
用戶空間與內核空間，進程上下文與中斷上下文[總結]
到此為止，標記/清除算法LZ已經介紹完了，下面我們來看下它的缺點，其實了解完它的算法原理，它的缺點就很好理解了。
1、首先，它的缺點就是效率比較低（遞歸與全堆對象遍歷），而且在進行GC的時候，需要停止應用程序，這會導致用戶體驗非常差勁，尤其對於交互式的應用程序來說簡直是無法接受。試想一下，如果你玩一個網站，這個網站一個小時就掛五分鍾，你還玩嗎？
2、第二點主要的缺點，則是這種方式清理出來的空閑內存是不連續的，這點不難理解，我們的死亡對象都是隨即的出現在內存的各個角落的，現在把它們清除之后，內存的布局自然會亂七八糟。而為了應付這一點，JVM就不得不維持一個內存的空閑列表，這又是一種開銷。而且在分配數組對象的時候，尋找連續的內存空間會不太好找。
看完它的缺點估計有的猿友要忍不住吐糟了，“這么說這個算法根本沒法用嘛，那LZ還介紹這么個玩意干什么。”
猿友們莫要着急，一個算法有缺點，高人們自然會想盡辦法去完善它的。而接下來我們要介紹的兩種算法，皆是在標記/清除算法的基礎上優化而產生的。具體的內容，下一次LZ再和各位分享。
本次的分享就到此結束了，希望各位看完都能有所收獲，0.0。
1、前言
最近在學習linux內核方面的知識，經常會看到用戶空間與內核空間及進程上下文與中斷上下文。看着很熟悉，半天又說不出到底是怎么回事，有什么區別。看書過程經常被感覺欺騙，似懂非懂的感覺，很是不爽，今天好好結合書和網上的資料總結一下，加深理解。
2、用戶空間與內核空間
我們知道現在操作系統都是采用虛擬存儲器，那么對32位操作系統而言，它的尋址空間（虛擬存儲空間）為4G（2的32次方）。操心系統的核心是內核，獨立於普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。為了保證用戶進程不能直接操作內核，保證內核的安全，操心系統將虛擬空間划分為兩部分，一部分為內核空間，一部分為用戶空間。針對linux操作系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱為內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱為用戶空間。每個進程可以通過系統調用進入內核，因此，Linux內核由系統內的所有進程共享。於是，從具體進程的角度來看，每個進程可以擁有4G字節的虛擬空間。空間分配如下圖所示：
有了用戶空間和內核空間，整個linux內部結構可以分為三部分，從最底層到最上層依次是：硬件-->內核空間-->用戶空間。如下圖所示：
需要注意的細節問題：
（1） 內核空間中存放的是內核代碼和數據，而進程的用戶空間中存放的是用戶程序的代碼和數據。不管是內核空間還是用戶空間，它們都處於虛擬空間中。
（2） Linux使用兩級保護機制：0級供內核使用，3級供用戶程序使用。
內核態與用戶態：
（1）當一個任務（進程）執行系統調用而陷入內核代碼中執行時，稱進程處於內核運行態（內核態）。此時處理器處於特權級最高的（0級）內核代碼中執行。當進程處於內核態時，執行的內核代碼會使用當前進程的內核棧。每個進程都有自己的內核棧。
（2）當進程在執行用戶自己的代碼時，則稱其處於用戶運行態（用戶態）。此時處理器在特權級最低的（3級）用戶代碼中運行。當正在執行用戶程序而突然被中斷程序中斷時，此時用戶程序也可以象征性地稱為處於進程的內核態。因為中斷處理程序將使用當前進程的內核棧。
參考資料：
http://blog.csdn.net/f22jay/article/details/7925531
http://blog.csdn.net/zhangskd/article/details/6956638
http://blog.chinaunix.net/uid-26838492-id-3162146.html
3、進程上下文與中斷上下文
我在看《linux內核設計與實現》這本書的第三章進程管理時候，看到進程上下文。書中說當一個程序執行了系統調用或者觸發某個異常（軟中斷），此時就會陷入內核空間，內核此時代表進程執行，並處於進程上下文中。看后還是沒有弄清楚，什么是進程上下文，如何上google上面狂搜一把，總結如下：
程序在執行過程中通常有用戶態和內核態兩種狀態，CPU對處於內核態根據上下文環境進一步細分，因此有了下面三種狀態：
（1）內核態，運行於進程上下文，內核代表進程運行於內核空間。
（2）內核態，運行於中斷上下文，內核代表硬件運行於內核空間。
（3）用戶態，運行於用戶空間。
上下文context： 上下文簡單說來就是一個環境。
用戶空間的應用程序，通過系統調用，進入內核空間。這個時候用戶空間的進程要傳遞 很多變量、參數的值給內核，內核態運行的時候也要保存用戶進程的一些寄存 器值、變量等。所謂的“進程上下文”，可以看作是用戶進程傳遞給內核的這些參數以及內核要保存的那一整套的變量和寄存器值和當時的環境等。
相對於進程而言，就是進程執行時的環境。具體來說就是各個變量和數據，包括所有的寄存器變量、進程打開的文件、內存信息等。一個進程的上下文可以分為三個部分:用戶級上下文、寄存器上下文以及系統級上下文。
（1）用戶級上下文: 正文、數據、用戶堆棧以及共享存儲區；
（2）寄存器上下文: 通用寄存器、程序寄存器(IP)、處理器狀態寄存器(EFLAGS)、棧指針(ESP)；
（3）系統級上下文: 進程控制塊task_struct、內存管理信息(mm_struct、vm_area_struct、pgd、pte)、內核棧。
當發生進程調度時，進行進程切換就是上下文切換(context switch).操作系統必須對上面提到的全部信息進行切換，新調度的進程才能運行。而系統調用進行的模式切換(mode switch)。模式切換與進程切換比較起來，容易很多，而且節省時間，因為模式切換最主要的任務只是切換進程寄存器上下文的切換。
硬件通過觸發信號，導致內核調用中斷處理程序，進入內核空間。這個過程中，硬件的 一些變量和參數也要傳遞給內核，內核通過這些參數進行中斷處理。所謂的“ 中斷上下文”，其實也可以看作就是硬件傳遞過來的這些參數和內核需要保存的一些其他環境（主要是當前被打斷執行的進程環境）。中斷時，內核不代表任何進程運行，它一般只訪問系統空間，而不會訪問進程空間，內核在中斷上下文中執行時一般不會阻塞。
摘錄Linux注釋的內容如下：
Process Context
-------------------------------------------
One of the most important parts of a process is the executing program code. This code is read in from an executable file and executed within the program's address space. Normal program execution occurs in user-space. When a program executes a system call or triggers an exception, it enters kernel-space. At this point, the kernel is said to be "executing on behalf of the process" and is in process context. When in process context, the current macro is valid[7]. Upon exiting the kernel, the process resumes execution in user-space, unless a higher-priority process has become runnable in the interim(過渡期), in which case the scheduler is invoked to select the higher priority process.
Other than process context there is interrupt context, In interrupt context, the system is not running on behalf of a process, but is executing an interrupt handler. There is no process tied to interrupt handlers and consequently no process context.
System calls and exception handlers are well-defined interfaces into the kernel. A process can begin executing in kernel-space only through one of these interfaces -- all access to the kernel is through these interfaces.
-------------------------------------------
Interrupt Context
-------------------------------------------
When executing an interrupt handler or bottom half, the kernel is in interrupt context. Recall that process context is the mode of operation the kernel is in while it is executing on behalf of a process -- for example, executing a system call or running a kernel thread. In process context, the current macro points to the associated task. Furthermore, because a process is coupled to the kernel in process context(因為進程是以進程上文的形式連接到內核中的), process context can sleep or otherwise invoke the scheduler.
Interrupt context, on the other hand, is not associated with a process. The current macro is not relevant (although it points to the interrupted process). Without a backing process(由於沒有進程的背景),interrupt context cannot sleep -- how would it ever reschedule?(否則怎么再對它重新調度?) Therefore, you cannot call certain functions from interrupt context. If a function sleeps, you cannot use it from your interrupt handler -- this limits the functions that one can call from an interrupt handler.(這是對什么樣的函數可以在中斷處理程序中使用的限制)
Interrupt context is time critical because the interrupt handler interrupts other code. Code should be quick and simple. Busy looping is discouraged. This is a very important point; always keep in mind that your interrupt handler has interrupted other code (possibly even another interrupt handler on a different line!). Because of this asynchronous nature, it is imperative(必須) that all interrupt handlers be as quick and as simple as possible. As much as possible, work should be pushed out from the interrupt handler and performed in a bottom half, which runs at a more convenient time.
The setup of an interrupt handler's stacks is a configuration option. Historically, interrupt handlers did not receive(擁有) their own stacks. Instead, they would share the stack of the process that they interrupted[1]. The kernel stack is two pages in size; typically, that is 8KB on 32-bit architectures and 16KB on 64-bit architectures. Because in this setup interrupt handlers share the stack, they must be exceptionally frugal(必須非常節省) with what data they allocate there. Of course, the kernel stack is limited to begin with, so all kernel code should be cautious.
A process is always running. When nothing else is schedulable, the idle task runs.
-------------------------------------------
LINUX完全注釋中的一段話：
當一個進程在執行時,CPU的所有寄存器中的值、進程的狀態以及堆棧中的內容被稱為該進程的上下文。當內核需要切換到另一個進程時，它需要保存當前進程的所有狀態，即保存當前進程的上下文，以便在再次執行該進程時，能夠必得到切換時的狀態執行下去。在LINUX中，當前進程上下文均保存在進程的任務數據結構中。在發生中斷時,內核就在被中斷進程的上下文中，在內核態下執行中斷服務例程。但同時會保留所有需要用到的資源，以便中繼服務結束時能恢復被中斷進程的執行。
參考資料：
http://www.cnblogs.com/hustcat/articles/1505618.html
http://mprc.pku.edu.cn/~zhengyansong/blog/?p=199
http://blog.chinaunix.net/uid-26980210-id-3235544.html