Lecture 02 RPC and Threads.srt

1
00:00:02,500 --> 00:00:08,990
今天我想谈谈go语言，这很有趣，特别有趣
today I'd like to talk about GO which
is interesting especially interesting

2
00:00:08,990 --> 00:00:12,709
在本课程中为我们服务，因为go是你在这个课程所有实验中
for us in this course because course GO
is the language at the labs you're all

3
00:00:12,709 --> 00:00:17,090
要使用的语言，所以我今天要特别关注一些
going to do the labs in and so I want to
focus today particularly on some of the

4
00:00:17,090 --> 00:00:22,940
在实验室中最有用的机械，尤其是对
machinery that sort of most useful in
the labs and in most particular to

5
00:00:22,940 --> 00:00:29,600
分布式编程首​​先，您应该知道为什么我们要使用go 
distributed programming um first of all
you know it's worth asking why we use go

6
00:00:29,600 --> 00:00:33,890
实际上，在本课程中，我们可以使用许多其他系统中的任何一个
in this class in fact we could have used
any one of a number of other system

7
00:00:33,890 --> 00:00:38,210
样式语言诸如Java或C#甚至Python之类的大量语言
style languages plenty languages like
Java or C sharp or even Python that

8
00:00:38,210 --> 00:00:42,859
提供我们需要的那种设施，实际上我们曾经在这里使用C++ 
provide the kind of facilities we need
and indeed we used to use C++ in this

9
00:00:42,859 --> 00:00:49,010
类，效果很好，它的确会像许多其他语言一样
class and it worked out fine it'll go
indeed like many other languages

10
00:00:49,010 --> 00:00:51,649
提供了一堆特别方便的特性
provides a bunch of features which are
particularly convenient

11
00:00:51,649 --> 00:00:56,659
这是对线程以及线程之间的锁定和同步的良好支持
that's good support for threads and
locking and synchronization between

12
00:00:56,659 --> 00:01:01,789
我们经常使用的线程是一个方便的远程过程调用包
threads which we use a lot it is a
convenient remote procedure call package

13
00:01:01,789 --> 00:01:06,380
听起来并不多，但实际上却是一个重要的意义
which doesn't sound like much but it
actually turns out to be a significant

14
00:01:06,380 --> 00:01:11,210
例如C++等语言的约束，实际上很难
constraint from in languages like C++
for example it's actually a bit hard to

15
00:01:11,210 --> 00:01:14,930
找到一个方便易用的远程过程调用程序包，我们当然
find a convenient easy to use remote
procedure call package and of course we

16
00:01:14,930 --> 00:01:18,409
在本课程中始终使用它，或者在程序和不同的机器上交谈
use it all the time in this course or
programs and different machines to talk

17
00:01:18,409 --> 00:01:25,100
与C++彼此不同，go是类型安全和内存安全的，这很难
to each other unlike C++ go is type safe
and memory safe that is it's pretty hard

18
00:01:25,100 --> 00:01:29,180
编写一个程序，该程序由于错误而在某些随机部分上乱涂乱画
to write a program that due to a bug
scribbles over some random piece of

19
00:01:29,180 --> 00:01:34,789
内存，然后使程序执行神秘的操作， 
memory and then causes the program to do
mysterious things and that just

20
00:01:34,789 --> 00:01:39,680
同样消除了一大堆错误，这是垃圾收集，这意味着您
eliminates a big class of bugs similarly
it's garbage collected which means you

21
00:01:39,680 --> 00:01:44,509
永远不会冒着两次重复使用同一内存或仍在使用的可用内存的危险
never in danger of priam the same memory
twice or free memory that's still in use

22
00:01:44,509 --> 00:01:48,859
或其他东西，当它们停止使用时，垃圾矢量只会释放它们
or something the garbage vector just
frees things when they stop being used

23
00:01:48,859 --> 00:01:54,829
一件事可能直到您玩完这件事才变得明显
and one thing it's maybe not obvious
until you played around with just this

24
00:01:54,829 --> 00:01:58,640
之前的那种编程，但是线程和垃圾的结合
kind of programming before but the
combination of threads and garbage

25
00:01:58,640 --> 00:02:03,200
收集尤其重要，这是非
collection is particularly important one
of the things that goes wrong in a non

26
00:02:03,200 --> 00:02:08,899
如果使用线程，则像C ++这样的垃圾收集语言总是
garbage collected language like C++ if
you use threads is that it's always a

27
00:02:08,899 --> 00:02:13,430
有点困惑，需要一堆簿记才能弄清楚何时
bit of a puzzle and requires a bunch of
bookkeeping to figure out when the last

28
00:02:13,430 --> 00:02:15,660
使用共享对象的线程有
thread
that's using a shared object has

29
00:02:15,660 --> 00:02:19,530
完成使用该对象，因为只有这样，您才能在结束时释放该对象
finished using that object because only
then can you free the object as you end

30
00:02:19,530 --> 00:02:22,620
编写大量的外套，就像手动程序员一样
up writing quite a bit of coat it's like
manually the programmer it's about a

31
00:02:22,620 --> 00:02:26,580
一堆代码，您可以手动进行引用计数或按顺序进行操作
bunch of code to manually you know do
reference counting or something in order

32
00:02:26,580 --> 00:02:30,030
弄清楚您知道最后一个线程何时停止使用对象，并且
to figure out you know when the last
thread stopped using an object and

33
00:02:30,030 --> 00:02:34,710
只是痛苦而已，如果您使用垃圾，该问题将完全消失
that's just a pain and that problem
completely goes away if you use garbage

34
00:02:34,710 --> 00:02:39,390
像我们还没有去的集合，最后语言很简单
collection like we haven't go
and finally the language is simple much

35
00:02:39,390 --> 00:02:44,640
比C ++更简单使用C ++的问题之一是
simpler than C++ one of the problems
with using C++ is that often if you made

36
00:02:44,640 --> 00:02:51,420
您知道的错误，甚至可能是拼写错误，您从中得到的错误消息
an error you know maybe even just a typo
the the error message you get back from

37
00:02:51,420 --> 00:02:56,160
编译器是如此复杂，以至于在C ++中通常不值得尝试
the compiler is so complicated that in
C++ it's usually not worth trying to

38
00:02:56,160 --> 00:02:59,520
弄清楚错误消息的含义，我发现它总是更快
figure out what the error message meant
and I find it's always just much quicker

39
00:02:59,520 --> 00:03:02,670
去查看行号并尝试猜测错误一定是什么
to go look at the line number and try to
guess what the error must have been

40
00:03:02,670 --> 00:03:04,800
因为语言太复杂了
because the language is far too
complicated

41
00:03:04,800 --> 00:03:09,710
而go是您知道可能没有很多人喜欢的特性
whereas go is you know probably doesn't
have a lot of people's favorite features

42
00:03:09,710 --> 00:03:14,940
但这是相对简单的语言，所以在这一点上
but it's relatively straightforward
language okay so at this point you're

43
00:03:14,940 --> 00:03:19,290
两者都在本教程上（如果您正在寻找），您知道该看什么
both on the tutorial if you're looking
for sort of you know what to look at

44
00:03:19,290 --> 00:03:23,190
接下来学习该语言的一个好地方就是标题为
next to learn about the language a good
place to look is the document titled

45
00:03:23,190 --> 00:03:30,390
您首先可以通过搜索网络找到的有效途径
effective go which you know you can find
by searching the web all right the first

46
00:03:30,390 --> 00:03:35,940
我想谈的是线程，我们之所以非常在意的原因
thing I want to talk about is threads
the reason why we care a lot about

47
00:03:35,940 --> 00:03:41,459
本课程中的线程是线程是我们要使用的主要工具
threads in this course is that threads
are the sort of main tool we're going to

48
00:03:41,459 --> 00:03:47,340
用于管理程序中的并发，并发是一个特殊的
be using to manage concurrency in
programs and concurrency is a particular

49
00:03:47,340 --> 00:03:52,440
对分布式编程很感兴趣，因为通常情况下
interest in distributed programming
because it's often the case that one

50
00:03:52,440 --> 00:03:55,890
程序实际上需要与一堆您知道的其他计算机对话
program actually needs to talk to a
bunch of other computers you know client

51
00:03:55,890 --> 00:04:00,300
可能会与许多服务器通信，或者一台服务器可能同时在
may talk to many servers or a server may
be serving requests at the same time on

52
00:04:00,300 --> 00:04:04,830
代表许多不同的客户，所以我们需要一种方式说哦，您知道我是我的
behalf of many different clients and so
we need a way to say oh you know I'm my

53
00:04:04,830 --> 00:04:07,410
程序确实有七种不同的情况发生，因为它正在与
program really has seven different
things going on because it's talking to

54
00:04:07,410 --> 00:04:12,450
七个不同的客户，我想要一个简单的方法来允许它执行这七个
seven different clients and I want a
simple way to allow it to do these seven

55
00:04:12,450 --> 00:04:16,858
您不需要太多复杂的编程就可以知道不同的事情
different things you know without too
much complex programming I mean sort of

56
00:04:16,858 --> 00:04:21,629
推力线就是答案，所以这些都是go文档

57
00:04:21,630 --> 00:04:26,789
调用go例程，我称之为线程，它们是go例程，实际上是一样的
calls go routines which I call threads
they're go routines are really this same

58
00:04:26,789 --> 00:04:32,560
就像其他人所说的Red一样，线程的思考方式是
as what everybody else calls
Red's so the way to think of threads is

59
00:04:32,560 --> 00:04:43,120
你有一个程序和一个地址空间的程序，我要画一个
that you have a program of one program
and one address space I'm gonna draw a

60
00:04:43,120 --> 00:04:48,250
框来表示一个地址空间，并在该地址空间内
box to sort of denote an address space
and within that address space in a

61
00:04:48,250 --> 00:04:54,550
没有线程的串行程序，只有一个执行线程正在执行
serial program without threads you just
have one thread of execution executing

62
00:04:54,550 --> 00:05:00,100
该地址空间中的代码一个程序计数器一组寄存器一组
code in that address space one program
counter one set of registers one stack

63
00:05:00,100 --> 00:05:04,180
在某种程度上描述了线程中执行的当前状态
that are sort of describing the current
state of the execution in a threaded

64
00:05:04,180 --> 00:05:09,190
像go程序这样的程序，您可能有多个线程，并且您知道我很生
program like a go program you could have
multiple threads and you know I got raw

65
00:05:09,190 --> 00:05:13,480
它是多条弯曲的线，并且当每条线代表一个
it as multiple squiggly lines and when
each line represents really is a

66
00:05:13,480 --> 00:05:17,440
分开，尤其是如果线程在同时执行
separate if the especially if the
threads are executing at the same time

67
00:05:17,440 --> 00:05:21,550
但是一个单独的程序计数器是一个单独的寄存器集和一个单独的寄存器
but a separate program counter a
separate set of registers and a separate

68
00:05:21,550 --> 00:05:26,230
每个线程的堆栈，以便它们可以拥有自己的线程
stack for each of the threads so that
they can have a sort of their own thread

69
00:05:26,230 --> 00:05:31,810
控制权并在程序的不同部分执行每个线程，以及
of control and be executing each thread
in a different part of the program and

70
00:05:31,810 --> 00:05:35,530
因此，这里隐藏的是，对于每个堆栈，现在都有一个糖浆线程， 
so hidden here is that for every stack
now there's a syrupy thread there's a

71
00:05:35,530 --> 00:05:44,530
它在堆栈上执行的堆栈实际上位于一个地址空间中
stack that it's executing on the stacks
are actually in in the one address space

72
00:05:44,530 --> 00:05:47,860
程序，所以即使每个堆栈每个线程都有自己的堆栈
of the program so even though each stack
each thread has its own stack

73
00:05:47,860 --> 00:05:52,240
从技术上讲，它们都位于相同的地址空间和不同的线程中
technically the they're all in the same
address space and different threads

74
00:05:52,240 --> 00:05:55,960
如果他们知道正确的地址，则可以互相引用堆栈，尽管您
could refer to each other stacks if they
knew the right addresses although you

75
00:05:55,960 --> 00:06:01,510
通常不这样做，然后在您知道主程序时
typically don't do that and then go when
you even the main program you know when

76
00:06:01,510 --> 00:06:05,110
您首先启动程序，然后在main中运行，这只是一个步骤
you first start up the program and it
runs in main that's also it's just a go

77
00:06:05,110 --> 00:06:14,440
可以做所有常规的事情，青少年可以做的很好，就像我一样
routine and can do all the things that
go teens can do all right so as I

78
00:06:14,440 --> 00:06:21,730
提到的主要原因之一是允许程序的不同部分
mentioned one of the big reasons is to
allow different parts of the program to

79
00:06:21,730 --> 00:06:27,550
某种意义上说是在另一项活动中，所以我通常指的是
sort of be in its own point in in a
different activity so I usually refer to

80
00:06:27,550 --> 00:06:36,580
出于历史原因以及我称之为IO的原因，将其作为IO并发
that as IO concurrency for historical
reasons and the reason I call it IO

81
00:06:36,580 --> 00:06:39,580
并发是，在过去，这是第一次出现
concurrency is that in the old days
where this first came up is that oh you

82
00:06:39,580 --> 00:06:41,470
可能有一个正在等待读取的线程
might have one thread that's waiting to
read

83
00:06:41,470 --> 00:06:44,410
从磁盘上，而在等待从磁盘访问时，您希望
from the disk and while it's waiting to
reach from the disk you'd like to have a

84
00:06:44,410 --> 00:06:49,000
第二个线程可能可以计算或读取磁盘中的其他位置或发送
second thread that maybe can compute or
read somewhere else in the disk or send

85
00:06:49,000 --> 00:06:54,490
网络中的一条消息，等待回复，所以我打开货币之一
a message in the network and wait for
reply so and so I open currencies one of

86
00:06:54,490 --> 00:07:00,190
您为我们穿线的东西通常意味着我可以打开货币
the things that threads by you for us it
would usually mean I can I open currency

87
00:07:00,190 --> 00:07:04,090
我们通常是说我可以拥有一个已启动或删除程序的程序
we usually mean I can have one program
that has launched or removed procedure

88
00:07:04,090 --> 00:07:08,140
将请求呼叫到网络上的其他服务器，并且正在等待许多
calls requests to different servers on
the network and is waiting for many

89
00:07:08,140 --> 00:07:13,180
在同一时间回复，这将对我们产生影响，您知道
replies at the same time that's how
it'll come up for us and you know the

90
00:07:13,180 --> 00:07:17,110
用线程执行此操作的方式是，您将为创建一个线程
way you would do that with threads is
that you would create one thread for

91
00:07:17,110 --> 00:07:21,190
您要启动该线程的每个远程过程调用都会
each of the remote procedure calls that
you wanted to launch that thread would

92
00:07:21,190 --> 00:07:26,380
具有您知道发送远程过程调用请求消息和排序的代码
have code that you know sent the remote
procedure call request message and sort

93
00:07:26,380 --> 00:07:29,320
在线程中的这一点上等待了，然后终于在回复到来时
of waited at this point in the thread
and then finally when the reply came

94
00:07:29,320 --> 00:07:33,220
返回线程将继续执行，并且使用线程使我们能够
back the thread would continue executing
and using threads allows us to have

95
00:07:33,220 --> 00:07:36,250
多个线程将所有启动请求同时发送到网络
multiple threads that all launch
requests into the network at the same

96
00:07:36,250 --> 00:07:40,690
他们都在等待的时间，或者他们不必在同一时间这样做
time they all wait or they don't have to
do it at the same time they can you know

97
00:07:40,690 --> 00:07:43,090
只要他们愿意就执行它的不同部分
execute the different parts of this
whenever they feel like it

98
00:07:43,090 --> 00:07:49,720
所以这是I / O并发性，它是不同进度的重叠
so that's i/o concurrency sort of
overlapping of the progress of different

99
00:07:49,720 --> 00:07:57,060
活动并允许一个活动正在等待其他活动可以继续进行
activities and allowing one activity is
waiting other activities can proceed

100
00:07:57,060 --> 00:08:02,740
使用线程的另一个重要原因是多核并行性
another big reason to use threads is
multi-core parallelism which I'll just

101
00:08:02,740 --> 00:08:10,270
称为并行性，这是我们要尝试实现的目标
call parallelism and here the thing
where we'd be trying to achieve with

102
00:08:10,270 --> 00:08:13,540
线程是，如果您拥有一台多核计算机，例如，我确定你们所有人都在
threads is if you have a multi-core
machine like I'm sure all of you do in

103
00:08:13,540 --> 00:08:17,470
您的笔记本电脑，如果您需要大量的计算工作， 
your laptops if you have a sort of
compute heavy job that needs a lot of

104
00:08:17,470 --> 00:08:21,060
如果您有一个可以使用的程序，CPU周期就不好了
CPU cycles wouldn't it be nice if you
could have one program that could use

105
00:08:21,060 --> 00:08:25,630
计算机的所有内核上的CPU周期，实际上如果您编写了一个
CPU cycles on all of the cores of the
machine and indeed if you write a

106
00:08:25,630 --> 00:08:30,040
多线程go，如果您启动多个go例程并执行go并且它们执行某些操作
multi-threaded go if you launch multiple
go routines and go and they do something

107
00:08:30,040 --> 00:08:33,940
像坐在那里循环那样的计算机密集型，您知道pi的计算位数
computer intensive like sit there in a
loop and you know compute digits of pi

