go语言类似Java JUC包也提供了一些列用于多线程之间进行同步的措施，比如低级的同步措施有 锁、CAS、原子变量操作类。相比Java来说go提供了独特的基于通道的同步措施。本节我们先来看看go中CAS操作
go中的Cas操作与java中类似，都是借用了CPU提供的原子性指令来实现。CAS操作修改共享变量时候不需要对共享变量加锁，而是通过类似乐观锁的方式进行检查，本质还是不断的占用CPU 资源换取加锁带来的开销（比如上下文切换开销）。下面一个例子使用CAS来实现计数器
go中CAS操作具有原子性，在解决多线程操作共享变量安全上可以有效的减少使用锁所带来的开销，但是这是使用cpu资源做交换的。
我简单列举了并发编程的大纲，需要详细的私信“555”~~
爬取器 fetcher 和解析器 parser 与之前相同，模型类也不变。
注意：
见本小节文末分析。
Q1. 为什么在 scheduler 中每一个将 Request 添加到 chan 的任务都开启一个 Goroutine 来执行？
A：在 Go 语言学习9 - Channel 一节描述过，对于无缓冲的 channel， 如果两个 goroutine 没有同时准备好，通道会导致先执行发送或接收操作的 goroutine 阻塞等待 ，假设使用 s.workerChan <- request 而不是 go func() { s.workerChan <- request }() ，假设开启了 10 个 Worker Goroutine，这 10 个 goroutine 阻塞在 r := <-in 阻塞等待获取 Request 上，假设 seeds 大于 10，例如 11，那么当 Engine 的这个循环执行到底 11 个的时候，将陷入等待
，因为所有的10个 Worker goroutine 此时都可能也处于等待中，即 in chan 没有接收方准备好接收数据，所以 engine 作为发送方也要阻塞等待；那么为什么10个 Worker goroutine 都会处于等待中呢？
因为10个 Worker Goroutine 都处理完了请求，并阻塞在 out <- result ，由于 Engine 阻塞在 “将第11个 Request 发送到 in” 上，所以其无法进行后续的死循环去开启 result := <-out ，到此为止，相互等待死锁形成！！！Engine 等待 Worker 准备好 r := <-in ，而10个 Worker 等待 Engine 的 result := <-out 。
当使用 go func() { s.workerChan <- request }() 之后，Engine Goroutine 将不再阻塞，死锁等待被打破！！！
Q2. scheduler 方法为何使用指针接收者而不是值接收者？
A：在 Go 语言学习5 - 面向接口 中我们详细的介绍了什么时候使用指针接收者，什么时候使用值接收者，其中最重要的两条就是 “ 1. 如果要改变接收者内部的属性值，必须使用指针接收者，因为值接收者是对接收者副本的操作；2. 如果 struct 内一个方法是指针接收者，那么其全部方法都是用指针接收者 ”，在 scheduler 中，我们要将外界的 in chan 赋值给 scheduler 的 workChann，所以需要改变 workChann 的值，需要使用指针接收者。
