线程池

线程池是我们工作中常被用到的。他是一种线程的使用模式。线程过多会带来调度开销，进而影响缓存局部性和整体性能。而线程池维护着多个线程，等待着监督管理者分配可并发执行的任务。这避免了在处理短时间任务时创建与销毁线程的代价。线程池不仅能够保证内核的充分利用，还能防止过分调度（百度百科）。

设定一个使用场景：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() {
    //初始化一个容量为10的'队列'
    Queue = make(chan int, 10)
    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)
}

笔记

假设队列容量在服务器性能范围内已经足够大，那么这种方式是具有一定作用的，他可以有效避免因为无限制创建goroutine而引起的程序崩溃。但是当请求接口的速率远比处理业务(writeInfo)的速率要大，而且请求的量级也很大，那我们所创建的channel就会达到他的极限，会有一部分请求被阻塞，客户端请求响应的时间也会增加。比如demo中的channel的容量为10，当使用jmeter并发20个请求，一部分会很快的执行并返回结果，但是其余请求会被阻塞，直到有通道腾出来去接收他们。