108
00:08:33,940 --> 00:08:38,520
或达到物理计算机内核数限制的值
or something then up to the limit of the
number of cores in the physical machine

109
00:08:38,520 --> 00:08:43,690
您的线程将真正并行运行，如果启动，您将知道两个线程
your threads will run truly in parallel
and if you launch you know two threads

110
00:08:43,690 --> 00:08:48,370
而不是一个，您将可以使用两倍的CPU 
instead of one you'll get twice as many
you'll be able to use twice as many CPU

111
00:08:48,370 --> 00:08:53,170
每秒循环数，所以这对于某些人来说非常重要，这并不大
cycles per second so this is very
important to some people it's not a big

112
00:08:53,170 --> 00:08:57,440
处理这门课程，因为我们很少会思考
deal on this course
be it's rare that we'll sort of think

113
00:08:57,440 --> 00:09:01,640
特别是关于现实世界中的这种并行性
specifically about this kind of
parallelism in the real world though of

114
00:09:01,640 --> 00:09:06,890
构建诸如服务器之类的东西来构成分布式系统的一部分
building things like servers to form
parts of the distributed systems it can

115
00:09:06,890 --> 00:09:11,780
有时使服务器能够运行非常重要
sometimes be extremely important to be
able to have the server be able to run

116
00:09:11,780 --> 00:09:15,140
线程并利用许多内核的CPU功能，只是因为来自
threads and harness the CPU power of a
lot of cores just because the load from

117
00:09:15,140 --> 00:09:22,850
客户通常可以很高，所以并行是第二个原因
clients can often be pretty high okay so
parallelism is a second reason why

118
00:09:22,850 --> 00:09:27,170
线程对分布式系统非常感兴趣，第三个原因
threads are quite a bit interested in
distributed systems and a third reason

119
00:09:27,170 --> 00:09:32,780
这可能不那么重要，因为有些时候
which is maybe a little bit less
important is there's some there's times

120
00:09:32,780 --> 00:09:38,630
当您真的只想能够在后台执行某项操作或
when you really just want to be able to
do something in the background or you

121
00:09:38,630 --> 00:09:42,770
知道您只需要定期做一些事情，而您不想
know there's just something you need to
do periodically and you don't want to

122
00:09:42,770 --> 00:09:47,420
必须在程序的主要部分进行某种类型的插入检查
have to sort of in the main part of your
program sort of insert checks to say

123
00:09:47,420 --> 00:09:51,080
我应该做每秒钟左右发生的事情吗？ 
well should I be doing this things that
should happen every second or so you

124
00:09:51,080 --> 00:09:54,380
就像能够点火，每一秒都能做的一样
just like to be able to fire something
up that every second does whatever the

125
00:09:54,380 --> 00:10:00,500
周期性的事情是有一些方便的原因和一个例子
periodic thing is so there's some
convenience reasons and an example which

126
00:10:00,500 --> 00:10:05,210
经常会出现一些您知道主服务器的情况
will come up for you is it's often the
case that some you know a master server

127
00:10:05,210 --> 00:10:09,350
可能想定期检查其工人是否还活着，因为
may want to check periodically whether
its workers are still alive because one

128
00:10:09,350 --> 00:10:12,170
他们中的人死了，你知道你想在另一台机器上启动该工作
of them is died you know you want to
launch that work on another machine like

129
00:10:12,170 --> 00:10:17,420
 MapReduce可能会这样做，并且是一种安排排序的方法
MapReduce might do that and one way to
arrange sort of oh do this check every

130
00:10:17,420 --> 00:10:21,680
您知道的每一分钟都会向工作人员发送消息，您还活着吗？ 
second every minute you know send a
message to the worker are you alive is

131
00:10:21,680 --> 00:10:25,700
触发执行程序，该执行程序只是循环睡眠一秒钟，然后
to fire off a go routine that just sits
in a loop that sleeps for a second and

132
00:10:25,700 --> 00:10:28,700
然后做周期性的事情，然后再睡一秒钟，所以在
then does the periodic thing and then
sleeps for a second again and so in the

133
00:10:28,700 --> 00:10:36,560
实验室中，您最终会触发这类线程，是的
labs you'll end up firing off these kind
of threads quite a bit yes is the

134
00:10:36,560 --> 00:10:44,840
开销值得，是的，对于这些东西，开销真的很小
overhead worth it yes the overhead is
really pretty small for this stuff I

135
00:10:44,840 --> 00:10:50,150
意味着您知道这取决于您创建多少个他坐在其中的一百万个线程
mean you know it depends on how many you
create a million threads that he sit in

136
00:10:50,150 --> 00:10:53,960
等待毫秒的循环，然后发送网络消息
a loop waiting for a millisecond and
then send a network message that's

137
00:10:53,960 --> 00:10:59,200
可能会给您的计算机带来巨大的负担，但是如果您创建了它，就会知道十个线程
probably a huge load on your machine but
if you create you know ten threads that

138
00:10:59,200 --> 00:11:04,850
睡一秒钟然后做一点工作，这可能不是什么大问题
sleep for a second and do a little bit
of work it's probably not a big deal at

139
00:11:04,850 --> 00:11:10,019
全部，这是我向您保证程序员的时间
all and it's
I guarantee you the programmer time you

140
00:11:10,019 --> 00:11:16,199
说，不必在一起糊涂，他们是不同的不同
say by not having to sort of mush
together they're different different

141
00:11:16,199 --> 00:11:21,449
将活动集中到一行代码中，这值得少量的CPU成本
activities into one line of code it's
it's worth the small amount of CPU cost

142
00:11:21,449 --> 00:11:27,600
几乎总是你知道如果不幸的话，你会发现
almost always still you know you will if
you're unlucky you'll discover in the

143
00:11:27,600 --> 00:11:32,519
实验室，您的某个循环睡眠时间不足或被解雇了
labs that some loop of yours is not
sleeping long enough or are you fired

144
00:11:32,519 --> 00:11:37,589
掉了一堆这些，从没有让它们退出，例如
off a bunch of these and never made them
exit for example and they just

145
00:11:37,589 --> 00:11:43,680
积累，所以你可以把它推得太远，所以这些就是
accumulate so you can push it too far
okay so these are the reasons that the

146
00:11:43,680 --> 00:11:47,730
人们非常喜欢线程并且将在此使用线程的主要原因
main reasons that people like threads a
lot and that will use threads in this

147
00:11:47,730 --> 00:12:01,860
一般通过异步程序对有关线程的其他任何问题进行分类
class any other questions about threads
in general by asynchronous program you

148
00:12:01,860 --> 00:12:06,779
意味着像一个控制线程，可以保持许多不同状态
mean like a single thread of control
that keeps state about many different

149
00:12:06,779 --> 00:12:12,209
活动是的，所以这是一个很好的问题，实际上你知道吗
activities yeah so this is a good
question actually there is you know what

150
00:12:12,209 --> 00:12:15,089
如果我们没有线程，或者由于某种原因我们不想
would happen if we didn't have threads
or we'd for some reason we didn't want

151
00:12:15,089 --> 00:12:18,899
使用威胁，例如我们将如何编写一个您可能知道的程序
to use threats like how would we be able
to write a program that could you know a

152
00:12:18,899 --> 00:12:23,339
可以同时与许多不同客户端或客户端对话的服务器
server that could talk to many different
clients at the same time or a client

153
00:12:23,339 --> 00:12:26,100
可以与任何服务器交谈的权利，可以使用哪些工具，以及
that could talk to him any servers right
what what tools could be used and it

154
00:12:26,100 --> 00:12:36,420
事实证明，这是另一种主要风格的另一种形式
turns out there is sort of another line
of another kind of another major style

155
00:12:36,420 --> 00:12:38,339
您如何构造这些程序， 
of how do you structure these programs
called

156
00:12:38,339 --> 00:12:42,529
您调用异步程序，我可能称其为通风口驱动程序
you call the asynchronous program I
might call it a vent driven programming

157
00:12:42,529 --> 00:12:50,850
因此，或者您可以使用通风孔防止编程，并且一般
so sort of or you could use a vent
prevent programming and the the general

158
00:12:50,850 --> 00:12:54,420
事件驱动程序的结构通常是只有一个线程，并且
structure of an event-driven program is
usually that it has a single thread and

159
00:12:54,420 --> 00:13:01,380
一个循环，然后该循环坐在那里，等待任何输入或
a single loop and what that loop does is
sits there and waits for any input or

160
00:13:01,380 --> 00:13:05,699
任何可能触发处理的事件，因此一个事件可能是
sort of any event that might trigger
processing so an event might be the

161
00:13:05,699 --> 00:13:10,889
来自客户端的请求到达或计时器关闭，或者您正在构建
arrival of a request from a client or a
timer going off or if you're building a

162
00:13:10,889 --> 00:13:14,189
 Window System保护了我驾驶的笔记本电脑上的许多Windows系统
Window System protect many Windows
systems on your laptops I've driven

163
00:13:14,189 --> 00:13:17,639
编写了一种事件驱动型的样式，他们在等待什么，例如按键
written an event-driven style where what
they're waiting for is like key clicks

164
00:13:17,639 --> 00:13:20,259
或鼠标移动之类的东西，因此您可能只有一个
or Mouse move
or something so you might have a single

165
00:13:20,259 --> 00:13:23,350
在事件驱动的程序中，只有一个控制威胁就无法实现
in an event-driven program it of a
single threat of control sits an aloof

166
00:13:23,350 --> 00:13:27,160
等待输入，每当它收到输入（例如数据包）时，它就会弄清楚哦
waits for input and whenever it gets an
input like a packet it figures out oh

167
00:13:27,160 --> 00:13:31,540
您知道此数据包来自哪个客户端，然后它将有一个表
you know which client did this packet
come from and then it'll have a table of

168
00:13:31,540 --> 00:13:38,199
状态是它为该客户管理的任何活动的状态
sort of what the state is of whatever
activity its managing for that client

169
00:13:38,199 --> 00:13:42,220
它会说，哦，天哪，我正在阅读某某文件
and it'll say oh gosh I was in the
middle of reading such-and-such a file

170
00:13:42,220 --> 00:13:45,850
你知道现在我要我读下一个方块，成为下一个方块
you know now it's asked me to read the
next block I'll go and be the next block

171
00:13:45,850 --> 00:13:57,249
并将其返回，威胁通常会更方便，因为它们可以让您
and return it and threats are generally
more convenient because they allow you

172
00:13:57,249 --> 00:14:01,689
真的，您知道顺序写就像直接写要容易得多
to really you know it's much easier to
write sequential just like straight

173
00:14:01,689 --> 00:14:05,649
您知道计算的控制代码行发送一条消息等待
lines of control code that does you know
computes sends a message waits for

174
00:14:05,649 --> 00:14:09,009
响应，在线程中编写此类代码要比在线程中编写代码容易得多
response whatever it's much easier to
write that kind of code in a thread than

175
00:14:09,009 --> 00:14:16,269
就是将任何活动切成一堆小块， 
it is to chop up whatever the activity
is into a bunch of little pieces that

176
00:14:16,269 --> 00:14:23,379
可以一次被这些事件驱动的循环之一激活
can sort of be activated one at a time
by one of these event-driven loops that

177
00:14:23,379 --> 00:14:31,089
说得很好，所以该计划的一个问题是，这有点
said the well and so one problem with
the scheme is that it's it's a little

178
00:14:31,089 --> 00:14:34,660
编写另一个潜在缺陷的痛苦是
bit of a pain to program another
potential defect is that while you get

179
00:14:34,660 --> 00:14:38,769
通过这种方法进行io并发，您不会获得CPU并行性，因此如果
io concurrency from this approach you
don't get CPU parallelism so if you're

180
00:14:38,769 --> 00:14:42,730
编写一个繁忙的服务器，让您真正了解一个服务器上的32个核心
writing a busy server that would really
like to keep you know 32 cores busy on a

181
00:14:42,730 --> 00:14:49,149
大型服务器计算机，您知道一个循环，因为它不是很
big server machine you know a single
loop is you know it's it's not a very

182
00:14:49,149 --> 00:14:55,029
另一方面，利用多个核心的自然方法
natural way to harness more than one
core on the other hand the overheads of

183
00:14:55,029 --> 00:14:59,259
冒险和编程通常比您所知道的线程少很多
adventure and programming are generally
quite a bit less than threads you know

184
00:14:59,259 --> 00:15:05,379
 Ed的价格很便宜，但是这些线程中的每一个都坐在堆栈上
Ed's are pretty cheap but each one of
these threads is sitting on a stack you

185
00:15:05,379 --> 00:15:09,459
知道堆栈是一个千字节还是一个千字节，或者您知道如果您有20个字节
know stack is a kilobyte or a kilobytes
or something you know if you have 20 of

186
00:15:09,459 --> 00:15:12,970
这些线程在乎您是否拥有一百万个线程， 
these threads who cares if you have a
million of these threads then it's

187
00:15:12,970 --> 00:15:17,769
开始会占用大量的内存，您可能知道调度
starting to be a huge amount of memory
and you know maybe the scheduling

188
00:15:17,769 --> 00:15:20,980
决定下一步运行线程的簿记可能也开始
bookkeeping for deciding what the thread
to run next might also start you know

189
00:15:20,980 --> 00:15:25,899
您现在有了列表调度列表，其中包含一千个线程
you now have list scheduling lists with
a thousand threads in them the threads

190
00:15:25,899 --> 00:15:30,519
可能开始变得非常昂贵，所以如果您处于需要的位置
can start to get quite expensive so if
you are in a position where you need to

191
00:15:30,519 --> 00:15:33,520
有一台服务器，先生，您知道一百万个客户，并且必须
have a single server that sir
you know a million clients and has to

192
00:15:33,520 --> 00:15:37,920
对于一百万个客户，每个人都保持一点状态，这可能是
sort of keep a little bit of state for
each of a million clients this could be

193
00:15:37,920 --> 00:15:43,900
昂贵，写一个非常容易知道的东西
expensive
and it's easier to write a very you know

194
00:15:43,900 --> 00:15:47,440
花费一些程序员时间，编写真正精简的代码会更容易
at some expense in programmer time it's
easier to write a really stripped-down

195
00:15:47,440 --> 00:15:51,940
在企业中提供高效，低开销的服务，比编程要多得多
efficient low overhead service in a
venture than programming just a lot more

196
00:15:51,940 --> 00:16:18,040
工作是在问我的JavaScript我不知道问题是
work are you asking my JavaScript I
don't know the question is whether

197
00:16:18,040 --> 00:16:25,870
 JavaScript有多个执行核心，您是否知道，取决于
JavaScript has multiple cores executing
your does anybody know depends on the

198
00:16:25,870 --> 00:16:29,230
实施是的，所以我不知道这是很自然的想法，即使
implementation yeah so I don't know I
mean it's a natural thought though even

199
00:16:29,230 --> 00:16:33,400
如果您知道您的机器，即使您知道一个go也很想拥有
in you know even an NGO you might well
want to have if you knew your machine

200
00:16:33,400 --> 00:16:37,000
如果您想编写世界上最高效的书，那么它有八个核心
had eight cores if you wanted to write
the world's most efficient whatever

201
00:16:37,000 --> 00:16:42,850
在服务器上，您可以启动八个线程，并且在每个线程上运行
server you could fire up eight threads
and on each of the threads run sort of

202
00:16:42,850 --> 00:16:49,660
精简的事件驱动循环，只是您知道一种事件循环
stripped-down event-driven loop just you
know sort of one event loop Recor and

203
00:16:49,660 --> 00:16:54,700
你知道这将是同时获得并行性和生物
that you know that would be a way to get
both parallelism and to the bio

204
00:16:54,700 --> 00:16:59,160
并发是
concurrency yes

205
00:17:05,060 --> 00:17:07,950
好吧，问题是线程和进程之间有什么区别
okay so the question is what's the
difference between threads and processes

206
00:17:07,950 --> 00:17:14,880
因此通常在类似UNIX的计算机上，进程是一个单个程序， 
so usually on a like a UNIX machine a
process is a single program that you're

207
00:17:14,880 --> 00:17:18,690
运行和某种单一地址空间为
running and a sort of single address
space a single bunch of memory for the

208
00:17:18,690 --> 00:17:23,640
进程和进程内部，您可能有多个线程，并且在准备就绪时
process and inside a process you might
have multiple threads and when you ready

209
00:17:23,640 --> 00:17:28,349
 go程序，然后运行go程序，运行go程序会创建一个unix 
to go program and you run the go program
running the go program creates one unix

210
00:17:28,349 --> 00:17:35,880
进程和一种存储区，然后在执行流程创建go时
process and one sort of memory area and
then when your go process creates go

211
00:17:35,880 --> 00:17:40,950
这些例程都位于一个进程中，所以我不确定
routines those are so sitting inside
that one process so I'm not sure that's

212
00:17:40,950 --> 00:17:45,360
确实是一个答案，但从历史上看，操作系统提供了
really an answer but just historically
the operating systems have provided like

213
00:17:45,360 --> 00:17:49,580
这个大盒子是由操作系统和
this big box is the process that's
implemented by the operating system and

214
00:17:49,580 --> 00:17:53,940
个人和某些操作系统不在乎内部发生了什么
the individual and some of the operating
system does not care what happens inside

215
00:17:53,940 --> 00:17:59,130
您的过程使用什么语言都不使用任何操作系统业务，而是
your process what language you use none
of the operating systems business but

