线程池
线程池是我们工作中常被用到的。他是一种线程的使用模式。线程过多会带来调度开销，进而影响缓存局部性和整体性能。而线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。这避免了在处理短时间任务时创建与销毁线程的代价。线程池不仅能够保证内核的充分利用，还能防止过分调度（百度百科）。
设定一个使用场景：API平台对外提供了一个接口，该接口内部需要调用其它接口或是业务层去处理一些事情，但是客户端需要快速得到响应，业务的处理过程将在后台被继续执行。使用Spring的项目中，一般会用ThreadPoolTaskExecutor来实现一个线程池，调用时，只需要注入taskExecutor，开启线程：
@Autowired
private ThreadPoolTaskExecutor taskExecutor;
public String doJob(){
// 参数处理
taskExecutor.execute(new Thread() {
public void run() {
// 处理业务
}
});
return "SUCCESS";
}
goroutine池
go的概念里应该不能叫做线程池了。程序中我们会开启一个goroutine去执行任务：
func startProcessor() {
go dosomething()
}
对于一定量的负载，这种使用方法是没有问题，但是当遇到一定大数量级的请求时，程序会不断的新建goroutine，结果就是程序崩了。
所以必须要去控制创建的goroutine的数量。
第一个简易的demo
- 创建一个测试的业务函数，给一个文件中写日志
func writeInfo() {
time.Sleep(1 * time.Second)
t := time.Now()
logFile, err := os.OpenFile("syslog.txt", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0766)
defer logFile.Close()
if err != nil {
panic(err)
}
infoLog := log.New(logFile, "[INFO]", log.LstdFlags)
// 随便往里面写点东西
infoLog.Print("time=" + strconv.FormatInt(t.UTC().UnixNano(), 10))
}
- 初始化一个带缓冲的channel，并使用select去监听通道的操作
var Queue chan int
func init() {
//初始化一个容量为20的'队列'
Queue = make(chan int, 20)
go startProcessor()
}
func startProcessor() {
// 利用select，当有任务添加到Queue中时，执行业务操作
for {
select {
case <-Queue:
fmt.Println("开始执行任务--------------")
writeInfo()
}
}
}
- 提供一个监听端口和路由，用于测试
func indexHandler(w http.ResponseWriter, r *http.Request) {
Queue <- 1
w.Header().Set("Content-Type", "application/json; charset=UTF-8")
result := "{\"msg\":\"SUCCESS\",\"code\":0}"
fmt.Fprintln(w, result)
}
func main() {
http.HandleFunc("/test/pool/", indexHandler)
http.ListenAndServe(":9000", nil)
}
笔记
假设队列容量在服务器性能范围内已经足够大，那么这种方式是具有一定作用的，他可以有效避免因为无限制创建goroutine而引起的程序崩溃。但是当请求接口的速率远比处理业务(writeInfo)的速率要大，而且请求的量级也很大，那我们所创建的channel就会达到他的极限，会有一部分请求被阻塞，客户端请求响应的时间也会增加。
比如demo中的channel的容量为20，使用jmeter并发100个请求，循环10次：
聚合报告.png
图形结果.png
可以看到偏移量已经很大了，并且平均响应时间也很长，要是再加大并发的样本数量，我的电脑就扛不住了。
