@aaaaaaaa 关于 init 的顺序性问题，不能算是个坑，因为官方文档以及语言规范中都已经说明了：一个包中的多个 init 是无序调用的，使用者不能假定其调用顺序。
再说，就算 Go 想有序，但它也不知道哪个先、哪个后呀，除非修改 init 的接口，以此来表明其先后顺序，但这违反了 Go 1 的兼容性规范，除非在 Go 2 中实现。但觉得这没太大的必要，而且反而增加了复杂度和理解度。
自已写一个 Goroutine Pool，比如：https://gowalker.org/github.com/xgfone/go-tools/pools#GoPool 。大致思路是：写一个计数器，当启动一个 Goroutine 时，加 1，当 Goroutine 结束时，减 1。
另一个方法是：写一个 Goroutine 任务池（可以设置大小），把每个任务都放到一个管道 Channel 中，而任务池中的 Goroutine 会从管道 Channel 中取任务并处理。参见实现：https://gowalker.org/github.com/xgfone/go-tools/worker#Dispatcher 。
xorm 有这两个接口，可以设置最大连接数。xorm也不错。其实我也挺喜欢gorm的，但它有个不好的缺点：只是一味地开发，不喜欢发布版本或打 Tag。这会对使用者造成很大的问题：今天能编译，到了明天可能就无法编译了。
gorm底层使用了标准库database/sql，而sql有两个接口：SetMaxIdleConns、SetMaxOpenConns。其中，SetMaxOpenConns可以满足你的需求，但gorm中好像并没有与此接口对接（注：也可能作者已经实现了，但我没有发现此接口），以便允许使用者自定义最大连接数。sql默认情况下，连接数无限制。
你可以到 https://github.com/jinzhu/gorm/issues 上去提个 issue，请作者为gorm添加SetMaxOpenConns，以便用户可以自定义最大连接数。
@dxhdxh2k 这跟我当时的需求场景有关。
我先前曾有这个测试需求：在云平台上的云主机，当配置不足以承担服务需求时，可以热升级 CPU 和 内存，而升级后，新增的 CPU 和 内存 是否会立即被投入使用。
所以，我需要：（1）跑满所有 CPU，（2）将内存使用完，并还要再使用一部分 SWAP 分区中的内存。这样，当从低配置升级到高配置时，我可以清晰的看到新增的 CPU 被立即使用了，而 SWAP 分区中的内存也被移到了新增的内存中。
因此，我需要分配大量的内存。放在循环内，可以循环分配。在 64 位系统上，最终可以分配大约 2~3GB 的内存。
PS：我当时测试的 Case 是，从 1核1GB 升级到 2核4GB，因此，程序使用的CPU核为 2，内存分配了 2GB 多。
测试：
CPU 和 Mem：2核4GBOS： CentOS 7.2 终端界面GO： Go 1.7.3代码如下：
package main
import (
"runtime"
)
var (
LEN1 = 200000
LEN2 = 1024
)
func f() {
for {
}
}
func main() {
runtime.GOMAXPROCS(2)
v := make(map[int][]int64, LEN1)
for i := 0; i < LEN1; i++ {
_v := make([]int64, LEN2)
for j := 0; j < LEN2; j++ {
_v[j] = int64(j)
}
v[i] = _v
}
go f()
for {
for i := 0; i < LEN1; i++ {
for j := 0; j < LEN2; j++ {
v[i][j] += 1
v[i][j] -= 1
}
}
}
}
操作系统启动后，不启动其它服务，CPU利用率约 1%~2%。
测试结果：
程序启动后，2核CPU 全部跑满，GO程序达到 200%，过了两三分钟后，只有一个 CPU 到达 100%，另一个CPU却是 0%，Go程序 CPU利用率 是 100%。
Go程序有两个 goruntine，可完全利用 2核CPU，但不知为何另一个 CPU 的利用率突然间变成了 0%。
当然，这也有可能是 GO 做了优化（因为其中一个 goruntine 是空循环）！当在 f() 函数中也添加一下逻辑代码，如v := 1; v+=1; v-=1;，CPU利用率始终是 200%。
发送一个数据到Channel 和 从Channel接收一个数据 都是 原子性的。
Go的哲学之一就是：不要通过共享内存来通信，而要通过通信来共享内存，前者就是传统的加锁，后者就是Channel。也就是说，设计Channel的主要目的就是在多任务间传递数据的，这当然是安全的。
参见 函数动态调用(https://gowalker.org/github.com/xgfone/go-tools/function) 和 方法的动态调用/派发(https://gowalker.org/github.com/xgfone/go-tools/method)。
代码见 Github。
IpcClient 中的 conn 是来源于 IpcServer 中的，见
func NewIpcClient(server *IpcServer) *IpcClient {
c := server.Connect()
return &IpcClient{c}
}
当调用 server.Connect() 时，会创建一个 channel，该 channel 就是 Connect 的返回值，在Connect方法中，专门启动了一个 Go 例程，接收这个 channel，然后去处理，并把处理结果发送回来，也就是说，client.conn <- string(b)是把参数传递过去进行处理，str := <- client.conn是取回处理后的结果。见 Connect 方法的实现：
func (server *IpcServer)Connect() chan string {
session := make(chan string,0)
go func (c chan string) {
for {
request := <- c
if request == "CLOSE" {
break
}
var req Request
err := json.Unmarshal([]byte(request),&req)
if err != nil {
fmt.Println("Invalid request format:",request)
}
resp := server.Handle(req.Method, req.Params)
b, err := json.Marshal(resp)
c <- string(b) //return result
}
fmt.Println("Session closed.")
}(session)
fmt.Println("A new session has been created successfully.")
return session
}
见上面第15行。