216
00:17:59,130 --> 00:18:03,510
在该过程中，您可以运行很多线程，现在您知道是否可以运行更多线程
inside that process you can run lots of
threads now you know if you run more

217
00:18:03,510 --> 00:18:06,630
您的机器中不止一个进程，您知道您运行了多个程序
than one process in your machine you
know you run more than one program I can

218
00:18:06,630 --> 00:18:12,360
编辑或编译操作系统是非常独立的权利
edit or compiler the operating system
keep quite separate right you're your

219
00:18:12,360 --> 00:18:15,690
编辑器和编译器都有内存，但是内存不相同
editor and your compiler each have
memory but it's not the same memory that

220
00:18:15,690 --> 00:18:18,810
不允许彼此看对方，没有太多互动
are not allowed to look at each other
memory there's not much interaction

221
00:18:18,810 --> 00:18:22,470
在不同的进程之间，因此您的redditor可能有线程，并且您的
between different processes so you
redditor may have threads and your

222
00:18:22,470 --> 00:18:27,480
编译器可能有线程，但它们位于不同的世界，因此在任何情况下
compiler may have threads but they're
just in different worlds so within any

223
00:18:27,480 --> 00:18:31,890
一个程序的线程可以共享内存，并且可以与通道同步，并且
one program the threads can share memory
and can synchronize with channels and

224
00:18:31,890 --> 00:18:38,240
使用互斥对象和东西，但是在进程之间没有交互
use mutexes and stuff but between
processes there's just no no interaction

225
00:18:38,240 --> 00:18:45,140
这只是这类软件的传统结构
that's just a traditional structure of
these this kind of software

226
00:18:45,509 --> 00:18:48,509
是的
yeah

227
00:18:53,370 --> 00:18:59,190
所以问题是当上下文切换发生时，是否所有线程都发生了
so the question is when a context switch
happens does it happened for all threads

228
00:19:08,010 --> 00:19:12,580
好吧，让我们假设您有一台真正只有
okay so let's let's imagine you have a
single core machine that's really only

229
00:19:12,580 --> 00:19:19,900
跑步，一次只做一件事情，也许是思考的正确方法
running and as just doing one thing at a
time maybe the right way to think about

230
00:19:19,900 --> 00:19:22,960
这是因为您将要在自己的计算机上运行多个进程
it is that you're going to be you're
running multiple processes on your

231
00:19:22,960 --> 00:19:31,180
计算机操作系统将给CPU时间切片和
machine the operating system will give
the CPU sort of time slicing back and

232
00:19:31,180 --> 00:19:35,950
在这两个程序之间来回切换，这样当硬件计时器计时时， 
forth between these two programs so when
the hardware timer ticks and the

233
00:19:35,950 --> 00:19:38,950
操作系统决定是时候从当前版本中夺走CPU了
operating systems decides it's time to
take away the CPU from the currently

234
00:19:38,950 --> 00:19:44,700
运行流程并将其交给在流程级别完成的另一个流程
running process and give it to another
process that's done at a process level

235
00:19:48,600 --> 00:19:55,240
这很复杂，让我让我让我重新启动这些线程
it's complicated all right let me let me
let me restart this these the threads

236
00:19:55,240 --> 00:20:00,070
我们使用的基于操作系统提供的线程
that we use are based on threads that
are provided by the operating system in

237
00:20:00,070 --> 00:20:03,910
最终以及外部需要某种上下文时在其之间切换
the end and when the outer needs to some
context switches its switching between

238
00:20:03,910 --> 00:20:08,620
在这样的情况下，它知道的线程
the threads that it knows about so in a
situation like this the operating system

239
00:20:08,620 --> 00:20:11,560
可能知道在此过程中有两个线程和三个线程
might know that there are two threads
here in this process and three threads

240
00:20:11,560 --> 00:20:15,190
在此过程中，当计时器计时时，操作系统将基于
in this process and when the timer ticks
the operating system will based on some

241
00:20:15,190 --> 00:20:18,730
调度算法选择不同的线程来运行它可能会有所不同
scheduling algorithm pick a different
thread to run it might be a different

242
00:20:18,730 --> 00:20:22,270
此过程中的线程或此过程中的线程之一
thread in this process or one of the
threads in this process

243
00:20:22,270 --> 00:20:27,780
此外，巧妙地多路复用尽可能多的单行例程
in addition go cleverly multiplex as
many go routines on top of single

244
00:20:27,780 --> 00:20:32,590
操作系统线程以减少开销，因此实际上可能是两个
operating system threads to reduce
overhead so it's really probably a two

245
00:20:32,590 --> 00:20:37,330
操作系统调度阶段选择要运行的大线程， 
stages of scheduling the operating
system picks which big thread to run and

246
00:20:37,330 --> 00:20:43,290
然后在该过程中，go可以选择要运行的go例程
then within that process go may have a
choice of go routines to run

247
00:20:45,820 --> 00:20:55,539
好的，这样线程很方便，因为很多时候它们允许您
all right okay so threads are convenient
because a lot of times they allow you to

248
00:20:55,539 --> 00:20:59,919
为每个线程编写代码，就好像这是一个非常普通的顺序
write the code for each thread just as
if it were a pretty ordinary sequential

249
00:20:59,919 --> 00:21:10,529
程序，但是实际上在编写线程代码方面存在一些挑战
program however there are in fact some
challenges with writing threaded code

250
00:21:15,149 --> 00:21:18,999
一是如何处理共享数据
one is what to do about shared data one
of the really cool things about the

251
00:21:18,999 --> 00:21:22,359
线程模型是这些线程共享它们共享的相同地址空间
threading model is that these threads
share the same address space they share

252
00:21:22,359 --> 00:21:26,919
内存，如果一个线程在内存中创建对象，则可以让其他线程使用
memory if one thread creates an object
in memory you can let other threads use

253
00:21:26,919 --> 00:21:30,489
正确，您可以拥有一个数组或所有不同线程的东西
it right you can have a array or
something that all the different threads

254
00:21:30,489 --> 00:21:33,879
正在阅读和写作，如果您知道的话，有时这很重要
are reading and writing and that
sometimes critical right if you you know

255
00:21:33,879 --> 00:21:36,309
如果您保持一些有趣的状态，那么您可能知道
if you're keeping some interesting state
you know maybe you have a cache of

256
00:21:36,309 --> 00:21:40,840
当线程正在处理服务器时，您的服务器的缓存和内存
things that your server your cache and
memory when a thread is handling a

257
00:21:40,840 --> 00:21:43,809
客户端请求它将首先查看该缓存，但共享缓存和每个缓存
client request it's gonna first look in
that cache but the shared cache and each

258
00:21:43,809 --> 00:21:48,009
线程读取它，并且线程可能会在写入高速缓存时对其进行更新
thread reads it and the threads may
write the cache to update it when they

259
00:21:48,009 --> 00:21:51,220
有新信息要保存在缓存中，因此您可以共享它真的很酷
have new information to stick in the
cache so it's really cool you can share

260
00:21:51,220 --> 00:21:57,970
该内存，但事实证明，如果您不这样做，很容易得到错误
that memory but it turns out that it's
very very easy to get bugs if you're not

261
00:21:57,970 --> 00:22:02,590
小心，并且您在线程之间共享内存，因此完全是经典的
careful and you're sharing memory
between threads so a totally classic

262
00:22:02,590 --> 00:22:07,629
例如，您知道您的线程，因此您有一个全局变量N 
example is you know supposing your
thread so you have a global variable N

263
00:22:07,629 --> 00:22:11,440
并且在不同线程之间共享，而一个线程只想
and that's shared among the different
threads and a thread just wants to

264
00:22:11,440 --> 00:22:20,710
向右增加n，但这本身可能是对错误的邀请
increment n right but itself this is
likely to be an invitation to bugs right

265
00:22:20,710 --> 00:22:25,119
如果您对此代码没有做任何特别的事情，原因是您
if you don't do anything special around
this code and the reason is that you

266
00:22:25,119 --> 00:22:29,919
在线程中编写代码时就知道您正在访问读取
know whenever you write code in a thread
that you you know is accessing reading

267
00:22:29,919 --> 00:22:33,669
或编写与其他线程共享的数据，您知道总会有
or writing data that's shared with other
threads you know there's always the

268
00:22:33,669 --> 00:22:36,999
可能性，您必须记住，其他一些线程可能正在寻找
possibility and you got to keep in mind
that some other thread may be looking at

269
00:22:36,999 --> 00:22:41,739
数据或同时修改数据，因此存在明显的问题
the data or modifying the data at the
same time so the obvious problem with

270
00:22:41,739 --> 00:22:46,119
这可能是线程1正在执行此代码，而线程2实际上在
this is that maybe thread 1 is executing
this code and thread 2 is actually in

271
00:22:46,119 --> 00:22:50,799
在不同线程中执行相同代码的相同函数正确执行， 
the same function in a different thread
executing the very same code right and

272
00:22:50,799 --> 00:22:54,369
记得我在想N是一个全局变量，所以他们在谈论
remember I'm imagining the N is a global
variable so they're talking about the

273
00:22:54,369 --> 00:22:58,269
同样，所以这归结为你知道你实际上并没有运行
same n so what this boils down to you
know you're not actually running this

274
00:22:58,269 --> 00:23:01,749
您运行的代码是编译器生成的机器代码， 
code you're running
machine code the compiler produced and

275
00:23:01,749 --> 00:23:06,720
该机器码的作用是您知道它将X加载到寄存器中
what that machine code does is it you
know it loads X into a register

276
00:23:06,720 --> 00:23:18,129
你知道将一个加到寄存器中，然后用
you know adds one to the register and
then stores that register into X with

277
00:23:18,129 --> 00:23:23,080
 X是某个位置的地址，并且已经运行，所以您知道您可以依靠
where X is a address of some location
and ran so you know you can count on

278
00:23:23,080 --> 00:23:25,929
他们都在执行这行代码的两个线程
both of the threads
they're both executing this line of code

279
00:23:25,929 --> 00:23:31,090
您知道他们都将变量X加载到寄存器中，效果从0开始
you know they both load the variable X
into a register effect starts out at 0

280
00:23:31,090 --> 00:23:33,970
这意味着它们都加载为0，它们都递增该寄存器，因此
that means they both load at 0
they both increment that register so

281
00:23:33,970 --> 00:23:37,809
他们得到一个，并且都将一个存储回内存，现在有两个线程
they get one and they both store one
back to memory and now two threads of

282
00:23:37,809 --> 00:23:44,019
 n递增，结果值为1，谁知道呢
incremented n and the resulting value is
1 which well who knows what the

283
00:23:44,019 --> 00:23:47,289
程序员的意图也许就是程序员想要的，但是机会是
programmer intended maybe that's what
the programmer wanted but chances are

284
00:23:47,289 --> 00:24:02,710
不正确的机会是程序员想要不要1一些指令
not right chances are the programmer
wanted to not 1 some some instructions

285
00:24:02,710 --> 00:24:09,639
是原子的，所以问题是一个非常好的问题，那就是
are atomic so the question is a very
good question which it's whether

286
00:24:09,639 --> 00:24:13,269
单个指令是原子的，所以答案是肯定的，有些不是
individual instructions are atomic so
the answer is some are and some aren't

287
00:24:13,269 --> 00:24:23,440
因此，在32位存储中，极有可能是原子存储
so a store a 32-bit store is likely the
extremely likely to be atomic in the

288
00:24:23,440 --> 00:24:27,960
感觉是否有两个处理器同时存储到相同的内存地址
sense that if 2 processors store at the
same time to the same memory address

289
00:24:27,960 --> 00:24:33,159
最终得到的32位值是一个处理器的32位或
32-bit values well you'll end up with is
either the 32 bits from one processor or

290
00:24:33,159 --> 00:24:38,200
来自另一个处理器的32位，但不是其他大小的混合，事实并非如此
the 32 bits from the other processor but
not a mixture other sizes it's not so

291
00:24:38,200 --> 00:24:41,980
清除像一个字节存储一样，这取决于您使用的CPU，因为一个字节
clear like one byte stores it depends on
the CPU you using because a one byte

292
00:24:41,980 --> 00:24:47,919
 store实际上几乎可以肯定是32字节加载，然后修改8 
store is really almost certainly a 32
byte load and then a modification of 8

293
00:24:47,919 --> 00:24:51,820
位和32字节存储，但这取决于处理器，并且更加复杂
bits and a 32 byte store but it depends
on the processor and more complicated

294
00:24:51,820 --> 00:24:55,899
诸如增加微处理器之类的指令可能会
instructions like increment your
microprocessor may well have an

295
00:24:55,899 --> 00:25:00,220
可以直接增加某些内存位置的增量指令，例如
increment instruction that can directly
increment some memory location like

296
00:25:00,220 --> 00:25:05,619
尽管其中一些是原子版本，但几乎不可能是原子版本
pretty unlikely to be atomic although
there's atomic versions of some of these

297
00:25:05,619 --> 00:25:12,740
说明，所以没有办法，所以这是
instructions
so there's no way all right so this is

298
00:25:12,740 --> 00:25:20,490
这只是经典的危险，通常被称为我要参加的比赛
this is a just classic danger and it's
usually called a race I'm gonna come up

299
00:25:20,490 --> 00:25:25,280
很多事情是您要使用共享状态进行很多线程编程
a lot is you're gonna do a lot of
threaded programming with shared state

300
00:25:25,280 --> 00:25:30,570
我认为种族是涉及电子的一些古老漏洞
race I think refers to as some ancient
class of bugs involving electronic

301
00:25:30,570 --> 00:25:35,040
巡回赛，但对我们来说，您知道为什么将其称为比赛是因为
circuits but for us that you know the
reason why it's called a race is because

302
00:25:35,040 --> 00:25:43,110
如果一个CPU已开始执行此代码，而另一个CPU已开始执行
if one of the CPUs have started
executing this code and the other one

303
00:25:43,110 --> 00:25:46,320
其他线程有点接近此代码，有点像竞赛
the others thread is sort of getting
close to this code it's sort of a race

304
00:25:46,320 --> 00:25:50,309
关于第一个处理器是否可以完成并到达商店之前
as to whether the first processor can
finish and get to the store before the

305
00:25:50,309 --> 00:25:54,809
如果第一处理器实际处于第二处理器启动状态，则执行加载
second processor start status execute
the load if the first processor actually

306
00:25:54,809 --> 00:25:59,070
在第二个处理器达到负载之前管理它进行存储
manages it to do the store before the
second processor gets to the load then

307
00:25:59,070 --> 00:26:03,450
第二个处理器将看到存储的值，第二个处理器将加载
the second processor will see the stored
value and the second processor will load

308
00:26:03,450 --> 00:26:07,190
一并在商店二中添加一个
one and add one to it in store two

309
00:26:07,370 --> 00:26:13,679
这样您就可以证明该术语合理，因此您
that's how you can justify this
terminology okay and so the way you

310
00:26:13,679 --> 00:26:16,890
解决这个问题，这很简单，只要您插入锁
solve this certainly something this
simple is you insert locks

311
00:26:16,890 --> 00:26:23,910
您知道您是一名程序员，因此您有一些策略可以锁定
you know you as a programmer you have
some strategy in mind for locking the

312
00:26:23,910 --> 00:26:28,830
您可以说很好的数据，您知道这条共享数据只能使用
data you can say well you know this
piece of shared data can only be used

313
00:26:28,830 --> 00:26:33,090
当持有某某某类的锁时，您会看到此锁，并且您可能已经使用过
when such-and-such a lock is held and
you'll see this and you may have used

314
00:26:33,090 --> 00:26:39,799
在本教程中，go调用会锁定互斥锁，因此您将看到的是O子
this in the tutorial the go calls locks
mutexes so what you'll see is a mule Ock

315
00:26:39,799 --> 00:26:48,320
在使用共享数据的代码序列之前，然后您将其解锁
before a sequence of code that uses
shared data and you unlock afterwards

316
00:26:48,320 --> 00:26:53,340
然后两个线程执行此操作时，每个人都足够幸运
and then whichever two threads execute
this when it to everyone is lucky enough

317
00:26:53,340 --> 00:26:57,600
首先获得锁，然后先完成所有这些工作，然后再完成操作
to get the lock first gets to do all
this stuff and finish before the other

318
00:26:57,600 --> 00:27:02,340
一个被允许继续，所以您可以考虑将一些代码包装在锁中
one is allowed to proceed and so you can
think of wrapping a some code in a lock

319
00:27:02,340 --> 00:27:07,020
让很多人都知道这一点，即使这是一行
as making a bunch of you know remember
this even though it's one line it's

320
00:27:07,020 --> 00:27:13,669
实际上，您可以将三个不同的操作视为导致这种情况的锁定
really three distinct operations you can
think of a lock as causing this sort of

321
00:27:13,669 --> 00:27:18,240
多步代码序列对于其他人来说是原子的
multi-step code sequence to be atomic
with respect to other people who have to

322
00:27:18,240 --> 00:27:21,320
锁定是
lock yes

323
00:27:26,370 --> 00:27:30,970
你应该娘娘腔，你可以重复这个问题吗
should you sissy can you repeat the
question

324
00:27:30,970 --> 00:27:39,040
哦，这是一个很好的问题，问题是如何去知道哪个变量
oh that's a great question the question
was how does go know which variable

