-
Notifications
You must be signed in to change notification settings - Fork 436
/
control-flows-more.html
681 lines (536 loc) · 22.9 KB
/
control-flows-more.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
<h1>协程、延迟函数调用、以及恐慌和恢复</h1>
<p>
此篇文章将介绍协程和延迟函数调用。协程和延迟函数调用是Go中比较独特的两个特性。
恐慌和恢复也将在此篇文章中得到简单介绍。本文并非全面地对这些特性进行介绍,后面的其它文章会陆续补全本文的未介绍的内容。
</p>
<a class="anchor" id="goroutine"></a>
<h3>协程(goroutine)</h3>
<div>
<p>
现代CPU一般含有多个核,并且一个核可能支持多线程。换句话说,现代CPU可以同时执行多条指令流水线。
为了将CPU的能力发挥到极致,我们常常需要使我们的程序支持并发(concurrent)计算。
</p>
<p>
并发计算是指若干计算可能在某些时间片段内同时运行的情形。
下面这两张图描绘了两种并发计算的场景。在此图中,A和B表示两个计算。
在第一种情形中,两个计算只在某些时间片段同时运行。
第二种情形称为并行(parallel)计算。在并行计算中,多个计算在任何时间点都在同时运行。并行计算属于特殊的并发计算。
<div class="text-center">
<img src="res/concurrent-vs-parallel.png" alt="并发和并行"></img>
</div>
</p>
<p>
并发计算可能发生在同一个程序中、同一台电脑上、或者同一个网络中。
在《Go语言101》中,我们只谈及发生在同一个程序中的并发计算。
在Go编程中,协程是创建计算的唯一途径。
</p>
<p>
协程有时也被称为绿色线程。绿色线程是由程序的运行时(runtime)维护的线程。一个绿色线程的开销(比如内存消耗和情景转换)比一个系统线程常常小得多。
只要内存充足,一个程序可以轻松支持上万个并发协程。
</p>
<p>
Go不支持创建系统线程,所以协程是一个Go程序内部唯一的并发实现方式。
</p>
<p>
每个Go程序启动的时候只有一个对用户可见的协程,我们称之为主协程。
一个协程可以开启更多其它新的协程。在Go中,开启一个新的协程是非常简单的。
我们只需在一个函数调用之前使用一个<code>go</code>关键字,即可让此函数调用运行在一个新的协程之中。
当此函数调用退出后,这个新的协程也随之结束了。我们可以称此函数调用为一个协程调用(或者为此协程的启动调用)。
一个协程调用的所有返回值(如果存在的话)必须被全被舍弃。
</p>
在下面的例子程序中,主协程创建了两个新的协程。在此例中,<code>time.Duration</code>是一个在<code>time</code>标准库包中定义的类型。
此类型的底层类型为内置类型<code>int64</code>。
底层类型这个概念将在<a href="type-system-overview.html#underlying-type">下一篇文章</a>中介绍。
<pre class="line-numbers"><code class="language-go">package main
import (
"log"
"math/rand"
"time"
)
func SayGreetings(greeting string, times int) {
for i := 0; i < times; i++ {
log.Println(greeting)
d := time.Second * time.Duration(rand.Intn(5)) / 2
time.Sleep(d) // 睡眠片刻(随机0到2.5秒)
}
}
func main() {
rand.Seed(time.Now().UnixNano())
log.SetFlags(0)
go SayGreetings("hi!", 10)
go SayGreetings("hello!", 10)
time.Sleep(2 * time.Second)
}
</code></pre>
非常简单!我们编写了一个并发程序!
此程序在运行的时候在某一时刻将很可能会有三个协程并存。
运行之,可能会得到如下的结果(也可能是其它结果):
<pre class="output"><code>hi!
hello!
hello!
hello!
hello!
hi!
</code></pre>
<p>
</p>
<p>
当一个程序的主协程退出后,此程序也就退出了,即使还有一些其它协程在运行。
</p>
<p>
和前面的几篇文章不同,上面的例子程序使用了<code>log</code>标准库而不是<code>fmt</code>标准库中的<code>Println</code>函数。
原因是<code>log</code>标准库中的打印函数是经过了同步处理的(下一节将解释什么是并发同步),而<code>fmt</code>标准库中的打印函数却没有被同步。
如果我们在上例中使用<code>fmt</code>标准库中的<code>Println</code>函数,则不同协程的打印可能会交织在一起。(虽然对此例来说,交织的概率很低。)
</p>
</div>
<a class="anchor" id="synchronization"></a>
<h3>并发同步(concurrency synchronization)</h3>
<div>
不同的并发计算可能共享一些资源,其中共享内存资源最为常见。
在一个并发程序中,常常会发生下面的情形:
<ul>
<li>
在一个计算向一段内存写数据的时候,另一个计算从此内存段读数据,结果导致读出的数据的完整性得不到保证。
</li>
<li>
在一个计算向一段内存写数据的时候,另一个计算也向此段内存写数据,结果导致被写入的数据的完整性得不到保证。
</li>
</ul>
<p>
这些情形被称为数据竞争(data race)。并发编程的一大任务就是要调度不同计算,控制它们对资源的访问时段,以使数据竞争的情况不会发生。
此任务常称为并发同步(或者数据同步)。Go支持几种并发同步技术,这些并发同步技术将在后面的章节中逐一介绍。
</p>
并发编程中的其它任务包括:
<ul>
<li>
决定需要开启多少计算;
</li>
<li>
决定何时开启、阻塞、解除阻塞和结束哪些计算;
</li>
<li>
决定如何在不同的计算中分担工作负载。
</li>
</ul>
<p>
上一节中这个并发程序是有缺陷的。我们本期望每个新创建的协程打印出10条问候语,但是主协程(和程序)在这20条问候语还未都打印出来的时候就退出了。
如何确保主协程在这20条问候语都打印完毕之后才退出呢?我们必须使用某种并发同步技术来达成这一目标。
</p>
<p>
Go支持几种<a href="concurrent-synchronization-overview.html">并发同步技术</a>。
其中, <a href="channel.html">通道</a>是最独特和最常用的。
但是,为了简单起见,这里我们将使用<code>sync</code>标准库包中的<code>WaitGroup</code>来同步上面这个程序中的主协程和两个新创建的协程。
</p>
<code>WaitGroup</code>类型有三个方法(特殊的函数,将在以后的文章中详解):<code>Add</code>、<code>Done</code>和<code>Wait</code>。
此类型将在后面的某篇文章中详细解释,目前我们可以简单地认为:
<ul>
<li>
<code>Add</code>方法用来注册新的需要完成的任务数。
</li>
<li>
<code>Done</code>方法用来通知某个任务已经完成了。
</li>
<li>
一个<code>Wait</code>方法调用将阻塞(等待)到所有任务都已经完成之后才继续执行其后的语句。
</li>
</ul>
示例:
<pre class="line-numbers"><code class="language-go">package main
import (
"log"
"math/rand"
"time"
"sync"
)
var wg sync.WaitGroup
func SayGreetings(greeting string, times int) {
for i := 0; i < times; i++ {
log.Println(greeting)
d := time.Second * time.Duration(rand.Intn(5)) / 2
time.Sleep(d)
}
wg.Done() // 通知当前任务已经完成。
}
func main() {
rand.Seed(time.Now().UnixNano())
log.SetFlags(0)
wg.Add(2) // 注册两个新任务。
go SayGreetings("hi!", 10)
go SayGreetings("hello!", 10)
wg.Wait() // 阻塞在这里,直到所有任务都已完成。
}
</code></pre>
<p>
运行这个修改后的程序,我们将会发现所有的20条问候语都将在程序退出之前打印出来。
</p>
</div>
<a class="anchor" id="states-of-goroutine"></a>
<h3>协程的状态</h3>
<div>
<p>
从上面这个的例子,我们可以看到一个活动中的协程可以处于两个状态:<b>运行状态</b>和<b>阻塞状态</b>。一个协程可以在这两个状态之间切换。
比如上例中的主协程在调用<code>wg.Wait</code>方法的时候,将从运行状态切换到阻塞状态;当两个新协程完成各自的任务后,主协程将从阻塞状态切换回运行状态。
</p>
<p>
下面的图片显示了一个协程的生命周期。
<div class="text-center">
<img src="res/goroutine-states.png" alt="协程状态"></img>
</div>
</p>
<p>
注意,一个处于睡眠中的(通过调用<code>time.Sleep</code>)或者在等待系统调用返回的协程被认为是处于运行状态,而不是阻塞状态。
</p>
<p>
当一个新协程被创建的时候,它将自动进入运行状态,一个协程只能从运行状态而不能从阻塞状态退出。
如果因为某种原因而导致某个协程一直处于阻塞状态,则此协程将永远不会退出。
除了极个别的应用场景,在编程时我们应该尽量避免出现这样的情形。
</p>
<p>
一个处于阻塞状态的协程不会自发结束阻塞状态,它必须被另外一个协程通过某种并发同步方法来被动地结束阻塞状态。
如果一个运行中的程序当前所有的协程都出于阻塞状态,则这些协程将永远阻塞下去,程序将被视为死锁了。
当一个程序死锁后,官方标准编译器的处理是让这个程序崩溃。
</p>
比如下面这个程序将在运行两秒钟后崩溃。
<pre class="line-numbers"><code class="language-go">package main
import (
"sync"
"time"
)
var wg sync.WaitGroup
func main() {
wg.Add(1)
go func() {
time.Sleep(time.Second * 2)
wg.Wait() // 阻塞在此
}()
wg.Wait() // 阻塞在此
}
</code></pre>
它的输出:
<pre class="output"><code>fatal error: all goroutines are asleep - deadlock!
...
</code></pre>
<p>
以后我们将学习到更多可以让一个协程进入到阻塞状态的操作。
</p>
</div>
<h3>协程的调度</h3>
<p>
并非所有处于运行状态的协程都在执行。在任一时刻,只能最多有和逻辑CPU数目一样多的协程在同时执行。
我们可以调用<a href="https://golang.google.cn/pkg/runtime/#NumCPU"><code>runtime.NumCPU</code></a>函数来查询当前程序可利用的逻辑CPU数目。
每个逻辑CPU在同一时刻只能最多执行一个协程。Go运行时(runtime)必须让逻辑CPU频繁地在不同的处于运行状态的协程之间切换,从而每个处于运行状态的协程都有机会得到执行。
这和操作系统执行系统线程的原理是一样的。
</p>
<p>
下面这张图显示了一个协程的更详细的生命周期。在此图中,运行状态被细分成了多个子状态。
一个处于排队子状态的协程等待着进入执行子状态。一个处于执行子状态的协程在被执行一会儿(非常短的时间片)之后将进入排队子状态。
<div class="text-center">
<img src="res/goroutine-schedule.png" alt="协程详细状态"></img>
</div>
</p>
<p>
请注意,为了解释的简单性,在以后其它的《Go语言101》文章中,上图中所示的子状态将不会再提及。
重申一下,睡眠和等待系统调用返回子状态被认为是运行状态,而不是阻塞状态。
</p>
<p>
标准编译器采纳了一种被称为<a href="https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sLKhJYD0Y_kqxDv3I3XMw">M-P-G模型</a>的算法来实现协程调度。
其中,<b>M</b>表示系统线程,<b>P</b>表示逻辑处理器(并非上述的逻辑CPU),<b>G</b>表示协程。
大多数的调度工作是通过逻辑处理器(<b>P</b>)来完成的。
逻辑处理器像一个监工一样通过将不同的处于运行状态协程(<b>G</b>)交给不同的系统线程(<b>M</b>)来执行。
一个协程在同一时刻只能在一个系统线程中执行。一个执行中的协程运行片刻后将自发地脱离让出一个系统线程,从而使得其它处于等待子状态的协程得到执行机会。
</p>
<p>
在运行时刻,我们可以调用<a href="https://golang.google.cn/pkg/runtime/#GOMAXPROCS"><code>runtime.GOMAXPROCS</code></a>函数来获取和设置逻辑处理器的数量。
对于官方标准编译器,在Go 1.5之前,默认初始逻辑处理器的数量为1;自从Go 1.5之后,默认初始逻辑处理器的数量和逻辑CPU的数量一致。
此新的默认设置在大多数情况下是最佳选择。但是对于某些文件操作十分频繁的程序,设置一个大于<code>runtime.NumCPU()</code>的<code>GOMAXPROCS</code>值可能是有好处的。
</p>
<p>
我们也可以通过设置<code>GOMAXPROCS</code>环境变量来设置一个Go程序的初始逻辑处理器数量。
</p>
<a class="anchor" id="defer"></a>
<h3>延迟函数调用(deferred function call)</h3>
<div>
<p>
在Go中,一个函数调用可以跟在一个<code>defer</code>关键字后面,形成一个延迟函数调用。
和协程调用类似,被延迟的函数调用的所有返回值必须全部被舍弃。
</p>
<p>
当一个函数调用被延迟后,它不会立即被执行。它将被推入由当前协程维护的一个延迟调用堆栈。
当一个函数调用(可能是也可能不是一个延迟调用)返回并进入它的<a href="function-declarations-and-calls.html#exiting-phase">退出阶段</a>后,所有在此函数调用中已经被推入的延迟调用将被按照它们被推入堆栈的顺序逆序执行。
当所有这些延迟调用执行完毕后,此函数调用也就真正退出了。
</p>
下面这个例子展示了如何使用延迟调用函数。
<pre class="line-numbers"><code class="language-go">package main
import "fmt"
func main() {
defer fmt.Println("The third line.")
defer fmt.Println("The second line.")
fmt.Println("The first line.")
}
</code></pre>
输出结果:
<pre class="output"><code>The first line.
The second line.
The third line.
</code></pre>
<p>
</p>
事实上,每个协程维护着两个调用堆栈。
<ul>
<li>
一个是正常的函数调用堆栈。在此堆栈中,相邻的两个调用存在着调用关系。晚进入堆栈的调用被早进入堆栈的调用所调用。
此堆栈中最早被推入的调用是对应协程的启动调用。
</li>
<li>
另一个堆栈是上面提到的延迟调用堆栈。处于延迟调用堆栈中的任意两个调用之间不存在调用关系。
</li>
</ul>
下面是另一个略微复杂一点的使用了延迟调用的例子程序。此程序将按照自然数的顺序打印出0到9十个数字。
<pre class="line-numbers"><code class="language-go">package main
import "fmt"
func main() {
defer fmt.Println("9")
fmt.Println("0")
defer fmt.Println("8")
fmt.Println("1")
if false {
defer fmt.Println("not reachable")
}
defer func() {
defer fmt.Println("7")
fmt.Println("3")
defer func() {
fmt.Println("5")
fmt.Println("6")
}()
fmt.Println("4")
}()
fmt.Println("2")
return
defer fmt.Println("not reachable")
}
</code></pre>
<p>
</p>
</div>
<a class="anchor" id="defer-modify-results"></a>
<h3>一个延迟调用可以修改包含此延迟调用的最内层函数的返回值</h3>
<div>
一个例子:
<pre class="line-numbers"><code class="language-go">package main
import "fmt"
func Triple(n int) (r int) {
defer func() {
r += n // 修改返回值
}()
return n + n // <=> r = n + n; return
}
func main() {
fmt.Println(Triple(5)) // 15
}
</code></pre>
</div>
<h3>延迟函数调用的必要性和好处</h3>
<p>
事实上,上面的几个使用了延迟函数调用的例子中的延迟函数调用并非绝对必要。
但是延迟调用对于下面将要介绍的恐慌/恢复特性是必要的。
</p>
<p>
另外延迟函数调用可以帮助我们写出更整洁和更鲁棒的代码。我们可以在后面的<a href="defer-more.html">更多关于延迟调用</a>一文中读到这样的例子。
</p>
<a class="anchor" id="argument-evaluation-moment"></a>
<h3>协程和延迟调用的实参的估值时刻</h3>
<div>
一个协程调用或者延迟调用的实参是在此调用发生时被估值的。更具体地说,
<ul>
<li>
对于一个延迟函数调用,它的实参是在此调用被推入延迟调用堆栈的时候被估值的。
</li>
<li>
对于一个协程调用,它的实参是在此协程被创建的时候估值的。
</li>
</ul>
<p>
一个匿名函数体内的表达式是在此函数被执行的时候才会被逐个估值的,不管此函数是被普通调用还是延迟/协程调用。
</p>
一个例子:
<pre class="line-numbers"><code class="language-go">package main
import "fmt"
func main() {
func() {
for i := 0; i < 3; i++ {
defer fmt.Println("a:", i)
}
}()
fmt.Println()
func() {
for i := 0; i < 3; i++ {
defer func() {
fmt.Println("b:", i)
}()
}
}()
}
</code></pre>
运行之,将得到如下结果:
<pre class="output"><code>a: 2
a: 1
a: 0
b: 3
b: 3
b: 3
</code></pre>
<p>
第一个匿名函数中的循环打印出<code>2</code>、<code>1</code>和<code>0</code>这个序列,但是第二个匿名函数中的循环打印出三个<code>3</code>。
因为第一个循环中的<code>i</code>是在<code>fmt.Println</code>函数调用被推入延迟调用堆栈的时候估的值,而第二个循环中的<code>i</code>是在第二个匿名函数调用的退出阶段估的值(此时循环变量<code>i</code>的值已经变为<code>3</code>)。
</p>
我们可以对第二个循环略加修改(使用两种方法),使得它和第一个循环打印出相同的结果。
<pre class="line-numbers"><code class="language-go"> for i := 0; i < 3; i++ {
defer func(i int) {
// 此i为形参i,非实参循环变量i。
fmt.Println("b:", i)
}(i)
}
</code></pre>
或者
<pre class="line-numbers"><code class="language-go"> for i := 0; i < 3; i++ {
i := i // 在下面的调用中,左i遮挡了右i。
// <=> var i = i
defer func() {
// 此i为上面的左i,非循环变量i。
fmt.Println("b:", i)
}()
}
</code></pre>
<p>
</p>
同样的估值时刻规则也适用于协程调用。下面这个例子程序将打印出<code>123 789</code>。
<pre class="line-numbers"><code class="language-go">package main
import "fmt"
import "time"
func main() {
var a = 123
go func(x int) {
time.Sleep(time.Second)
fmt.Println(x, a) // 123 789
}(a)
a = 789
time.Sleep(2 * time.Second)
}
</code></pre>
<p>
顺便说一句,使用<code>time.Sleep</code>调用来做并发同步不是一个好的方法。
如果上面这个程序运行在一个满负荷运行的电脑上,此程序可能在新启动的协程可能还未得到执行机会的时候就已经退出了。
在正式的项目中,我们应该使用<a href="concurrent-synchronization-overview.html">并发同步技术</a>一文中列出的方法来实现并发同步。
</p>
</div>
<a class="anchor" id="panic-recover"></a>
<h3>恐慌(panic)和恢复(recover)</h3>
<p>
Go不支持异常抛出和捕获,而是推荐使用返回值显式返回错误。
不过,Go支持一套和异常抛出/捕获类似的机制。此机制称为恐慌/恢复(panic/recover)机制。
</p>
<p>
我们可以调用内置函数<code>panic</code>来产生一个恐慌以使当前协程进入恐慌状况。
</p>
<p>
进入恐慌状况是另一种使当前函数调用开始返回的途径。
一旦一个函数调用产生一个恐慌,此函数调用将立即进入它的退出阶段,在此函数调用中被推入堆栈的延迟调用将按照它们被推入的顺序逆序执行。
</p>
<p>
通过在一个延迟函数调用之中调用内置函数<code>recover</code>,当前协程中的一个恐慌可以被消除,从而使得当前协程重新进入正常状况。
</p>
<p>
在一个处于恐慌状况的协程退出之前,其中的恐慌不会蔓延到其它协程。
如果一个协程在恐慌状况下退出,它将使整个程序崩溃。
</p>
内置函数<code>panic</code>和<code>recover</code>的声明原型如下:
<pre class="line-numbers"><code class="language-go">func panic(v interface{})
func recover() interface{}
</code></pre>
<p>
接口(interface)类型和接口值将在以后的文章<a href="interface.html">接口</a>中详解。
目前,我们可以暂时将空接口类型<code>interface{}</code>视为很多其它语言中的<code>any</code>或者<code>Object</code>类型。
换句话说,在一个<code>panic</code>函数调用中,我们可以传任何实参值。
</p>
<p>
一个<code>recover</code>函数的返回值为其所恢复的恐慌在产生时被一个<code>panic</code>函数调用所消费的参数。
</p>
下面这个例子展示了如何产生一个恐慌和如何消除一个恐慌。
<pre class="line-numbers"><code class="language-go">package main
import "fmt"
func main() {
defer func() {
fmt.Println("正常退出")
}()
fmt.Println("嗨!")
defer func() {
v := recover()
fmt.Println("恐慌被恢复了:", v)
}()
panic("拜拜!") // 产生一个恐慌
fmt.Println("执行不到这里")
}
</code></pre>
它的输出结果:
<pre class="output"><code>嗨!
恐慌被恢复了: 拜拜!
正常退出
</code></pre>
<p>
</p>
下面的例子在一个新协程里面产生了一个恐慌,并且此协程在恐慌状况下退出,所以整个程序崩溃了。
<pre class="line-numbers"><code class="language-go">package main
import (
"fmt"
"time"
)
func main() {
fmt.Println("hi!")
go func() {
time.Sleep(time.Second)
panic(123)
}()
for {
time.Sleep(time.Second)
}
}
</code></pre>
运行之,输出如下:
<pre class="output"><code>hi!
panic: 123
goroutine 5 [running]:
...
</code></pre>
<p>
</p>
Go运行时(runtime)会在若干情形下产生恐慌,比如一个整数被0除的时候。下面这个程序将崩溃退出。
<pre class="line-numbers"><code class="language-go">package main
func main() {
a, b := 1, 0
_ = a/b
}
</code></pre>
它的输出:
<pre class="output"><code>panic: runtime error: integer divide by zero
goroutine 1 [running]:
...
</code></pre>
<p>
</p>
<p>
一般说来,恐慌用来表示正常情况下不应该发生的逻辑错误。
如果这样的一个错误在运行时刻发生了,则它肯定是由于某个bug引起的。
另一方面,非逻辑错误是现实中难以避免的错误,它们不应该导致恐慌。
我们必须正确地对待和处理非逻辑错误。
</p>
<p>
更多可能由Go运行时产生的恐慌将在以后其它文章中提及。
</p>
<p>
以后,我们可以了解<a href="panic-and-recover-use-cases.html">一些恐慌/恢复用例</a>和<a href="panic-and-recover-more.html">更多关于恐慌/恢复机制的细节</a>。
</p>
<h3>一些致命性错误不属于恐慌</h3>
<p>
对于官方标准编译器来说,很多致命性错误(比如堆栈溢出和内存不足)不能被恢复。它们一旦产生,程序将崩溃。
</p>