有三个步骤需要处理：下载Golang 的源代码；根据《[翻译]Go 环境设置》的提示设置环境变量；运行源代码 src 目录中的 all.bash。或者一步到位：使用二进制包进行安装。然后就会得到一个叫做“go”的工具集合。使用“go”工具和使用 PHP 的 CLI 工具一样简单。《[翻译]go 工具》对此进行了详细的解释。PHP 的迷思如果一个编程语言容易学习和使用，我们是不是就应当学习它呢？有许多容易学习和使用的编程语言。难道要把它们都学一遍？答案是显然的：NO!但是 呢？只是因为它很酷！是的，我在开玩笑，但是这是真的。无论如何先从 PHP 自身谈起吧。PHP “原本是为了开发动态的 Web 页面而设计的服务器端通用语言(Wikipedia)”。PHP 一个重要的特性就是可以嵌入到 HMTL 中。代码编写在“<?php … ?>”标签内；HTML 写在标签外。它有一个强大的扩展系统。扩展使用 C 调用 Zend API 编写。数据的处理实际上要利用这些扩展完成。在我看来，PHP 是世界上最好的模板语言。但是当积累了一些 PHP 的经验，并且开始面对一些更加复杂的 Web 应用时，你一定会对 PHP 产生一种无力的感觉。它没有内建的并行机制，没有线程、进程（你真得认为那个简陋的进程控制可以不加改造的用在高并发的生产环境？），或者其他某“程”。一个慢数据源可以阻塞整个页面的处理。消息队列、缓存、代理……系统开始不仅仅是 PHP 这么单纯，还包括了许多服务和系统组件。这时，PHP 只处理很少的业务逻辑，成为真正的模板语言了。PHPer 们总是在寻找解决这一问题的办法，如“PHP multithread”或者PHP RPC 并发框架。我很难说哪种会更好一些。不过我肯定你会需要选择一些编程语言用于后端工作的开发。就我自己的经验，我尝试过 C（一直在和 malloc/free 进行搏斗）/Java（陷入到了 jar 地狱中）/Python（从来没能做到 Pythonic 不说，还总是在错误的类型中打转）……如果想要获得性能，就得同内存管理进行搏斗；如果用 GC，就得部署和调优 VM；当获得便利性的时候，同时也是走在刀尖上，一个小错误就引起巨大的灾难……每个都有优势，同样每个都有问题。好吧！现在回到 Golang！Golang 有 GC，无需关心内存管理（或者可以用较少的精力去关注它）。代码被编译为本地码，因此“cp”和“mv”就是部署 Golang 编写的应用所需要的全部工具。噢，我刚才已经说过了，Golang 是一个具有静态类型系统的编译语言。所以你没有机会弄乱变量的类型。当然，PHPer 应该学习 Golang 的一个重要原因是“转到Go 是因为他们并未放弃太多的表达能力，但是获得了性能，并且与并发共舞（Rob Pike）”。《Why Not Go?（英文）》对此进行了深入的分析。我可以分享一些我的经验：有一个 Gearman 的worker 用于处理后端数据。PHP 通过其 API 连接到 Gearman 的 Job Server 向 worker 发起请求。最初 worker 是使用 python 编写的（还有更加原始的版本，PHP 的，但是你能想像它工作起来……唉，不说了……）。这个版本有许多的问题（是我们自己的问题，不关 Python 的事），但是至少它能工作。后来用 Golang 重写了这个 worker。为此我开发了 Golang 的 Gearman API，并使用 Zend API 编写了一个在 Golang 中执行 PHP 脚本的包。然后将它们放在一起：一个可以执行 PHP 的 Gearman worker。它已经工作了一段时间了，看起来还不错！哦，受到 Yar 的启发，这里还有一个 Golang 编写的 RPC 合并器，用来合并 PHP 脚本中的 RPC 调用。现在还是个玩具，不过或许日后能用得着。这其实是将 Golang 的 channel 当作消息队列来用。我在《Golang：有趣的 channel 应用》中对此有一些说明。世界真美好啊。谢谢 Golang！无论如何，大多数 PHPer 在进行后端开发的时候都会需要学习一些其他语言。如果你正在寻找，或者已经尝试了一些其他语言。为什么不来试试 Golang？它真得可以让你的生活更加轻松和快乐。让你可以有更多的时间陪伴你的家人和朋友，吃你爱吃的东西，去你想去的地方。貌似我还是没说清楚啊？好吧，没关系，在下个月的中国软件开发者大会上再跟大家就这个话题做一个探讨吧。
本文是对 Gopher 2017 中一个非常好的 Talk�: [Understanding Channel](GopherCon 2017: Kavya Joshi - Understanding Channels) 的学习笔记，希望能够通过对 channel 的关键特性的理解，进一步掌握其用法细节以及 Golang 语言设计哲学的管窥蠡测。
channel 是可以让一个 goroutine 发送特定值到另一个 gouroutine 的通信机制。
原生的 channel 是没有缓存的(unbuffered channel)，可以用于 goroutine 之间实现同步。
关闭后不能再写入，可以读取直到 channel 中再没有数据，并返回元素类型的零值。
gopl/ch3/netcat3
首先从 channel 是怎么被创建的开始:
在 heap 上分配一个 hchan 类型的对象，并将其初始化，然后返回一个指向这个 hchan 对象的指针。
理解了 channel 的数据结构实现，现在转到 channel 的两个最基本方法: sends 和 receivces ，看一下以上的特性是如何体现在 sends 和 receives 中的:
假设发送方先启动，执行 ch <- task0 :
如此为 channel 带来了 goroutine-safe 的特性。
在这样的模型里， sender goroutine ->channel ->receiver goroutine 之间， hchan 是唯一的共享内存，而这个唯一的共享内存又通过 mutex 来确保 goroutine-safe ，所有在队列中的内容都只是副本。
这便是著名的 golang 并发原则的体现:
发送方 goroutine 会阻塞，暂停，并在收到 receive 后才恢复。
goroutine 是一种 用户态线程 , 由 Go runtime 创建并管理，而不是操作系统，比起操作系统线程来说，goroutine更加轻量。
Go runtime scheduler 负责将 goroutine 调度到操作系统线程上。
runtime scheduler 怎么将 goroutine 调度到操作系统线程上？
当阻塞发生时，一次 goroutine 上下文切换的全过程:
然而，被阻塞的 goroutine 怎么恢复过来？
阻塞发生时，调用 runtime sheduler 执行 gopark 之前，G1 会创建一个 sudog ，并将它存放在 hchan 的 sendq 中。 sudog 中便记录了即将被阻塞的 goroutine G1 ，以及它要发送的数据元素 task4 等等。
接收方 将通过这个 sudog 来恢复 G1
接收方 G2 接收数据, 并发出一个 receivce ，将 G1 置为 runnable :
同样的, 接收方 G2 会被阻塞，G2 会创建 sudoq ，存放在 recvq ，基本过程和发送方阻塞一样。
不同的是，发送方 G1如何恢复接收方 G2，这是一个非常神奇的实现。
理论上可以将 task 入队，然后恢复 G2, 但恢复 G2后，G2会做什么呢？
G2会将队列中的 task 复制出来，放到自己的 memory 中，基于这个思路，G1在这个时候，直接将 task 写到 G2的 stack memory 中！
这是违反常规的操作，理论上 goroutine 之间的 stack 是相互独立的，只有在运行时可以执行这样的操作。
这么做纯粹是出于性能优化的考虑，原来的步骤是：
优化后，相当于减少了 G2 获取锁并且执行 memcopy 的性能消耗。
channel 设计背后的思想可以理解为 simplicity 和 performance 之间权衡抉择，具体如下：
queue with a lock prefered to lock-free implementation:
比起完全 lock-free 的实现，使用锁的队列实现更简单，容易实现