325
00:27:39,040 --> 00:27:43,090
我们走在这里当然只是一个变量，但也许我们是说
we're walking right here of course is
only one variable but maybe we're saying

326
00:27:43,090 --> 00:27:47,440
一个等于x加y的值实际上是三个不同的变量，答案是
an equals x plus y really threes few
different variables and the answer is

327
00:27:47,440 --> 00:27:55,030
去不知道那根本就没有协会
that go has no idea it's not there's no
Association at all

328
00:27:55,030 --> 00:28:00,640
这个锁之间的任何地方，所以这个新事物是一个紧密的变量
anywhere between this lock so this new
thing is a variable which is a tight

329
00:28:00,640 --> 00:28:07,630
互斥体之间的语言之间没有关联
mutex there's just there's no
association in the language between the

330
00:28:07,630 --> 00:28:12,340
锁定和任何变量在程序员头上的联系，以便
lock and any variables the associations
in the programmers head so as a

331
00:28:12,340 --> 00:28:18,670
程序员，您需要说哦，这是一堆共享数据，您随时可以
programmer you need to say oh here's a
bunch of shared data and any time you

332
00:28:18,670 --> 00:28:22,810
修改其中的任何一个，您就会知道这是一个复杂的数据结构，例如一棵树或
modify any of it you know here's a
complex data structure say a tree or an

333
00:28:22,810 --> 00:28:26,560
可扩展的哈希表或任何您将要修改的哈希表
expandable hash table or something
anytime you're going to modify it and of

334
00:28:26,560 --> 00:28:29,710
当然，只要您需要修改，一棵树就由许多对象组成
course a tree is composed many many
objects anytime you got to modify

335
00:28:29,710 --> 00:28:32,290
与该数据结构相关的任何事物，您都必须持有
anything that's associated with this
data structure you have to hold such and

336
00:28:32,290 --> 00:28:36,580
这样的锁定权当然是很多对象，而不是对象更改
such a lock right and of course is many
objects and instead of objects changes

337
00:28:36,580 --> 00:28:40,120
因为您可能会分配新的树节点，但实际上是程序员
because you might allocate new tree
nodes but it's really the programmer who

338
00:28:40,120 --> 00:28:44,710
制定出确保使用数据结构的策略
sort of works out a strategy for
ensuring that the data structure is used

339
00:28:44,710 --> 00:28:50,260
一次只有一个核心，因此它会创建一个或多个锁，并且
by only one core at a time and so it
creates the one or maybe more locks and

340
00:28:50,260 --> 00:28:53,020
您可以将许多锁定策略应用于一棵树，您可以想象
there's many many locking strategies you
could apply to a tree you can imagine a

341
00:28:53,020 --> 00:28:58,780
每个树节点都有锁的树，程序员制定策略
tree with a lock for every tree node the
programmer works out the strategy

342
00:28:58,780 --> 00:29:02,230
分配锁并保持程序员与之的关系
allocates the locks and keeps in the
programmers head the relationship to the

343
00:29:02,230 --> 00:29:07,690
数据，但是去吧，这就是这个锁，就像一个非常简单的事情
data but go for go it's this is this
lock it's just like a very simple thing

344
00:29:07,690 --> 00:29:12,970
有一个锁对象，第一个调用锁的线程获取了另一个锁
there's a lock object the first thread
that calls lock gets the lock other

345
00:29:12,970 --> 00:29:18,540
线程必须等待，直到没有锁，这一切都知道了
threads have to wait until none locks
and that's all go knows

346
00:29:18,800 --> 00:29:21,160
是的
yeah

347
00:29:23,990 --> 00:29:29,040
它不锁定对象的所有变量吗go不知道
does it not lock all variables that are
part of the object go doesn't know

348
00:29:29,040 --> 00:29:33,720
关于变量和锁之间关系的任何事情，所以当您获得
anything about the relationship between
variables and locks so when you acquire

349
00:29:33,720 --> 00:29:41,280
当您拥有调用锁的代码时，该锁正是在执行此操作
that lock when you have code that calls
lock exactly what it is doing it is

350
00:29:41,280 --> 00:29:47,280
获得此锁定，这就是所有要做的，还有其他尝试锁定的人
acquiring this lock and that's all this
does and anybody else who tries to lock

351
00:29:47,280 --> 00:29:55,170
对象，所以其他可能会宣布您知道互斥的对象
objects so somewhere else who would have
declared you know mutex knew all right

352
00:29:55,170 --> 00:29:58,410
这个亩指的是某个特定的锁对象，没有，还有很多
and this mu refers to some particular
lock object no and there me many many

353
00:29:58,410 --> 00:30:04,620
锁定正确，这就是获得该锁定，其他任何想要锁定的人
locks right all this does is acquires
this lock and anybody else who wants to

354
00:30:04,620 --> 00:30:09,120
获得它必须等到我们解锁完全由我们决定的锁
acquire it has to wait until we unlock
this lock that's totally up to us as

355
00:30:09,120 --> 00:30:33,570
程序员我们用那个锁保护着什么，所以问题是
programmers what we were protecting with
that lock so the question is is it

356
00:30:33,570 --> 00:30:39,660
最好让锁成为私有数据结构的私有业务
better to have the lock be a private the
private business of the data structure

357
00:30:39,660 --> 00:30:44,820
像假设它是一个分区地图，是的，虽然它是
like supposing it a zoning map yeah and
you know you would hope although it's

358
00:30:44,820 --> 00:30:49,860
不正确的是，内部地图会具有保护它的锁，这是一个
not true that map internally would have
a lock protecting it and that's a

359
00:30:49,860 --> 00:30:56,340
合理的策略是拥有我的意思是，如果您拥有
reasonable strategy would be to have I
mean what would be to have it if you

360
00:30:56,340 --> 00:30:59,820
定义一个需要锁定的数据结构
define a data structure that needs to be
locked to have the lock be sort of

361
00:30:59,820 --> 00:31:03,210
具有每种数据结构方法的内部
interior that have each of the data
structures methods be responsible for

362
00:31:03,210 --> 00:31:06,840
获取该锁，用户数据结构可能永远不会知道
acquiring that lock and the user the
data structure may never know that

363
00:31:06,840 --> 00:31:10,830
这是非常合理的，唯一可以解决的问题是
that's pretty reasonable and the only
point at which that breaks down is that

364
00:31:10,830 --> 00:31:18,090
嗯，这是几件事情，如果程序员知道数据是
um well it's a couple things one is if
the programmer knew that the data was

365
00:31:18,090 --> 00:31:22,200
从来没有分享过，他们可能会为他们付出的锁开销感到沮丧
never shared they might be bummed that
they were paying the lock overhead for

366
00:31:22,200 --> 00:31:25,820
他们知道不需要锁定的东西，所以这是一个潜在的问题
something they knew didn't need to be
locked so that's one potential problem

367
00:31:25,820 --> 00:31:33,060
另一个是，如果您有依赖关系的任何内部数据结构，那么
the other is that if you if there's any
inter data structure of dependencies so

368
00:31:33,060 --> 00:31:36,020
我们有两个分别带有锁和
we have two data structures each with
locks and

369
00:31:36,020 --> 00:31:41,080
他们可能会互相使用，那么就有周期和死锁的风险
and they maybe use each other then
there's a risk of cycles and deadlocks

370
00:31:41,080 --> 00:31:47,600
正确，可以解决僵局，但是通常的解决僵局的方法
right and the deadlocks can be solved
but the usual solutions to deadlocks

371
00:31:47,600 --> 00:31:54,290
需要将锁从实现中移出并移到调用中
requires lifting the locks out of out of
the implementations up into the calling

372
00:31:54,290 --> 00:31:59,180
代码，我会在那一点上谈论它，但这不是一个隐藏的好主意
code I will talk about that some point
but it's not a it's a good idea to hide

373
00:31:59,180 --> 00:32:11,600
锁，但这并不总是一个好主意，好吧，所以一个问题
the locks but it's not always a good
idea all right okay so one problem you

374
00:32:11,600 --> 00:32:16,370
遇到线程是这些种族，通常您可以用锁解决它们
run into with threads is these races and
generally you solve them with locks okay

375
00:32:16,370 --> 00:32:19,430
或实际上有两个大策略之一是您找出一些锁定
or actually there's two big strategies
one is you figure out some locking

376
00:32:19,430 --> 00:32:25,180
一次访问一个数据线程的策略，或者
strategy for making access to the data
single thread one thread at a time or

377
00:32:25,180 --> 00:32:32,420
请您修复您的代码，使其不共享数据（如果可以），那可能是
yury you fix your code to not share data
if you can do that it's that's probably

378
00:32:32,420 --> 00:32:38,330
更好，因为它不太复杂，所以出现了另一个问题
better because it's less complex all
right so another issue that shows up

379
00:32:38,330 --> 00:32:44,780
在执行锁定操作时，带有引线的线程称为协调
with leads threads is called
coordination when we're doing locking

380
00:32:44,780 --> 00:32:48,530
所涉及的不同线程可能不知道其他线程是否存在
the different threads involved probably
have no idea that the other ones exist

381
00:32:48,530 --> 00:32:51,650
他们只是希望能够在没有其他人的情况下获取数据
they just want to like be able to get
out the data without anybody else

382
00:32:51,650 --> 00:32:55,220
干扰，但在某些情况下，您需要在哪里做
interfering but there are also cases
where you need where you do

383
00:32:55,220 --> 00:32:58,370
故意让不同的线程进行交互我想等你
intentionally want different threads to
interact I want to wait for you

384
00:32:58,370 --> 00:33:01,550
也许您正在生成一些数据，您知道自己与我的线程不同
maybe you're producing some data you
know you're a different thread than me

385
00:33:01,550 --> 00:33:05,900
您正在生成数据，我要等到生成数据后
you're you're producing data I'm gonna
wait until you've generated the data

386
00:33:05,900 --> 00:33:11,180
在我正确阅读它之前，或者您启动一堆线程说要抓取
before I read it right or you launch a
bunch of threads to say you crawl the

387
00:33:11,180 --> 00:33:14,180
网络，而您想等待所有这些匹配完成，因此有时我们
web and you want to wait for all those
fits to finish so there's times when we

388
00:33:14,180 --> 00:33:18,260
有意地希望与我们不同的人互相交流以等待
intentionally want different to us to
interact with each other to wait for

389
00:33:18,260 --> 00:33:23,320
彼此之间通常称为协调
each other
and that's usually called coordination

390
00:33:23,440 --> 00:33:28,250
在完成本教程后，您可能会知道很多
and there's a bunch of as you probably
know from having done the tutorial

391
00:33:28,250 --> 00:33:34,299
有很多技术可以像渠道一样做到这一点
there's a bunch of techniques in go for
doing this like channels

392
00:33:34,299 --> 00:33:38,950
这实际上是关于将数据从一种威胁发送到另一种威胁并进行繁殖，但
which are really about sending data from
one threat to another and breeding but

393
00:33:38,950 --> 00:33:45,239
他们确实被送去了，还有其他一些特殊用途的东西
they did to be sent there's also other
stuff that more special purpose things

394
00:33:45,239 --> 00:33:51,549
就像有一个叫做条件变量的想法，如果有
like there's a idea called condition
variables which is great if there's some

395
00:33:51,549 --> 00:33:54,489
穿出那里，你想踢它，你不确定是否另一个
thread out there and you want to kick it
period you're not sure if the other

396
00:33:54,489 --> 00:33:57,459
线程甚至在等你，但是如果它在等你，你就想给
threads even waiting for you but if it
is waiting for you you just like to give

397
00:33:57,459 --> 00:34:01,509
这是一个踢，所以它很清楚知道它应该继续做任何事情， 
it a kick so it can well know that it
should continue whatever it's doing and

398
00:34:01,509 --> 00:34:08,260
然后有一个等待小组，特别适合启动aa 
then there's wait group which is
particularly good for launching a a

399
00:34:08,260 --> 00:34:14,469
已知数量的go例程，然后等待它们完成，然后Dolph 
known number of go routines and then
waiting for them Dolph to finish and a

400
00:34:14,469 --> 00:34:23,618
与线程死锁有关的最终损害是死锁

401
00:34:23,619 --> 00:34:29,219
有时会遇到一个线程的一般问题
the general problem that you sometimes
run into where one thread

402
00:34:29,219 --> 00:34:35,858
你知道这个线程正在等待第二个线程产生一些东西

403
00:34:35,859 --> 00:34:41,168
你知道这是画一条箭头，说线程一正在等待线程二
you know it's draw an arrow to say
thread one is waiting for thread two you

404
00:34:41,168 --> 00:34:43,989
知道例如线程一可能正在等待线程二释放锁
know for example thread one may be
waiting for thread two to release a lock

405
00:34:43,989 --> 00:34:48,278
或在频道上发送某些内容，或者您​​知道某个频道中的内容会减少

406
00:34:48,279 --> 00:34:55,210
等待组，但是不幸的是，也许T 2正在等待线程1 
wait group however unfortunately maybe T
two is waiting for thread thread one to

407
00:34:55,210 --> 00:35:00,069
做某事，这在锁定其线程的情况下尤其常见
do something and this is particularly
common in the case of locks its thread

408
00:35:00,069 --> 00:35:05,740
一个获取锁a而线程获取锁是一个线程
one acquires lock a and thread to
acquire lock be so thread one is

409
00:35:05,740 --> 00:35:11,230
获得的锁抛出第二个需要B，然后下一个线程需要
acquired lock a throw two is required
lot B and then next thread one needs to

410
00:35:11,230 --> 00:35:15,910
锁B也就是持有两个锁，有时会出现
lock B also that is hold two locks which
sometimes shows up and it just so

411
00:35:15,910 --> 00:35:19,990
碰巧线程2需要保留块，嘿，这是一个死锁
happens that thread two needs to hold
block hey that's a deadlock all right at

412
00:35:19,990 --> 00:35:23,410
至少要抓住他们的第一把锁，然后继续走到他们需要的地方
least grab their first lock and then
proceed down to where they need their

413
00:35:23,410 --> 00:35:26,740
第二把锁，现在他们永远都在等对方，无论如何
second lock and now they're waiting for
each other forever right neither can

414
00:35:26,740 --> 00:35:33,569
继续操作，然后都无法释放锁，通常什么也没发生，所以
proceed neither then can release the
lock and usually just nothing happens so

415
00:35:33,569 --> 00:35:37,420
如果您的程序只是停止而似乎没有执行
if your program just kind of grinds to a
halt and doesn't seem to be doing

416
00:35:37,420 --> 00:35:42,960
什么都没有导致死锁是检查的一件事
anything but didn't crash deadlock is
it's one thing to check

417
00:35:43,799 --> 00:35:53,859
好的，让我们以教程中的Web爬网程序为例
okay all right let's look at the web
crawler from the tutorial as an example

418
00:35:53,859 --> 00:36:03,730
这些线程中的一些我有两个解决方案，并且不同
of some of this threading stuff I have a
couple of two solutions and different

419
00:36:03,730 --> 00:36:09,430
样式实际上是三种不同样式的解决方案，使我们可以谈论
styles are really three solutions in
different styles to allow us to talk a

420
00:36:09,430 --> 00:36:13,539
关于一些线程编程的细节，所以首先
bit about the details of some of this
thread programming so first of all you

421
00:36:13,539 --> 00:36:18,490
所有人都可能知道网络爬虫的工作是您给它提供页面的URL 
all probably know web crawler its job is
you give it the URL of a page that it

422
00:36:18,490 --> 00:36:23,109
开始于，您知道许多网页都具有指向其他页面的链接，那么什么是网络
starts at and you know many web pages
have links to other pages so what a web

423
00:36:23,109 --> 00:36:27,609
搜寻器尝试做的是，如果那是第一页，则提取所有
crawler is trying to do is if that's the
first page extract all the URLs that

424
00:36:27,609 --> 00:36:32,049
有人提到您知道的页面链接会获取他们指向的页面
were mentioned that pages links you know
fetch the pages they point to look at

425
00:36:32,049 --> 00:36:35,740
 ules的所有页面都是它们所引用的URL之外的所有页面
all those pages for the ules are all
those but all urls that they refer to

426
00:36:35,740 --> 00:36:41,230
并继续进行下去，直到获取了网络上的所有页面，我们再说
and keep on going until it's fetched all
the pages in the web let's just say and

427
00:36:41,230 --> 00:36:52,150
那么它应该停止，此外，页面和URL的图形是循环的， 
then it should stop in addition the the
graph of pages and URLs is cyclic that

428
00:36:52,150 --> 00:36:55,420
如果您不小心，可能会跟随您，如果您不小心
is if you're not careful
um you may end up following if you don't

429
00:36:55,420 --> 00:36:59,019
记住哦，我已经获取了此网页，您可能最终会
remember oh I've already fetched this
web page already you may end up

430
00:36:59,019 --> 00:37:03,579
永远遵循以下周期，您知道自己的履带将永远无法完成，所以其中之一
following cycles forever and you know
your crawler will never finish so one of

431
00:37:03,579 --> 00:37:08,140
搜寻器的工作是记住已经被搜寻的页面集
the jobs of the crawler is to remember
the set of pages that is already crawled

432
00:37:08,140 --> 00:37:15,819
或什至已经开始获取，并且不开始对任何页面进行第二次获取
or already even started a fetch for and
to not start a second fetch for any page

