-
Notifications
You must be signed in to change notification settings - Fork 398
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
luobangkui
committed
Jul 23, 2019
1 parent
ae24348
commit ba29fe9
Showing
4 changed files
with
170 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
### 三色算法 | ||
|
||
go垃圾回收器的操作都是基于**三色算法**,这一章节主要来说明此算法。 | ||
|
||
###### 三色算法并不是go独有的,它也会在其它编程语言中使用到 | ||
|
||
严格来说,在Go中这个算法的官方名称是叫做**三色标记清除算法(tricolor mark-and-sweep algorithm)**。它可以和程序一起并发工作并且使用**写屏障(write barrier)**。这就意味着,当Go程序员运行起来,go调度器去负责应用程序的调度,而垃圾回收器会像调度器处理常规应用程序一样,去使用多个**goroutines**去进行工作。你可以在[第九章](https://github.com/hantmac/Mastering_Go_ZH_CN/blob/master/eBook/chapter9/09.0.md)了解更多关于goroutines以及go调度器的相关内容,包括*Go 并发 - Goroutines,Channels,和管道(Piplines)*。 | ||
|
||
这个算法背后的核心思想是由Edsger W. Dijkstra,Leslie Lamport,A.J.Martin,C.S.Scholten和E.F.M.Steffens这些大佬提出的。算法首先发表在论文*On-the-fly Garbage Collection:An Exercise in Cooperation*上面。三色标记清除算法背后的首要原则就是它把堆中的对象根据它们的颜色分到不同集合里面,颜色是根据算法进行标记的,我会在这一章的*更多关于go垃圾回收*这部分对其算法进行进一步说明。 | ||
|
||
现在让我们来谈谈每种颜色集合代表的含义。**黑色集合**是为了确保没有任何指针指向白色集合。但是**白色集合**中的对象允许有指针指向黑色集合,因为这不会对垃圾回收器的操作产生影响。**灰色集合**可能会有指针指向白色集合里的对象。白色集合中的对象就是垃圾回收的候选对象。 | ||
|
||
注意到没有任何对象可以从黑色集合进到白色集合,这允许算法能够去操作并且清除白色集合里的对象。此外,没有任何黑色集合里的指针对象能够直接指向白色集合中的对象。 | ||
|
||
当垃圾回收开始,全部对象标记为白色,然后垃圾回收器会遍历所有根对象并把它们标记为灰色。**根对象**就是程序能直接访问到的对象,包括全局变量以及栈里面的东西。这些对象大多数取决于特定程序的go代码。在这之后,垃圾回收器选取一个灰色的对象,把它变为黑色,然后开始寻找去确定这个对象是否有指针指向白色集合的对象。这意味着当一个灰色对象由于被其它对象的指针所指而扫描到的时候,这个灰色对象会被标记为黑色。如果扫描发现这个灰色对象有一个或者更多指针指向白色对象时,会把所指向的白色对象放到灰色集合里。只要有灰色集合对象存在,这个过程就会一直进行下去。之后,白色集合里的对象就是没人访问的对象,并且它们所占用的内存可以被回收重用。因此,在这个点上,我们说白色集合里的元素被垃圾回收了。 | ||
|
||
###### *如果垃圾回收过程中,一个灰色对象在某些情况变为不可达状态,它在那次垃圾回收中就不会被回收了,但是不是说下次也不会回收!尽管这不是最佳情况,但也没有那么糟* | ||
|
||
在这个过程中,运行应用程序被叫做**修改器(mutator)**。mutator去运行一个小的方法叫做**写屏障(write barrier),每次堆中的指针被修改写屏障都会去执行。如果堆中对象的指针被修改,就意味着那个对象现在是可触达的,写屏障会把它标记为灰色并把它放到灰色集合中。 | ||
|
||
###### *mutator负责保持黑色集合中没有任何元素的指针去指向白色集合中的元素。这是在写屏障方法的帮助下完成的。如果维持这个不变状态失败的话,会毁坏垃圾回收过程,并且很可能会以一种丑陋和非预期的方式破坏你的程序。* | ||
|
||
|
||
堆可以看成许多连接对象的图,如下所示,展示了单独一个垃圾回收的过程。 | ||
|
||
![image](https://github.com/hantmac/Mastering_Go_ZH_CN/tree/master/images/chapter2/02.3-1.jpg) | ||
|
||
|
||
因此,我们有三种不同颜色:黑色、白色和黑色。当算法开始的时候,所有对象标记为白色。随着算法继续进行,白色对象移到了其它两种颜色集合的一种里面。最后留在白色集合里面的对象会在将来某个时间点被清理掉。 | ||
|
||
在前面的图里,你可以看到白色对象E,它是在白色集合里而且可以访问对象F,E不会被任何其它的对象访问到因为没有其它指向E的指针,这使得E成为了垃圾回收的最佳候选人!另外,对象A、B和C是根对象而且总是可达的,因此它们不会被垃圾回收掉。 | ||
|
||
|
||
接下来,算法会去处理留下的灰色集合元素,这意味着对象A和F会进入到黑色集合里。对象A会进入到黑色集合是因为它是一个根元素,而F会进入黑色集合是因为它没有指向任何其它对象但是是在灰色集合里。在对象A被垃圾回收之后,对象F会变成不可达状态并且会在下一次垃圾回收器的处理循环中被回收掉。 | ||
|
||
go垃圾回收也可以应用于其它变量例如**channel**!当垃圾回收器发现一个channel是不可达的而且channel变量再也不会被访问到,它就会释放掉它的资源甚至说channel还没被关闭!你将会了解更多channels的东西在[第九章](https://github.com/hantmac/Mastering_Go_ZH_CN/blob/master/eBook/chapter9/09.0.md)里,*Go并发 - Groutines,Channel和Pipelines*。 | ||
|
||
|
||
Go允许你通过在你的Go代码里放一个```runtime.GC()```的声明来手动去开启一次垃圾回收。但是,要记住一点,```runtime.GC()```会阻塞调用器,并且它可能会阻塞整个程序,尤其是如果你想运行一个非常繁忙的而且有很多对象的go程序。这种情况发生,主要是因为你不能在其他任何事都在频繁变化的时候去处理垃圾回收,因为这种情况不会给垃圾回收器机会,去清楚地确定白色、黑色和灰色集合里的成员。这种垃圾回收状态也被称作是**垃圾回收安全点(garbage collection safe-point)**。 | ||
|
||
|
||
你可以在https://github.com/golang/go/blob/master/src/runtime/mgc.go里找到垃圾回收器相关的高级go代码。你可以学习这个如果你想了解更多关于垃圾回收操作的东西。 | ||
|
||
###### *go团队一直在优化垃圾回收器,主要是通过降低垃圾回收器所需要处理三种集合上数据的扫描次数来让它更快。但是尽管进行各种优化,其背后算法的整体原理还是一样的。* | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,123 @@ | ||
### 垃圾回收 | ||
|
||
**垃圾回收**是释放掉那些不再被使用的的内存空间的过程。换句话说,垃圾回收器会去检查哪些对象超出范围并且不会再被引用到,然后它会去释放掉那些对象占用的内存空间。这个过程是在go程序运行中以并发的方式去进行的,不是go程序执行之前,也不是go程序执行之后。go垃圾回收器实现的说明文档给出了如下声明(runtime下的mgc.go中): | ||
|
||
*The GC runs concurrently with mutator threads, is type accurate (aka precise), allows multiple | ||
GC thread to run in parallel. It is a concurrent mark and sweep that uses a write barrier. It is non-generational and non-compacting. Allocation is done using size segregated per P allocation areas to minimize fragmentation while eliminating locks in the common case.* | ||
|
||
*垃圾回收是和go线程同时运行的,它是类型精确的,而且多个垃圾回收线程可以并行运行。它是一种使用了写屏障的并发标记清除的垃圾回收方式。它是非分代和非压缩的。使用按P分配区域隔离的大小来完成分配,以最小化碎片,同时消除常见情况下的锁。* | ||
|
||
这里面有很多术语,我一会儿会解释。但是首先,我会为你展示一种查看垃圾回收过程的参数的方式。幸运的是,Go标准库提供了方法,允许你去学习垃圾回收器的操作以及了解更多关于垃圾回收器在背后所做的事情。相关的代码保存在了gColl.go中,它有三个部分。 | ||
|
||
gColl.go的第一部分代码段如下所示: | ||
|
||
``` | ||
package main | ||
import ( | ||
"fmt" | ||
"os" | ||
"runtime" | ||
"runtime/trace" | ||
"time" | ||
) | ||
func printStats(mem runtime.MemStats) { | ||
runtime.ReadMemStats(&mem) | ||
fmt.Println("mem.Alloc:", mem.Alloc) | ||
fmt.Println("mem.TotalAlloc:", mem.TotalAlloc) | ||
fmt.Println("mem.HeapAlloc:", mem.HeapAlloc) | ||
fmt.Println("mem.NumGC:", mem.NumGC) | ||
fmt.Println("-----") | ||
} | ||
``` | ||
|
||
注意到每次你都需要获取更多最近的垃圾回收统计信息,你会需要调用```runtime.ReadMemStats()```方法。```printStats()```方法的目的是去避免每次要写相同代码。 | ||
|
||
|
||
第二部分代码如下: | ||
|
||
``` | ||
func main() { | ||
f, err := os.Create("/tmp/traceFile.out") | ||
if err != nil { | ||
panic(err) | ||
} | ||
defer f.Close() | ||
err = trace.Start(f) | ||
if err != nil { | ||
fmt.Println(err) | ||
return | ||
} | ||
defer trace.Stop() | ||
var mem runtime.MemStats | ||
printStats(mem) | ||
for i := 0; i < 10; i++ { | ||
s := make([]byte, 50000000) | ||
if s == nil { | ||
fmt.Println("Operation failed!") | ||
} | ||
} | ||
printStats(mem) | ||
``` | ||
for循环里创建一堆大的go slices,目的是为了进行大量内存分配来触发垃圾回收。 | ||
|
||
最后一部分是接下来```gColl.go```的代码,用go slices进行了更多的内存分配。 | ||
|
||
``` | ||
for i := 0; i < 10; i++ { | ||
s := make([]byte, 100000000) | ||
if s == nil { | ||
fmt.Println("Operation failed!") | ||
} | ||
time.Sleep(time.Millisecond) | ||
} | ||
printStats(mem) | ||
} | ||
``` | ||
|
||
在macOS High Sierra上面gColl.go的输出如下: | ||
|
||
``` | ||
mem.Alloc: 66024 | ||
mem.TotalAlloc: 66024 | ||
mem.HeapAlloc: 66024 | ||
mem.NumGC: 0 | ||
----- | ||
mem.Alloc: 50078496 | ||
mem.TotalAlloc: 500117056 | ||
mem.HeapAlloc: 50078496 | ||
mem.NumGC: 10 | ||
----- | ||
mem.Alloc: 76712 | ||
mem.TotalAlloc: 1500199904 | ||
mem.HeapAlloc: 76712 | ||
mem.NumGC: 20 | ||
----- | ||
``` | ||
|
||
尽管你不会每次都去检查go垃圾收集器的操作,但是在一个慢的应用程序上可以看到go垃圾回收器的工作方式,长时间的运行里会节省你很多时间。我很确定,花点时间去整体学习了解垃圾回收,尤其是了解go垃圾回收器的工作方式,你不会后悔的。 | ||
|
||
这里有一个技巧可以让你得到更多关于go 垃圾收集器操作的细节,使用下面这个命令。 | ||
|
||
``` | ||
GODEBUG=gctrace=1 go run gColl.go | ||
``` | ||
所以,如果你在任何```go run```命令前面加上```GODEBUG=gctrace=1```,go就会去打印关于垃圾回收操作的一些分析数据。生成的数据是如下的形式: | ||
|
||
``` | ||
gc 4 @0.025s 0%: 0.002+0.65+0.018 ms clock, 0.021+0.040/0.057/0.003+0.14 ms cpu, 47->47->0 MB, 48 MB goal, 8 P | ||
gc 17 @30.103s 0%: 0.004+0.080+0.019ms clock, 0.033+0/0.076/0.071+0.15 ms cpu, 95->95->0 MB, 96 MB goal, 8 P | ||
``` | ||
|
||
这些数据给你提供了更多垃圾回收过程中的堆内存大小的信息。让我们以```47->47->0 MB```这三个值为例。第一个数值是垃圾回收器要去运行时候的堆内存大小。第二个值是垃圾回收器操作结束时候的堆内存大小。最后一个值就是生存堆的大小。 | ||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.