433
00:37:15,819 --> 00:37:18,849
它已经开始获取，您可以将其视为
that it's already started fetching on
and you can think of that as sort of

434
00:37:18,849 --> 00:37:25,269
强加一个树形结构，找到循环的树形子集
imposing a tree structure finding a sort
of tree shaped subset of the cyclic

435
00:37:25,269 --> 00:37:33,430
实际网页的图形还可以，所以我们要避免周期，我们希望能够
graph of actual web pages okay so we
want to avoid cycles we want to be able

436
00:37:33,430 --> 00:37:38,289
不会两次获取页面，事实证明，这需要很长时间
to not fetch a page twice it also it
turns out that it just takes a long time

437
00:37:38,289 --> 00:37:42,160
来获取网页，但是服务器速度很慢，并且因为网络
to fetch a web page but it's good
servers are slow and because the network

438
00:37:42,160 --> 00:37:48,670
延迟时间长，因此您绝对不希望获取页面
has a long speed of light latency and so
you definitely don't want to fetch pages

439
00:37:48,670 --> 00:37:54,190
一次只需要一次，除非您想爬很多年，所以付出了巨大的代价
one at a time unless you want to crawl
to take many years so it pays enormous

440
00:37:54,190 --> 00:37:57,980
导致获取许多相同的页面，但我想达到某个极限
lead to fetch many pages that same
I'm up to some limit right you want to

441
00:37:57,980 --> 00:38:01,490
继续增加并行获取的页面数，直到
keep on increasing the number of pages
you fetch in parallel until the

442
00:38:01,490 --> 00:38:05,690
您每秒获取的页面吞吐量停止增长，正在运行
throughput you're getting in pages per
second stops increasing that is running

443
00:38:05,690 --> 00:38:11,300
增加并发性，直到网络容量用尽，所以我们希望成为
increase the concurrency until you run
out of network capacity so we want to be

444
00:38:11,300 --> 00:38:15,980
能够并行启动多个提取操作，这是最终的挑战
able to launch multiple fetches in
parallel and a final challenge which is

445
00:38:15,980 --> 00:38:19,400
有时最难解决的事情是知道爬网何时完成
sometimes the hardest thing to solve is
to know when the crawl is finished

446
00:38:19,400 --> 00:38:24,110
并且一旦我们抓取了所有页面，我们就想停止并说我们完成了，但是我们
and once we've crawled all the pages we
want to stop and say we're done but we

447
00:38:24,110 --> 00:38:27,110
实际需要写代码来实现啊哈
actually need to write the code to
realize aha

448
00:38:27,110 --> 00:38:32,480
我们已经抓取了每个页面，对于某些解决方案，我尝试找出
we've crawled every single page and for
some solutions I've tried figuring out

449
00:38:32,480 --> 00:38:38,420
当你完成后，这是最难的部分，所以我的第一个
when you're done has turned out to be
the hardest part all right so my first

450
00:38:38,420 --> 00:38:43,400
搜寻器是此系列搜寻器，顺便说一下，此代码可在
crawler is this serial crawler here and
by the way this code is available on the

451
00:38:43,400 --> 00:38:48,500
搜寻器下的网站按计划运行，您不会看这个，这个手腕叫一个
website under crawler go on the schedule
you won't look at it this wrist calls a

452
00:38:48,500 --> 00:38:58,120
串行搜寻器，可有效地对网页图形执行深度优先搜索
serial crawler it effectively performs a
depth-first search into the web graph

453
00:38:58,120 --> 00:39:04,490
并且有一件适度有趣的事情使它保持
and there is sort of one moderately
interesting thing about it it keeps this

454
00:39:04,490 --> 00:39:08,630
称为fetched的地图，基本上是用作记忆的集合
map called fetched which is basically
using as a set in order to remember

455
00:39:08,630 --> 00:39:12,830
它抓取了哪些页面，这就像是您唯一有趣的部分
which pages it's crawled and that's like
the only interesting part of this you

456
00:39:12,830 --> 00:39:17,920
给它一个URL，如果已经获取了URL，它将在第18行返回
give it a URL that at line 18 if it's
already fetched the URL it just returns

457
00:39:17,920 --> 00:39:22,420
如果它不获取URL，则它首先会记住现在已获取它
if it doesn't fetch the URL it first
remembers that it is now fetched it

458
00:39:22,420 --> 00:39:27,650
实际上获取该页面并提取页面中的URL 
actually gets fetches that page and
extracts the URLs that are in the page

459
00:39:27,650 --> 00:39:33,430
使用提取程序，然后遍历该页面中的URL并自行调用
with the fetcher and then iterates over
the URLs in that page and calls itself

460
00:39:33,430 --> 00:39:38,060
对于这些页面中的每一页，它都会以它真正的方式传递给自己
for every one of those pages and it
passes to itself the way it it really

461
00:39:38,060 --> 00:39:43,070
只有一张桌子，当然只有一张提取的地图，因为您知道
has just a one table there's only one
fetched map of course because you know

462
00:39:43,070 --> 00:39:47,330
当我调用递归爬网时，它会获取一堆页面
when I call recursive crawl and it
fetches a bunch of pages after it

463
00:39:47,330 --> 00:39:52,340
返回我想成为您知道外部爬网实例需要注意的地方
returns I want to be where you know the
outer crawl instance needs to be aware

464
00:39:52,340 --> 00:39:56,330
某些页面已经被获取，因此我们非常依赖所获取的页面
that certain pages are already fetched
so we depend very much on the fetched

465
00:39:56,330 --> 00:40:01,970
映射是通过引用而不是通过复制在函数之间传递的，因此它
map being passed between the functions
by reference instead of by copying so it

466
00:40:01,970 --> 00:40:05,330
所以在幕后真正要做的是，走过去了
so under the hood what must really be
going on here is that go is passing a

467
00:40:05,330 --> 00:40:10,070
指向每个抓取调用的地图对象的指针，因此它们
pointer to the map object
to each of the calls of crawl so they

468
00:40:10,070 --> 00:40:15,740
全部共享指向相同对象和内存的指针，而不是复制
all share the pointer to the same object
and memory rather than copying rather

469
00:40:15,740 --> 00:40:24,140
比复制比任何问题，所以这段代码绝对不能解决
than copying than that any questions so
this code definitely does not solve the

470
00:40:24,140 --> 00:40:30,650
提出正确的问题，因为它不会启动并行并行获取
problem that was posed right because it
doesn't launch parallel parallel fetches

471
00:40:30,650 --> 00:40:35,150
现在这样的提示我们需要在此代码中的某处插入goroutines以获得
now so clue we need to insert goroutines
somewhere in this code right to get

472
00:40:35,150 --> 00:40:41,480
并行获取，所以让我们假设只是为咯咯笑的爸爸，我们从
parallel fetches so let's suppose just
for chuckles dad we just start with the

473
00:40:41,480 --> 00:40:54,950
最懒惰的事情，因为为什么我要修改代码以运行
most lazy thing because why so I'm gonna
just modify the code to run the

474
00:40:54,950 --> 00:41:00,470
子公司实际上在我这样做之前就按照自己的go例程进行爬网
subsidiary crawls each in its own go
routine actually before I do that why

475
00:41:00,470 --> 00:41:04,070
我不是运行代码只是为了向您展示正确的输出是什么样子，希望
don't I run the code just to show you
what correct output looks like so hoping

476
00:41:04,070 --> 00:41:09,380
这个另一个窗口Emad运行抓取工具，它实际上运行的是所有三个副本
this other window Emad run the crawler
it actually runs all three copies of the

477
00:41:09,380 --> 00:41:14,330
搜寻器，他们都找到完全相同的一组网页，因此这是
crawler and they all find exactly the
same set of webpages so this is the

478
00:41:14,330 --> 00:41:19,220
我们希望看到五行输出的是五个不同的网页
output that we're hoping to see five
lines five different web pages are are

479
00:41:19,220 --> 00:41:26,120
抓取为每一个打印一行，所以现在让我运行辅助爬网
fetched prints a line for each one so
let me now run the subsidiary crawls in

480
00:41:26,120 --> 00:41:35,540
他们自己的go例程并运行该代码，所以我要看到的希望是
their own go routines and run that code
so what am I going to see the hope is to

481
00:41:35,540 --> 00:41:42,800
并行获取这些网页以获得更高的性能，那么好的， 
fetch these webpages in parallel for
higher performance so okay so you're

482
00:41:42,800 --> 00:41:47,680
投票只看到一个URL，为什么呢？ 
voting for only seeing one URL and why
so why is that

483
00:41:50,980 --> 00:41:59,000
是的，那是完全正确的，之后您将不再等待
yeah yes that's exactly right you know
after the after it's not gonna wait in

484
00:41:59,000 --> 00:42:02,450
这个循环在第26行，它将在那个循环中滑动，我将
this loop at line 26 it's gonna zip
right through that loop I was gonna

485
00:42:02,450 --> 00:42:07,039
轮渡在第22行的第一个网页时获取1p，然后循环播放
fetch 1p when the ferry first webpage at
line 22 and then a loop it's gonna fly

486
00:42:07,039 --> 00:42:10,220
关闭女孩例程，然后滚动功能将立即返回并
off the girl routines and immediately
the scroll function is gonna return and

487
00:42:10,220 --> 00:42:13,789
如果是从main main调用的，则几乎可以肯定在任何
if it was called from main main what was
exit almost certainly before any of the

488
00:42:13,789 --> 00:42:16,880
例行程序完全可以做任何工作，所以我们可能只会看到第一个网络
routines was able to do any work at all
so we'll probably just see the first web

489
00:42:16,880 --> 00:42:23,920
页面，我将在运行它时执行该操作，您会在这里看到只有序列号
page and I'm gonna do when I run it
you'll see here under serial that only

490
00:42:23,920 --> 00:42:28,730
实际上已经找到了一个网页，因为此程序不会在之后退出
the one web page was found now in fact
since this program doesn't exit after

491
00:42:28,730 --> 00:42:32,269
那些Guru T仍在运行的串行爬虫，它们实际上在打印
the serial crawler those Guru T's are
still running and they actually print

492
00:42:32,269 --> 00:42:37,819
他们的输出在下面与下一个搜寻器示例交织在一起，但是
their output down here interleaved with
the next crawler example but

493
00:42:37,819 --> 00:42:45,829
但是，仅在此处添加代码的代码绝对不起作用，所以让我们
nevertheless the codes just adding a go
here absolutely doesn't work so let's

494
00:42:45,829 --> 00:42:52,190
摆脱掉好吧，所以现在我想向您展示一种并发样式
get rid of that okay so now I want to
show you a one style of concurrent

495
00:42:52,190 --> 00:42:59,750
搜寻器，我正在向其中一位展示共享数据
crawler and I'm presenting to one of
them written with shared data shared

496
00:42:59,750 --> 00:43:05,059
对象并锁定它是第一个，而另一个是在没有共享数据的情况下写入的
objects and locks it's the first one and
another one written without shared data

497
00:43:05,059 --> 00:43:11,359
但沿渠道传递信息以协调
but with passing information along
channels in order to coordinate the

498
00:43:11,359 --> 00:43:17,000
不同的线程，所以这是共享数据之一，或者仅仅是众多数据之一
different threads so this is the shared
data one or this is just one of many

499
00:43:17,000 --> 00:43:22,460
使用共享数据构建网络爬虫的方法，因此此代码显着
ways of building a web crawler using
shared data so this code significantly

500
00:43:22,460 --> 00:43:31,130
它比串行搜寻器更为复杂，因此每次获取时都会创建一个线程
more complicated than a serial crawler
it creates a thread for each fetch it

501
00:43:31,130 --> 00:43:38,390
确实可以，但是最大的不同是它可以做两件事
does alright but the huge difference is
that it does with two things one it does

502
00:43:38,390 --> 00:43:44,690
要求簿记人员注意所有爬网何时完成以及
the bookkeeping required to notice when
all of the crawls have finished and it

503
00:43:44,690 --> 00:43:49,849
处理其网址已正确爬网的共享表，因此此代码
handles the shared table of which URLs
have been crawled correctly so this code

504
00:43:49,849 --> 00:43:59,349
仍然有此网址表，这就是F点获取F点获取
still has this table of URLs and that's
this F dot fetched this F dot fetch

505
00:43:59,349 --> 00:44:10,660
映射在第43行，但是此表实际上由所有
map at line 43 but this this table is
actually shared by all of the all of the

506
00:44:10,660 --> 00:44:14,890
搜寻器线程和所有衣领线程都在内部执行或执行
crawler threads and all the collar
threads are making or executing inside

507
00:44:14,890 --> 00:44:18,609
并发互斥体，因此我们在当前互斥体中仍然有这种树
concurrent mutex and so we still have
this sort of tree up in current mutexes

508
00:44:18,609 --> 00:44:22,599
正在探索网络图的不同部分，但每个部分都是
that's exploring different parts of the
web graph but each one of them was

509
00:44:22,599 --> 00:44:28,720
作为自己的go例程而不是函数调用启动，但是
launched as a as his own go routine
instead of as a function call but

510
00:44:28,720 --> 00:44:32,859
他们都共享此状态表和测试URL表，因为如果一个
they're all sharing this table of state
this table of test URLs because if one

511
00:44:32,859 --> 00:44:36,970
 go例程获取一个URL，我们不希望其他女孩例程意外
go routine fetches a URL we don't want
another girl routine to accidentally

512
00:44:36,970 --> 00:44:43,150
提取相同的URL，正如您在此处看到的那样，第42和45行已将它们包围
fetch the same URL and as you can see
here line 42 and 45 I've surrounded them

513
00:44:43,150 --> 00:44:51,099
如果我避免了为了防止比赛而需要的新税收
by the new taxes that are required to to
prevent a race that would occur if I

514
00:44:51,099 --> 00:44:57,730
没有添加新的德克萨斯州，所以这里的危险是在第43行有一个线程
didn't add them new Texas so the danger
here is that at line 43 a thread is

515
00:44:57,730 --> 00:45:02,680
检查网址已被提取，因此两个线程恰好在
checking of URLs already been fetched so
two threads happen to be following the

516
00:45:02,680 --> 00:45:09,490
现在使用相同的URL两次并发互斥锁的调用最终将查找相同的URL 
same URL now two calls to concurrent
mutex end up looking at the same URL

517
00:45:09,490 --> 00:45:13,930
可能是因为如果我们没有在两个不同的网页中提到该网址， 
maybe because that URL was mentioned in
two different web pages if we didn't

518
00:45:13,930 --> 00:45:18,819
拥有锁，他们都将访问数学表以查看线程和
have the lock they'd both access the
math table to see if the threaded and

519
00:45:18,819 --> 00:45:23,650
那么，如果已经提取了URL，并且它们都在行中变为false 
then already if the URL had been already
fetched and they both get false at line

520
00:45:23,650 --> 00:45:30,880
在第43行和第47行，它们都将输入表格的URL设置为true。 
43 they both set the URLs entering the
table to true at line 44 and at 47 they

521
00:45:30,880 --> 00:45:33,880
都会看到我已经是假的，然后他们都继续修补
will both see that I already was false
and then they both go on to patch the

522
00:45:33,880 --> 00:45:38,740
网页，所以我们需要那里的锁和思考方式，我认为是
web page so we need the lock there and
the way to think about it I think is

523
00:45:38,740 --> 00:45:44,020
我们希望第43和44行是原子的，就是我们不想其他
that we want lines 43 and 44 to be
atomic that is we don't want some other

524
00:45:44,020 --> 00:45:48,460
进入并使用43至44之间的表格的线程，我们希望
thread to to get in and be using the
table between 43 and 44 we we want to

525
00:45:48,460 --> 00:45:52,690
读取当前内容每个线程都想读取当前表内容
read the current content each thread
wants to read the current table contents

526
00:45:52,690 --> 00:45:57,309
并在没有其他任何线程干扰的情况下更新它，这就是锁
and update it without any other thread
interfering and so that's what the locks

527
00:45:57,309 --> 00:46:03,280
为我们做的很好，所以实际上关于锁定的任何问题
are doing for us okay so so actually any
questions about the about the locking

528
00:46:03,280 --> 00:46:05,940
这里的策略
strategy here

529
00:46:07,750 --> 00:46:13,670
好吧，一旦我们检查了表alliant 51中的URL条目，它就会抓取
all right once we check the URLs entry
in the table alliant 51 it just crawls

530
00:46:13,670 --> 00:46:18,950
它只是以通常的方式获取该页面，然后另一件事很有趣
it just fetches that page in the usual
way and then the other thing interesting

531
00:46:18,950 --> 00:46:35,450
发生的事情是线程的启动，是的，所以问题是
thing that's going on is the launching
of the threads yes so the question is

532
00:46:35,450 --> 00:46:47,120
 F点有什么不，没有MU没关系，所以有一个结构可以找出
what's with the F dot no no the MU it is
okay so there's a structure to find out

533
00:46:47,120 --> 00:46:53,930
第36行将所有不同的东西收集在一起
line 36 that sort of collects together
all the different stuff that all the

534
00:46:53,930 --> 00:46:57,380
我们需要运行此爬网的不同状态，这里只有两个对象，但是
different state that we need to run this
crawl and here it's only two objects but

535
00:46:57,380 --> 00:47:00,620
您知道可能还要多得多，而且它们仅组合在一起
you know it could be a lot more and
they're only grouped together for

536
00:47:00,620 --> 00:47:05,390
方便，没有深处的事实没有其他意义
convenience there's no other
significance to the fact there's no deep

537
00:47:05,390 --> 00:47:11,750
重要的是，mu和fetch将其存储在相同的结构中，并且
significance the fact that mu and fetch
store it inside the same structure and

538
00:47:11,750 --> 00:47:15,890
 F点只是一种语法，正在摆脱其中的元素之一
that F dot is just sort of the syntax
are getting out one of the elements in

539
00:47:15,890 --> 00:47:19,070
结构，所以我刚好把他们放在结构中，因为它
the structure so I just happened to put
them you in the structure because it

540
00:47:19,070 --> 00:47:22,790
允许我将与抓取相关的所有内容归为一组，但是
allows me to group together all the
stuff related to a crawl but that

541
00:47:22,790 --> 00:47:28,880
绝对不意味着go将MU与该结构相关联或
absolutely does not mean that go
associates the MU with that structure or

542
00:47:28,880 --> 00:47:33,710
与获取映射或任何东西，它只是一个锁对象，只有一个锁
with the fetch map or anything it's just
a lock objects and just has a lock

543
00:47:33,710 --> 00:47:37,930
您可以调用的功能，仅此而已
function you can call and that's all
that's going on

544
00:47:53,790 --> 00:48:00,520
所以问题是，为了通过引用传递一些东西，我不得不使用
so the question is how come in order to
pass something by reference I had to use

545
00:48:00,520 --> 00:48:03,940
在上面的示例中，当我们传递一个
star here where it is when a in the
previous example when we were passing a

546
00:48:03,940 --> 00:48:07,569
地图，我们不必使用不需要传递指针的星形
map we didn't have to use star that is
didn't have to pass a pointer I mean

547
00:48:07,569 --> 00:48:15,339
你基本上在我的第41颗星中看到的那个星号，他说
that star notation you're seeing there
in mine 41 basically and he's saying

548
00:48:15,339 --> 00:48:19,210
我们正在传递一个指向此获取状态对象的指针，并且希望它成为
that we're passing a pointer to this
fetch state object and we want it to be

549
00:48:19,210 --> 00:48:22,000
一个指针，因为我们希望内存中有一个对象，而所有
a pointer because we want there to be
one object in memory and all the

550
00:48:22,000 --> 00:48:25,240
我想使用同一对象的不同的go例程，因此它们都需要一个指针
different go routines I want to use that
same object so they all need a pointer

551
00:48:25,240 --> 00:48:29,410
到同一个对象，所以我们需要找到自己的结构
to that same object so so we need to
find your own structure that's sort of

552
00:48:29,410 --> 00:48:32,530
您用于传递指针的语法是我们不必这样做的原因
the syntax you use for passing a pointer
the reason why we didn't have to do it

553
00:48:32,530 --> 00:48:39,000
使用map的原因是，尽管语法上不清楚，但map是指针
with map is because although it's not
clear from the syntax a map is a pointer

554
00:48:39,000 --> 00:48:45,069
只是因为它内置于语言中，所以它们并不能使您成为明星
it's just because it's built into the
language they don't make you put a star

555
00:48:45,069 --> 00:48:52,420
那里，但是地图是什么，如果您声明变量类型地图，那是什么
there but what a map is is if you
declare a variable type map what that is

556
00:48:52,420 --> 00:48:57,579
是指向堆中某些数据的指针，所以无论如何它都是指针，并且始终
is a pointer to some data in the heap so
it was a pointer anyway and it's always

557
00:48:57,579 --> 00:49:00,609
通过引用传递了吗，他们只是不必放星星，它确实
passed by reference do they you just
don't have to put the star and it does

558
00:49:00,609 --> 00:49:03,609
它给你，所以那里肯定是地图
it for you
so there's they're definitely map is

559
00:49:03,609 --> 00:49:07,900
特别是您无法使用必须内置的语言来定义地图
special you cannot define map in the
language it's it has to be built in

560
00:49:07,900 --> 00:49:15,819
因为有一些奇怪的事情，好吧，好吧，所以我们拿来
because there's some curious things
about it okay good okay so we fetch the

561
00:49:15,819 --> 00:49:20,799
现在，我们要针对页面中提到的每个网址启动爬网例程
page now we want to fire off a crawl go
routine for each URL mentioned in the

562
00:49:20,799 --> 00:49:26,440
我们刚刚获取的页面，所以在第50行的第56行中完成了姊妹循环
page we just fetch so that's done in
line 56 on line 50 sisters loops over

563
00:49:26,440 --> 00:49:32,950
 fetch函数返回的URL，并为每个URL触发一次
the URLs that the fetch function
returned and for each one fires off a go

564
00:49:32,950 --> 00:49:41,530
第58行的例程，并且第58行的func语法是闭包或
routine at line 58 and that lines that
func syntax in line 58 is a closure or a

565
00:49:41,530 --> 00:49:46,599
即时功能，但是func关键字正在执行的操作是清除
sort of immediate function but that func
thing keyword is doing is to clearing a

566
00:49:46,599 --> 00:49:53,280
函数，然后我们调用它，所以读取它的方法可能是
function right there that we then call
so the way to read it maybe is

567
00:49:53,740 --> 00:50:00,230
如果您可以将函数声明为仅包含func的数据，则您知道并且
that if you can declare a function as a
piece of data as just func you know and

568
00:50:00,230 --> 00:50:08,930
然后你给参数，然后给身体，这是一个空白，所以
then you give the arguments and then you
give the body and that's a clears and so

569
00:50:08,930 --> 00:50:14,000
这是一个对象，就像有一个
this is an object now this is like it's
like when you type one when you have a

570
00:50:14,000 --> 00:50:19,819
一个或23，或者您要声明某种常量对象的东西，这是
one or 23 or something you're declaring
a sort of constant object and this is

571
00:50:19,819 --> 00:50:24,079
定义常量函数的方式，我们在这里这样做是因为我们想要
the way to define a constant function
and we do it here because we want to

572
00:50:24,079 --> 00:50:27,290
启动一个go例程，它将运行我们声明正确的函数
launch a go routine that's gonna run
this function that we declared right

573
00:50:27,290 --> 00:50:31,069
在这里，所以我们为了执行go例程，我们必须在前面添加一个go 
here and so we in order to make the go
routine we have to add a go in front to

574
00:50:31,069 --> 00:50:35,059
说我们想去例程，然后我们必须调用函数，因为去
say we want to go routine and then we
have to call the function because the go

575
00:50:35,059 --> 00:50:39,140
语法表示在跟随函数时go关键字的语法
syntax says the syntax of the go
keywords as you follow it by a function

576
00:50:39,140 --> 00:50:43,460
您想传递该函数的名称和参数，所以我们要传递一些
name and arguments you want to pass that
function and so we're gonna pass some

577
00:50:43,460 --> 00:50:52,670
这里的论点，有两个原因使我们确实做到了这一点
arguments here and there's two reasons
we're doing this well really this one

578
00:50:52,670 --> 00:50:57,790
我们在其他情况下知道的原因我们本可以说走
reason we you know in some other
circumstance we could have just said go

579
00:50:57,790 --> 00:51:01,400
并发互斥体哦，我同意互斥体是我们实际使用的函数的名称
concurrent mutex oh I concur mutex is
the name of the function we actually

580
00:51:01,400 --> 00:51:08,119
想用这个URL打电话，但我们也想做其他一些事情，所以我们
want to call with this URL but we want
to do a few other things as well so we

581
00:51:08,119 --> 00:51:12,170
定义这个小辅助函数，它首先为我们调用并发互斥量
define this little helper function that
first calls concurrent mutex for us with

582
00:51:12,170 --> 00:51:17,119
 URL，然后在它们完成当前互斥后，我们执行一些操作
the URL and then after them current
mutex is finished we do something

583
00:51:17,119 --> 00:51:22,069
特别是为了帮助我们在外部进行所有爬网之前等待
special in order to help us wait for all
the crawls to be done before the outer

584
00:51:22,069 --> 00:51:27,380
函数返回，以便将我们带到权重组
function returns so that brings us to
the the weight group the weight group at

585
00:51:27,380 --> 00:51:33,619
第55行只是一个数据结构，可以通过它来帮助协调和
line 55 it's a just a data structure to
find by go to help with coordination and

586
00:51:33,619 --> 00:51:39,290
具有权重组的游戏在内部具有计数器，您可以调用
the game with weight group is that
internally it has a counter and you call

587
00:51:39,290 --> 00:51:46,549
重量组点添加为第57行，以增加计数器，我们将其分组
weight group dot add like a line 57 to
increment the counter and we group done

588
00:51:46,549 --> 00:51:50,900
先减小它，然后减小该重量，此重量方法称为第63行
to decrement it and then this weight
what this weight method called line 63

589
00:51:50,900 --> 00:51:56,510
等待计数器下降到零，所以权重组是一种等待的方式
waits for the counter to get down to
zero so a weight group is a way to wait

590
00:51:56,510 --> 00:52:02,540
完成一定数量的事情，这在很多方面很有用
for a specific number of things to
finish and it's useful in a bunch of

591
00:52:02,540 --> 00:52:05,359
在不同的情况下，我们使用它来等待最后执行例程
different situations here we're using it
to wait for the last go routine to

592
00:52:05,359 --> 00:52:07,839
完成，因为我们将一个添加到体重组
finish
because we add one to the weight group

593
00:52:07,839 --> 00:52:13,119
对于每个执行例程，我们在此函数的末尾创建第60行
for every go routine we create line 60
at the end of this function we've

594
00:52:13,119 --> 00:52:18,130
声明将权重组中的计数器递减，然后将三个权重行
declared decrement the counter in the
weight group and then line three weights

595
00:52:18,130 --> 00:52:22,300
直到所有减量完成为止，所以我们宣布这一点的原因
until all the decrements have finished
and so the reason why we declared this

596
00:52:22,300 --> 00:52:26,530
小功能基本上可以同时调用文本和调用
little function was basically to be able
to both call concurrently text and call

597
00:52:26,530 --> 00:52:39,760
这就是为什么我们需要该功能的原因，所以问题是
dot that's really why we needed that
function so the question is what if one

598
00:52:39,760 --> 00:52:45,820
子例程失败并且没有到达完成的行，这真是太好了
of the subroutines fails and doesn't
reach the done line that's a darn good

599
00:52:45,820 --> 00:52:51,070
问题是您是否知道我是否忘记了确切的错误范围
question there is you know if I forget
the exact range of errors that will

600
00:52:51,070 --> 00:52:55,150
导致执行例程失败，而不会导致程序感到
cause the go routine to fail without
causing the program to feel maybe

601
00:52:55,150 --> 00:52:57,790
除以零我不知道解引用在哪里是nil指针
divides by zero I don't know where
dereference is a nil pointer

602
00:52:57,790 --> 00:53:04,570
不确定，但是功能肯定有失败的方法，我可以
not sure but there are certainly ways
for a function to fail and I have the go

603
00:53:04,570 --> 00:53:08,890
例行程序死了而程序没有死掉，这对我们来说是个问题
routine die without having the program
die and that would be a problem for us

604
00:53:08,890 --> 00:53:13,660
因此，我确实以白色正确的方式确定了您的想法，并询问了
and so really the white right way to I'm
sure you had this in mind and asking the

605
00:53:13,660 --> 00:53:18,520
质疑编写此代码的正确方法，以确保完成呼叫未通过
question the right way to write this to
be sure that the done call is made no

606
00:53:18,520 --> 00:53:27,180
这个专家团队为什么要完成的原因是在这里推迟
matter why this guru team is finishing
would be to put a defer here which means

607
00:53:27,180 --> 00:53:34,330
调用在周围函数完成之前完成，并且始终调用否
call done before the surrounding
function finishes and always call it no

608
00:53:34,330 --> 00:53:42,119
关于周围功能为何完成的问题
matter why the surrounding function is
finished yes

609
00:53:53,559 --> 00:54:00,650
是的，所以问题是两个用户如何在不同的线程中完成任务
and yes yeah so the question is how come
two users have done in different threads

610
00:54:00,650 --> 00:54:10,640
是不是种族，所以答案必须是在内部点缀一个权重组
aren't a race yeah so the answer must be
that internally dot a weight group has a

611
00:54:10,640 --> 00:54:18,200
互斥锁或类似的东西，邓恩的每个方法在执行之前都需要获取
mutex or something like it that each of
Dunn's methods acquires before doing

612
00:54:18,200 --> 00:54:22,789
其他任何事情，以便同时调用完成以等待组方法
anything else so that simultaneously
calls to a done to await groups methods

613
00:54:22,789 --> 00:54:32,170
是我们可以做的低矮树吗
are trees we could to did a low class

614
00:54:39,519 --> 00:54:45,440
是的，对于某些叶子的C ++，在C语言中，您需要查看称为P的内容
yeah for certain leaf C++ and in C you
want to look at something called P

615
00:54:45,440 --> 00:54:48,650
用于C线程的线程位于库中，它们实际上不是该语言的一部分
threads for C threads come in a library
they're not really part of the language

616
00:54:48,650 --> 00:54:55,420
被称为P螺纹，它们非常传统和古老
called P threads which they have these
are extremely traditional and ancient

617
00:54:55,420 --> 00:55:04,450
所有语言都可以的原始体
primitives that all languages yeah

618
00:55:06,630 --> 00:55:14,140
再说一遍，您不知道这段代码中没有，但您知道您可以想象使用
say it again you know not in this code
but you know you could imagine a use of

619
00:55:14,140 --> 00:55:21,250
体重组我的意思是体重组只算东西，是的，是的，体重
weight groups I mean weight groups just
count stuff and yeah yeah yeah weight

620
00:55:21,250 --> 00:55:27,370
小组并不真的在乎你在敲打什么，或者为什么我意思是你知道这是为什么
group doesn't really care what you're
pounding or why I mean you know this is

621
00:55:27,370 --> 00:55:48,550
看到它的最常见方式是您想知道为什么将您作为
the most common way to see it use you're
wondering why you is passed as a

622
00:55:48,550 --> 00:55:59,070
函数的参数在58好的，是的，所以问题是
parameter to the function at 58 okay
yeah this is alright so the question is

623
00:55:59,070 --> 00:56:05,890
好的，所以实际上为诸如此类的功能备份了一些规则
okay so actually backing up a little bit
the rules for these for a function like

624
00:56:05,890 --> 00:56:10,960
我在58上定义的是，如果函数主体提到一个变量
the one I'm defining on 58 is that if
the function body mentions a variable

625
00:56:10,960 --> 00:56:17,470
在外部函数中声明，但没有阴影，然后内部
that's declared in the outer function
but not shadowed then the the inner

626
00:56:17,470 --> 00:56:20,650
函数的使用与内部函数中的变量相同
functions use of that is the same
variable in the inner function as in the

627
00:56:20,650 --> 00:56:26,380
外部功能，这就是Fechter所发生的事情，例如
outer function and so that's what's
happening with Fechter for example like

628
00:56:26,380 --> 00:56:30,250
这个变量在这里指的是Fechter变量指的是什么
what is this variable here refer to what
does the Fechter variable refer to in

629
00:56:30,250 --> 00:56:35,290
内部函数很好，它引用的变量与fetcher中的变量相同
the inner function well it refers it's
the same variable as as the fetcher in

630
00:56:35,290 --> 00:56:38,920
外部函数说的只是那个变量，所以当内部函数
the outer function says just is that
variable and so when the inner function

631
00:56:38,920 --> 00:56:42,310
指的是提取器，它只是意味着它只引用与此相同的变量
refers to fetcher it just means it's
just referring the same variable as this

632
00:56:42,310 --> 00:56:48,160
一个在这里，与F f相同，这里使用的只是这个变量，所以
one here and the same with F f is it's
used here it's just is this variable so

633
00:56:48,160 --> 00:56:55,990
您可能会认为我们可以摆脱我们传递的this u参数
you might think that we could get rid of
the this u argument that we're passing

634
00:56:55,990 --> 00:56:59,860
并且只让内部函数不带任何参数，而是使用U 
and just have the inner function take no
arguments at all but just use the U that

635
00:56:59,860 --> 00:57:04,530
在循环的第56行定义
was defined up on line 56 in the loop

636
00:57:05,070 --> 00:57:09,910
如果可以的话会很好，因为事实证明，为我们节省了一些打字时间
and it'll be nice if we could do that
because save us some typing it turns out

637
00:57:09,910 --> 00:57:16,060
不起作用，原因是在线的for循环的go语义
not to work and the reason is that the
semantics of go of the for loop at line

638
00:57:16,060 --> 00:57:21,850
 56是用于更新变量的变量
56 is that the
for the updates the variable you so in

639
00:57:21,850 --> 00:57:29,380
 for循环的第一次迭代，变量u包含一些URL，以及何时
the first iteration of the for loop that
variable u contains some URL and when

640
00:57:29,380 --> 00:57:34,150
您在该变量的内容之前输入第二次迭代
you enter the second iteration before
the that variable this contents are

641
00:57:34,150 --> 00:57:39,370
更改为第二个URL，这意味着我们首先执行的例程
changed to be the second URL and that
means that the first go routine that we

642
00:57:39,370 --> 00:57:43,000
推出的只是看外表，如果我们看外表
launched that's just looking at the
outer if it we're looking at the outer

643
00:57:43,000 --> 00:57:48,910
函数u变量我们启动的第一支团队会看到不同的结果
functions u variable the that first go
team we launched would see a different

644
00:57:48,910 --> 00:57:53,800
外部函数更新后的u变量中的值，有时
value in the u variable after the outer
function it updated it and sometimes

645
00:57:53,800 --> 00:57:58,000
这实际上就是您想要的，例如对于F然后是特定的F 
that's actually what you want so for
example for for F and then particular F

646
00:57:58,000 --> 00:58:04,960
取得点，我们的互动绝对希望看到该地图的变化，但对于
dot fetched we interaction absolutely
wants to see changes to that map but for

647
00:58:04,960 --> 00:58:09,070
您我们不希望看到更改，我们应在生成的第一次执行例程中读取
you we don't want to see changes the
first go routine we spawn should read

648
00:58:09,070 --> 00:58:13,810
第一个URL而不是第二个URL，因此我们希望go例程可以为您提供一个副本
the first URL not the second URL so we
want that go routine to have a copy you

649
00:58:13,810 --> 00:58:18,370
有自己的URL专用副本，您知道我们可以在其中完成
have its own private copy of the URL and
you know is we could have done it in

650
00:58:18,370 --> 00:58:22,150
我们可能有的其他方式，但是这段代码碰巧产生的方式
other ways we could have but the way
this code happens to do it to produce

651
00:58:22,150 --> 00:58:31,860
该内部函数的私有副本是通过在参数yes中传递URL 
the copy private to that inner function
is by passing the URLs in argument yes

652
00:58:34,450 --> 00:58:51,200
是的，如果我们已经通过了您的住址，那么实际上是我
yeah if we have passed the address of
you yeah then it uh it's actually I

653
00:58:51,200 --> 00:58:54,049
不知道字符串如何工作，但绝对给您自己的私人
don't know how strings work but it is
absolutely giving you your own private

654
00:58:54,049 --> 00:59:08,950
变量的副本，您得到自己的变量副本，是的
copy of the variable you get your own
copy of the variable and it yeah

655
00:59:26,500 --> 00:59:33,860
您是在说我们不需要在代码中发挥这个技巧吗？ 
are you saying we don't need to play
this trick in the code we definitely

656
00:59:33,860 --> 00:59:37,700
需要在代码中玩这个把戏，这是怎么回事
need to play this trick in the code and
what's going on is this it's so the

657
00:59:37,700 --> 00:59:41,960
问题是哦，字符串是不可变的字符串是不可变的，是的，怎么
question is Oh strings are immutable
strings are immutable right yeah so how

658
00:59:41,960 --> 00:59:45,110
字符串是不可变的，外部函数如何更改字符串
kind of strings are immutable how can
the outer function change the string

659
00:59:45,110 --> 00:59:49,700
应该没有问题，问题不是字符串被更改了
there should be no problem the problem
is not that the string is changed the

660
00:59:49,700 --> 00:59:56,150
问题是变量U改变了，所以当内部函数
problem is that the variable U is
changed so the when the inner function

661
00:59:56,150 --> 00:59:59,000
提到在其引用的外部函数中定义的变量
mentions a variable that's defined in
the outer function it's referring to

662
00:59:59,000 --> 01:00:03,320
该变量和变量的当前值，所以当您有字符串时
that variable and the variables current
value so when you if you have a string

663
01:00:03,320 --> 01:00:09,110
变量中有a，然后将B分配给该字符串变量
variable that has has a in it and then
you assign B to that string variable

664
01:00:09,110 --> 01:00:12,530
您没有写完字符串，而是将变量更改为指向
you're not over writing the string
you're changing the variable to point to

665
01:00:12,530 --> 01:00:18,680
一个不同的字符串，并且因为for循环将U变量更改为point 
a different string and and because the
for loop changes the U variable to point

666
01:00:18,680 --> 01:00:22,970
更改为另一个字符串，您知道对您所做的更改将在内部可见
to a different string you know that
change to you would be visible inside

667
01:00:22,970 --> 01:00:26,390
内部功能，因此内部功能需要自己的
the inner function and therefore the
inner function needs its own copy of the

668
01:00:26,390 --> 01:00:29,260
变量
variable

669
01:00:36,150 --> 01:00:42,000
本质上是复制它，以便
essentially make a copy of that so that

670
01:00:50,250 --> 01:00:54,670
好的，但这就是我们在这段代码中所做的，所以这就是为什么
okay but that is what we're doing in
this code and that's that is why this

671
01:00:54,670 --> 01:00:59,080
代码可以正常工作的提案或损坏的代码
code works okay
the proposal or the broken code that

672
01:00:59,080 --> 01:01:02,850
我们不在这里使用，我将向您展示损坏的代码
we're not using here I will show you the
broken code

673
01:01:44,060 --> 01:01:47,700
这就像一个可怕的细节，但是不幸的是，您将要运行
this is just like a horrible detail but
it is unfortunately one that you'll run

674
01:01:47,700 --> 01:01:52,200
在做实验的同时，至少应该在有问题的地方
into while doing the labs so you should
be at least where that there's a problem

675
01:01:52,200 --> 01:02:12,170
当您遇到它时，您可以尝试找出细节，好吗
and when you run into it maybe you can
try to figure out the details okay

676
01:02:12,170 --> 01:02:18,090
这是一个很好的问题，所以问题是您知道自己是否有
that's a great question so so the
question is you know if you have an

677
01:02:18,090 --> 01:02:21,180
如果您有一个内部函数引用一个内部函数，则内部函数只是重复
inner function just a repeated if you
have an inner function that refers to a

678
01:02:21,180 --> 01:02:25,980
周围函数中的变量，但周围函数返回的是
variable in the surrounding function but
the surrounding function returns what is

679
01:02:25,980 --> 01:02:30,030
由于外部函数是
the inner functions variable referring
to anymore since the outer function is

680
01:02:30,030 --> 01:02:35,190
作为返回，答案是去通知去分析您的内部功能
as returned and the answer is that go
notices go analyzes your inner functions

681
01:02:35,190 --> 01:02:39,870
或者这些被称为闭包去分析它们，编译器分析它们说
or these are called closures go analyzes
them the compiler analyze them says aha

682
01:02:39,870 --> 01:02:42,570
哦，在本公开中，此内部函数在外部使用变量
oh this disclosure this inner function
is using a variable in the outer

683
01:02:42,570 --> 01:02:47,580
我们实际上要使用的功能，编译器将热量存储分配给
function we're actually gonna and the
compiler will allocate heat memory to

684
01:02:47,580 --> 01:02:52,590
持有变量，就知道变量的当前值，并且两者
hold the variable the you know the
current value of the variable and both

685
01:02:52,590 --> 01:02:58,350
函数将引用具有桶的那个小区域堆，因此
functions will refer to that that little
area heap that has the barrel so it

686
01:02:58,350 --> 01:03:01,590
不会被分配，变量不会像您期望的那样在堆栈上
won't be allocated the variable won't be
on the stack as you might expect it's

687
01:03:01,590 --> 01:03:04,980
如果编译器发现正在使用闭包，则将其移至堆，然后
moved to the heap if if the compiler
sees that it's using a closure and then

688
01:03:04,980 --> 01:03:07,950
当外部函数返回对象时，堆中仍然存在该对象
when the outer function returns the
object is still there in the heap the

689
01:03:07,950 --> 01:03:11,820
内部函数仍然可以得到它，然后垃圾回收器是
inner function can still get at it and
then the garbage collector is

690
01:03:11,820 --> 01:03:15,540
负责注意到最后一个功能引用了这一小块
responsible for noticing that the last
function to refer to this little piece

691
01:03:15,540 --> 01:03:24,769
剩下的热量返回并释放出来，然后好吧好吧
of heat that's exited returned and to
free it only then okay okay

692
01:03:24,769 --> 01:03:30,629
好的，所以等待组等待组可能是这里更重要的事情， 
okay so wait group wait group is maybe
the more important thing here that the

693
01:03:30,629 --> 01:03:35,719
此代码用于等待所有所有级别的爬网的技术
technique that this code uses to wait
for all the all this level of crawls to

694
01:03:35,719 --> 01:03:39,599
完成了所有直接的冷静，完成当然是等待组
finished all its direct chill and the
finish is the wait group of course

695
01:03:39,599 --> 01:03:44,909
这些等待组很多，每个呼叫一个，每个呼叫两个并发互斥体
there's many of these wait groups one
per call two concurrent mutex each call

696
01:03:44,909 --> 01:03:49,519
该并发互斥体只是等待自己的子进程完成，然后返回
that concurrent mutex just waits for its
own children to finish and then returns

697
01:03:49,519 --> 01:03:54,479
好了，回到锁上，我想说的是一件事
okay so back to the lock actually
there's one more thing I want to talk

698
01:03:54,479 --> 01:03:57,949
关于带锁，这是探索如果我们不锁会发生什么
about with a lock and that is to explore
what would happen if we hadn't locked

699
01:03:57,949 --> 01:04:02,369
是的，我声称是哦，你知道你没有锁，你会得到这些比赛的
right I'm claiming oh you know you don't
lock you're gonna get these races you're

700
01:04:02,369 --> 01:04:11,039
不管执行什么，我们都会得到错误的执行。 
gonna get incorrect execution whatever
let's give it a shot I'm gonna I'm gonna

701
01:04:11,039 --> 01:04:17,159
注释掉锁，问题是如果我使用以下命令运行代码会发生什么
comment out the locks and the question
is what happens if I run the code with

702
01:04:17,159 --> 01:04:26,459
没有锁，我会看到什么，所以我们可能会看到ru，或者我会打电话两次或取回
no locks what am I gonna see so we may
see a ru or I'll call twice or I fetch

703
01:04:26,459 --> 01:04:31,649
两次，是的，那是您可能会期望的错误，所以我会
twice yeah that's yeah that would be the
error you might expect alright so I'll

704
01:04:31,649 --> 01:04:36,269
在没有锁的情况下运行它，我们正在查看并发映射中的一个
run it without locks and we're looking
at the concurrent map the one in the

705
01:04:36,269 --> 01:04:40,369
这次中间似乎没有两次取回任何东西，只有五个
middle this time it doesn't seem to have
fetched anything twice it's only five

706
01:04:40,369 --> 01:04:50,719
再次运行天哪，到目前为止，天才，所以也许我们在浪费那些锁的时间
run again gosh so far genius so maybe
we're wasting our time with those locks

707
01:04:50,719 --> 01:04:57,419
是的，似乎从未出错，但实际上我似乎从未出错，所以
yeah never seems to go wrong I've
actually never seem to go wrong so the

708
01:04:57,419 --> 01:05:03,329
代码仍然是错误的，总有一天它会失败，好的问题是
code is nevertheless wrong and someday
it will fail okay the problem is that

709
01:05:03,329 --> 01:05:06,179
你知道这只是这里的一些说明，所以机会
you know this is only a couple of
instructions here and so the chances of

710
01:05:06,179 --> 01:05:09,539
这两个线程可能正在发生数百条指令
these two threads which are maybe
hundreds of instructions happening to

711
01:05:09,539 --> 01:05:14,489
偶然发现这一点，您会同时知道相同的说明
stumble on this you know the same couple
of instructions at the same time is

712
01:05:14,489 --> 01:05:20,459
相当低，的确如此，这是关于越野车代码与种族的真正遗憾
quite low and indeed and and this is a
real bummer about buggy code with races

713
01:05:20,459 --> 01:05:25,289
是它通常可以正常工作，但当客户使用时可能无法工作
is that it usually works just fine but
it probably won't work when the customer

714
01:05:25,289 --> 01:05:30,510
在他们的计算机上运行它，这对我们来说实际上是个坏消息
runs it on their computer
so it's actually bad news for us right

715
01:05:30,510 --> 01:05:34,920
您知道什么在复杂程序中很难
what do we you know it it can be in
complex programs quite difficult to

716
01:05:34,920 --> 01:05:39,390
弄清楚您是否具有竞赛权，并且可能有一些代码
figure out if you have a race right and
you might you may have code that just

717
01:05:39,390 --> 01:05:44,610
看起来完全合理，实际上使用共享对您来说是未知的
looks completely reasonable that is in
fact sort of unknown to you using shared

718
01:05:44,610 --> 01:05:50,040
变量，答案是您真的是在实践中找到种族的唯一途径
variables and the answer is you really
the only way to find races in practice

719
01:05:50,040 --> 01:05:55,890
成为您自动化的工具，幸运的是，实际上给了我们这个很好的工具
to be is you automated tools and luckily
go actually gives us this pretty good

720
01:05:55,890 --> 01:06:04,619
内置了竞赛探测器，您应该使用它，如果您通过-race 
race detector built-in to go and you
should use it so if you pass the - race

721
01:06:04,619 --> 01:06:09,710
标记何时必须获取go程序并运行此比赛探测器
flag when you have to get your go
program and run this race detector which

722
01:06:09,710 --> 01:06:16,650
好吧，我将运行竞赛检测器，我们将看到它发出了一条错误消息
well I'll run the race detector and
we'll see so it emits an error message

723
01:06:16,650 --> 01:06:21,420
从我们那里发现了一场比赛，它实际上告诉我们比赛的确切地点
from us it's found a race and it
actually tells us exactly where the race

724
01:06:21,420 --> 01:06:25,260
发生了，所以此输出中有很多垃圾，但真正关键的是
happened so there's a lot of junk in
this output but the really critical

725
01:06:25,260 --> 01:06:30,180
问题是种族探测器意识到我们已经读取了一个变量
thing is that the race detector realize
that we had read a variable that's what

726
01:06:30,180 --> 01:06:35,670
该内容是先前编写的，没有中间版本， 
this read is that was previously written
and there was no intervening release and

727
01:06:35,670 --> 01:06:40,200
获取锁，这就是进一步的含义，它告诉我们
acquire of a lock that's what that's
what this means furthermore it tells us

728
01:06:40,200 --> 01:06:49,290
行号，所以它告诉我们读的是第43行，写的是
the line number so it's told us that the
read was a line 43 and the write the

729
01:06:49,290 --> 01:06:53,190
先前的写操作在第44行，实际上我们查看了代码，而读的不是
previous write was at line 44 and indeed
we look at the code and the read isn't

730
01:06:53,190 --> 01:06:58,170
第43行，右侧位于第44行，这意味着一个线程进行了写操作
line 43 and the right is at lying 44 so
that means that one thread did a write

731
01:06:58,170 --> 01:07:02,520
在第44行，然后没有任何中间锁定，另一个线程来了
at line 44 and then without any
intervening lock and another thread came

732
01:07:02,520 --> 01:07:07,560
继续阅读第43行的书面数据，基本上就是比赛
along and read that written data at line
43 that's basically what the race

733
01:07:07,560 --> 01:07:11,820
检测器正在寻找内部工作方式，它分配了
detector is looking for the way it works
internally is it allocates sort of

734
01:07:11,820 --> 01:07:16,260
影子内存现在很幸运，有些人知道它使用了大量的内存， 
shadow memory now lucky some you know it
uses a huge amount of memory and

735
01:07:16,260 --> 01:07:19,710
基本上为您的每个内存位置分配了种族探测器
basically for every one of your memory
locations the race detector is allocated

736
01:07:19,710 --> 01:07:24,330
一点点内存本身，用于跟踪最近的线程
a little bit of memory itself in which
it keeps track of which threads recently

737
01:07:24,330 --> 01:07:28,590
读取或写入每个单独的内存位置，然后何时以及也要
read or wrote every single memory
location and then when and it also to

738
01:07:28,590 --> 01:07:32,609
保持跟踪，跟踪线程何时获取释放锁并执行
keep tracking keeping track of when
threads acquiring release locks and do

739
01:07:32,609 --> 01:07:37,980
它知道的其他同步活动会强制执行但强制线程不执行
other synchronization activities that it
knows forces but force threads to not

740
01:07:37,980 --> 01:07:40,980
运行，如果种族检测程序驱动程序看到
run
and if the race detector driver sees a

741
01:07:40,980 --> 01:07:45,210
哈哈，有一个存储位置被写入然后没有读取
ha there was a memory location that was
written and then read with no

742
01:07:45,210 --> 01:08:06,600
介入市场会引发错误，是的，我相信这并不完美，是的，我
intervening market it'll raise an error
yes I believe it is not perfect yeah I

743
01:08:06,600 --> 01:08:15,180
必须考虑一下它肯定不是完美的一种方法是
have to think about it what one
certainly one way it is not perfect is

744
01:08:15,180 --> 01:08:21,270
如果您不执行某些代码，则种族探测器不知道
that if you if you don't execute some
code the race detector doesn't know

745
01:08:21,270 --> 01:08:27,990
关于它的任何事情，所以它没有分析，没有做静态分析
anything about it so it's not analyzing
it's not doing static analysis the

746
01:08:27,990 --> 01:08:31,770
赛车行业不看您的消息来源，而是根据
racing sectors not looking at your
source and making decisions based on the

747
01:08:31,770 --> 01:08:35,700
资料来源是某种程度的观察
source it's sort of watching what
happened at on this particular run of

748
01:08:35,700 --> 01:08:39,330
该程序，因此如果该程序的特定运行未执行
the program and so if this particular
run of the program didn't execute some

749
01:08:39,330 --> 01:08:44,370
碰巧读取或写入共享数据的代码，那么竞争检测器将
code that happens to read or write
shared data then the race detector will

750
01:08:44,370 --> 01:08:48,270
永远不知道，那里可能被擦除，所以这肯定是要
never know and there could be erased
there so that's certainly something to

751
01:08:48,270 --> 01:08:50,580
当心，所以您知道您是否认真对待所需的种族探测器
watch out for so you know if you're
serious about the race detector you need

752
01:08:50,580 --> 01:08:55,620
建立一种测试设备，试图确保所有代码都正确
to set up sort of testing apparatus that
tries to make sure all all the code is

753
01:08:55,620 --> 01:09:01,620
被执行，但这是非常好的，您只需要使用它就可以了8 
executed but it's it's it's very good
and you just have to use it for your 8

754
01:09:01,620 --> 01:09:09,300
到4岁还可以，所以这是这里的比赛，当然比赛实际上没有发生
to 4 lives okay so this is race here and
of course the race didn't actually occur

755
01:09:09,300 --> 01:09:14,370
比赛编辑器看不到的是实际的同时插入
what the race editor did not see was the
actual interleaving simultaneous

756
01:09:14,370 --> 01:09:18,899
对一些敏感代码的执行正确地没有看到两个线程
execution of some sensitive code right
it didn't see two threads literally

757
01:09:18,899 --> 01:09:23,969
同时执行第43和44行，从运行

758
01:09:23,970 --> 01:09:28,319
用手做的事情显然不会以低概率发生
things by hand that apparently doesn't
happen only with low probability all it

759
01:09:28,319 --> 01:09:31,529
看到在某一点是正确的，他们让我很晚以后有一个
saw was at one point that was a right
and they made me much later there was a

760
01:09:31,529 --> 01:09:39,179
无需中间步行即可阅读，因此从某种意义上讲，它可以

761
01:09:39,180 --> 01:09:47,630
检测没有实际发生或没有真正引起错误的种族
detect races that didn't actually happen
or didn't really cause bugs okay

762
01:09:49,540 --> 01:09:57,550
好的，关于此搜寻器的最后一个问题是它创建了多少个线程
okay one final question about this this
crawler how many threads does it create

763
01:10:03,639 --> 01:10:24,969
是的，还有多少个并发线程，所以这是一个缺陷
yeah and how many concurrent threads
could there be yeah so a defect in this

764
01:10:24,969 --> 01:10:28,719
搜寻器是并发线程数没有明显的限制
crawler is that there's no obvious bound
on the number of simultaneous threads

765
01:10:28,719 --> 01:10:32,800
可能会让您知道测试用例只有五个大网址
that might create you know with the test
case which only has five URLs big

766
01:10:32,800 --> 01:10:36,610
哎呀，但是如果您要爬行一个真正的轮辐网，您知道我不知道
whoopee but if you're crawling a real
wheel web with you know I don't know are

767
01:10:36,610 --> 01:10:40,389
那里有数十亿个网址，也许不是我们当然不希望出现在
there billions of URLs out there maybe
not we certainly don't want to be in a

768
01:10:40,389 --> 01:10:43,380
爬虫可能意外创建数十亿线程的位置
position where the crawler might
accidentally create billions of threads

769
01:10:43,380 --> 01:10:47,889
因为您知道成千上万的线程，这只是十亿个线程
because you know thousands of threads
it's just fine billions of threads it's

770
01:10:47,889 --> 01:10:54,280
不好，因为每个人都坐在一定数量的内存上，所以您知道
not okay because each one sits on some
amount of memory so a you know there's

771
01:10:54,280 --> 01:10:58,270
该爬虫在现实生活中可能存在很多缺陷，但在我们看来
probably many defects in real life for
this crawler but one at the level we're

772
01:10:58,270 --> 01:11:01,600
谈论的是，它确实创建了太多线程，并且确实应该有一个
talking about is that it does create too
many threads and really ought to have a

773
01:11:01,600 --> 01:11:04,630
说得好，您可以创建20个线程或100个线程或一千个线程
way of saying well you can create 20
threads or 100 threads or a thousand

774
01:11:04,630 --> 01:11:08,199
线程，但没有更多方法可以做到这一点，那就是预先创建一个池
threads but no more so one way to do
that would be to pre create a pool a

775
01:11:08,199 --> 01:11:13,179
固定大小的工人池，让工人反复寻找
fixed size pool of workers and have the
workers just iteratively look for

776
01:11:13,179 --> 01:11:18,159
另一个要爬网的URL对该URL进行爬网，而不是为其创建新线程
another URL to crawl crawl that URL
rather than creating a new thread for

777
01:11:18,159 --> 01:11:23,230
每个网址都可以，因此接下来我想谈谈另一个
each URL okay so next up I want to talk
about a another crawler that's

778
01:11:23,230 --> 01:11:28,780
实施，并且使用渠道代替
implemented and a significantly
different way using channels instead of

779
01:11:28,780 --> 01:11:33,489
共享内存，它是互斥锁调用的成员，或者我只是说有此表
shared memory it's a member on the mutex
call or I just said there is this table

780
01:11:33,489 --> 01:11:36,550
在所有线程之间共享的被调用URL的集合，并询问我
of URLs that are called that's shared
between all the threads and asked me

781
01:11:36,550 --> 01:11:44,440
锁定此版本没有这样的表不共享内存并且不
locked this version does not have such a
table does not share memory and does not

782
01:11:44,440 --> 01:11:55,060
需要使用锁好吧，所以这基本上是一个大师
need to use locks okay so this one the
instead there's basically a master

783
01:11:55,060 --> 01:12:00,699
线程是他在986上不错的主函数，它有一个表，但是
thread that's his master function on a
decent 986 and it has a table but the

784
01:12:00,699 --> 01:12:06,690
该表是主函数专用的，而主函数在做什么
table is private to the master function
and what the master function is doing is

785
01:12:06,690 --> 01:12:11,409
而不是基本上创建与之对应的功能树
instead of sort of basically creating a
tree of functions that corresponds to

786
01:12:11,409 --> 01:12:17,940
先前的抓取工具执行此操作后触发的图形的探索
the exploration of the graph which the
previous crawler did this one fires off

787
01:12:17,940 --> 01:12:23,770
每个网址只有一个专家团队，而这只是
one ute one guru team per URL that it's
fetches and that but it's only the

788
01:12:23,770 --> 01:12:28,300
只掌握创建这些线程的一个主人，所以我们没有
master only the one master that's
creating these threads so we don't have

789
01:12:28,300 --> 01:12:35,199
一棵创建线程的函数树，我们只有一个主设备，所以
a tree of functions creating threads we
just have the one master okay so it

790
01:12:35,199 --> 01:12:41,550
在第88行创建其自己的私人地图，记录其获取的内容，然后
creates its own private map a line 88
this record what it's fetched and then

791
01:12:41,550 --> 01:12:46,900
它还创建了一个通道，它的所有工作线程只有一个通道
it also creates a channel just a single
channel that all of its worker threads

792
01:12:46,900 --> 01:12:50,699
将要讨论的想法是，它将触发一个工作线程
are going to talk to and the idea is
that it's gonna fire up a worker thread

793
01:12:50,699 --> 01:12:55,630
以及完成后启动的每个工作线程，例如获取
and each worker thread that it fires up
when it finished such as fetching the

794
01:12:55,630 --> 01:13:00,250
页面将恰好将一项发送回频道上的母版，而该项目
page will send exactly one item back to
the master on the channel and that item

795
01:13:00,250 --> 01:13:07,960
将是该工作线程获取的页面中URL的列表，因此
will be a list of the URLs in the page
that that worker thread fetched so the

796
01:13:07,960 --> 01:13:13,989
主人坐在一个循环中，我们在第89行，正在从
master sits in a loop we're in line
eighty nine is reading entries from the

797
01:13:13,989 --> 01:13:20,469
频道，所以我们必须想象它已经提前启动了一些工作人员
channel and so we have to imagine that
it's started up some workers in advance

798
01:13:20,469 --> 01:13:24,489
现在正在读取这些工作人员发回的URL列表中的信息
and now it's reading the information the
URL lists that those workers send back

799
01:13:24,489 --> 01:13:28,810
并且每次他获得一个URL都坐在八十九号地上，然后循环遍历
and each time he gets a URL is sitting
on land eighty nine it then loops over

800
01:13:28,810 --> 01:13:36,100
从单个页面获取的该URL列表中的URL对齐90，并且该URL 
the URLs in that URL list from a single
page fetch align ninety and if the URL

801
01:13:36,100 --> 01:13:42,190
还没有被获取，它在第94行解雇了一个新的工人来获取
hasn't already been fetched it fires off
a new worker at line 94 to fetch that

802
01:13:42,190 --> 01:13:47,320
 URL，如果我们在线查看工作人员代码，则第77行开始会调用
URL and if we look at the worker code
online starting line 77 basically calls

803
01:13:47,320 --> 01:13:53,710
他的提取程序，然后在频道上通过80或82行发送一条消息，说
his fetcher and then sends a message on
the channel a line 80 or 82 saying

804
01:13:53,710 --> 01:14:01,170
这是他们获取的页面中的URL，请注意，现在， 
here's the URLs in the page they fetched
and notice that now that the maybe

805
01:14:01,170 --> 01:14:07,989
有趣的是，工作线程不共享任何对象
interesting thing about this is that the
worker threads don't share any objects

806
01:14:07,989 --> 01:14:11,530
工人和主人之间没有共享的对象，所以我们没有
there's no shared object between the
workers and the master so we don't have

807
01:14:11,530 --> 01:14:16,360
不必担心锁定，而不必担心恒河猴
to worry about locking we don't have to
worry about rhesus instead this is a

808
01:14:16,360 --> 01:14:21,100
交流信息而不是获取信息的示例
example of sort of communicating
information instead of getting at it

809
01:14:21,100 --> 01:14:25,620
通过共享内存是
through shared memory yes

810
01:14:33,930 --> 01:14:40,810
是的，所以观察到的是代码出现了，但是工人是
yeah yeah so the observation is that the
code appears but the workers are the

811
01:14:40,810 --> 01:14:47,130
观察是工人正在修改ch，而主人正在阅读它， 
observation is the workers are modifying
ch while the Masters reading it and

812
01:14:49,170 --> 01:14:54,160
那不是围棋作者希望您以这种方式思考的方式
that's not the way the go authors would
like you to think about this the way

813
01:14:54,160 --> 01:14:58,030
他们想让您考虑的是CH是一个频道，该频道具有
they want you to think about this is
that CH is a channel and the channel has

814
01:14:58,030 --> 01:15:03,070
发送和接收操作，而工作人员正在通道上发送，而
send and receive operations and the
workers are sending on the channel while

815
01:15:03,070 --> 01:15:09,250
主人在频道上收到，那是合法的
the master receives on the channel and
that's perfectly legal the channel is

816
01:15:09,250 --> 01:15:12,790
很高兴，我的意思是真正的意思是
happy I mean what that really means is
that the internal implementation of

817
01:15:12,790 --> 01:15:19,000
通道中有一个互斥锁，通道操作要小心
channel has a mutex in it and the
channel operations are careful to take

818
01:15:19,000 --> 01:15:22,449
当他们弄乱了通道的内部数据时，请关闭互斥量以确保
out the mutex when they're messing with
the channels internal data to ensure

819
01:15:22,449 --> 01:15:27,580
它实际上没有任何原因，但是是的，渠道是合理的
that it doesn't actually have any
reasons in it but yeah channels are sort

820
01:15:27,580 --> 01:15:30,400
防止并发，允许您同时使用它们
of protected against concurrency and
you're allowed to use them concurrently

821
01:15:30,400 --> 01:15:34,680
来自不同的线程
from different threads yes

822
01:15:36,389 --> 01:15:43,190
通过渠道收到是
over the channel receive yes

823
01:15:53,810 --> 01:15:58,850
我们不需要关闭通道，我的意思是，break语句是
we don't need to close the channel I
mean okay the the break statement is

824
01:15:58,850 --> 01:16:03,160
关于何时完全完成抓取，以及我们获取了每个URL 
about when the crawl has completely
finished and we fetched every single URL

825
01:16:03,160 --> 01:16:09,230
正确，因为发生了什么事，主人正在保持我的意思是，这个n值是
right because hey what's going on is the
master is keeping I mean this n value is

826
01:16:09,230 --> 01:16:14,860
私人价值和主人每次以逐步递增的方式解雇工人时
private value and a master every time it
fires off a worker at increments the end

827
01:16:14,860 --> 01:16:20,480
尽管每个工人都从渠道上的一个项目开始，所以开始
though every worker it starts since
exactly one item on the channel and so

828
01:16:20,480 --> 01:16:23,120
主机每次从通道中读取一个项目时，都会知道他的一个
every time the master reads an item off
the channel it knows that one of his

829
01:16:23,120 --> 01:16:29,060
工人完成后，当优秀工人的数量为零时， 
workers is finished and when the number
of outstanding workers goes to zero then

830
01:16:29,060 --> 01:16:34,520
我们已经完成了，我们不会再将优秀员工的数量降至零
we're done and we don't once the number
of outstanding workers goes to zero then

831
01:16:34,520 --> 01:16:40,370
对频道的唯一参考是来自母版或来自哦，真的来自
the only reference to the channel is
from the master or from oh really from

832
01:16:40,370 --> 01:16:43,460
调用主服务器的代码，因此垃圾收集器很快就会看到
the code that calls the master and so
the garbage collector will very soon see

833
01:16:43,460 --> 01:16:48,680
该通道没有对其的引用，并且将释放该通道，因此在此
that the channel has no references to it
and will free the channel so in this

834
01:16:48,680 --> 01:16:53,630
有时您需要关闭频道，但实际上我很少需要
case sometimes you need to close
channels but actually I rarely have to

835
01:16:53,630 --> 01:16:56,170
封闭渠道
close channels

836
01:17:03,150 --> 01:17:06,050
他再次说
he said again

837
01:17:09,749 --> 01:17:16,389
所以这个问题还好，这样您可以在致电master之前在第106行看到
so the question is alright so you can
see at line 106 before calling master

838
01:17:16,389 --> 01:17:25,659
并发通道触发，将一个URL推入该通道， 
concurrent channel sort of fires up one
shoves one URL into the channel and it's

839
01:17:25,659 --> 01:17:28,059
为了使整个事情开始，因为编写了master的代码
to sort of get the whole thing started
because the code for master was written

840
01:17:28,059 --> 01:17:31,749
您知道主机会直接从89号通道读取
you know the master goes right into
reading from the channel line 89 so

841
01:17:31,749 --> 01:17:36,550
通道中最好有东西，否则89号线将永远阻塞
there better be something in the channel
otherwise line 89 would block forever so

842
01:17:36,550 --> 01:17:42,550
如果不是第107行有那么少的代码，则89处的for循环将会阻塞
if it weren't for that little code at
line 107 the for loop at 89 would block

843
01:17:42,550 --> 01:17:54,460
永远从频道中读取，此代码无法正常运行，是的， 
reading from the channel forever and
this code wouldn't work well yeah so the

844
01:17:54,460 --> 01:17:57,510
观察真是太糟糕了，您知道能够编写代码来
observation is gosh you know wouldn't it
be nice to be able to write code that

845
01:17:57,510 --> 01:18:01,570
就能注意到频道上没有等待的内容，而您
would be able to notice if there's
nothing waiting on the channel and you

846
01:18:01,570 --> 01:18:05,019
可以，如果您查找Select语句，它比这要复杂得多，但是
can if you look up the Select statement
it's much more complicated than this but

847
01:18:05,019 --> 01:18:09,460
有一个Select语句，它使您可以继续执行以下操作： 
there is the Select statement which
allows you to proceed to not block if

848
01:18:09,460 --> 01:18:13,590
频道上没有等待的内容
something if there's nothing waiting on
the channel

849
01:18:44,590 --> 01:19:02,600
因为工作树脂完成可以，对不起第一个问题，我认为
because the work resin finish okay sorry
to the first question is there I think

850
01:19:02,600 --> 01:19:05,630
您真正担心的是我们是否真的能够启动
what you're really worried about is
whether we're actually able to launch

851
01:19:05,630 --> 01:19:37,220
并行，所以第一步不会并行，因为有出口
parallel so the very first step won't be
in parallel because there's an exit

852
01:19:37,220 --> 01:19:44,450
拥有第89行的for循环权重，这不行于第89行的for循环权重
owner the for-loop weights in at line 89
that's not okay that for loop at line 89

853
01:19:44,450 --> 01:19:49,190
不仅会循环浏览该通道的当前内容，然后退出
is does not just loop over the current
contents of the channel and then quit

854
01:19:49,190 --> 01:19:58,100
那是在89处的for循环将要读取的内容，它可能永远不会退出，但它将
that is the for loop at 89 is going to
read it may never exit but it's gonna

855
01:19:58,100 --> 01:20:01,130
阅读它会一直等待直到频道中出现某些内容
read it's just going to keep waiting
until something shows up in the channel

856
01:20:01,130 --> 01:20:10,250
因此，如果您没有在第99行的突破处for循环自己退出，是的，我
so if you don't hit the break at line 99
the for loop own exit yeah alright I'm

857
01:20:10,250 --> 01:20:15,800
怕我们没时间了，我们会继续做下去，实际上我们有一个演讲
afraid we're out of time we'll continue
this actually we have a presentation

858
01:20:15,800 --> 01:20:20,950
由TAS安排，我将详细介绍go 
scheduled by the TAS which I'll talk
more about go
