Go协程阻塞太长时间会发生什么？

https://www.cnblogs.com/linguanh/p/9510746.html
https://juejin.im/post/6844903846825705485

线程调度由OS全权负责，线程遇到一些系统调用（比如I/O）时，可能阻塞，也可能立即返回。

那么Go协程如果阻塞太长时间，会发生什么？

本文简单讲讲Go的GMP调度模型以及一个特殊场景。

GMP各自的角色

• G (Goroutine)，协程，每次代码中使用 go 关键词时候都会创建的对象
• M (Work Thread)，工作线程
• P (Processor)，代表一个处理器（不是物理处理器），又称上下文

GMP之间的基本关系

GMP模型通过任务队列之间的切换与G的上下文恢复实现协程调度。

• 队列分为两种：全局队列，P自身的工作队列
• 协程底层通过线程实现，真正做工作的是M，比如M.execute(job),这里的job是从队列（队列里都是G）里取出的任务。
• 上面提到M取任务，那么M从哪个队列取？答案是：M总是与一个P绑定

小结：GMP模型以任务队列为主体，队列内的对象是G，队列的维护者（上下文切换）是P，执行者是M，队列顺序执行。具体的任务切换策略暂略。

Go协程阻塞太长时间会发生什么？

协程的切换时间片是10ms，也就是说 goroutine 最多执行10ms就会被 M 切换到下一个 G。这个过程，又被称为 中断，挂起

Go协程遇到异步系统调用是怎么做的？

假设M的任务队列里有G1、G2，G1遇到异步系统调用时，M会先执行G2，G1异步返回时，插入回M的任务队列尾部。

Go协程遇到同步系统调用是怎么做的？

假设M的任务队列里有G1、G2，G1遇到同步系统调用时，G1会被调度到另外一个完全空闲的M上执行（如果不存在，则先创建一个新的M），G1同步返回时，插入回M的任务队列尾部。

工作窃取

当一个M的任务队列空闲时，可以从其他M或全局任务队列窃取任务。窃取优先级是：

• 其他M
• 全局

扩展

前面说的都是GMP调度，实际上是基于线程的用户层调度。想象以下场景：

多机器 * 多进程，都运行一个goroutine，这个协程中间有一个阻塞式操作（select … for update)。
如果A进程拿到mysql的锁，A没有rollback/commit 的情况下，B想拿锁拿不到，在10ms后B的这个协程会被判定为阻塞（由于全局队列与所有M的任务队列里，仅有一个协程任务，这时协程调度就退化为线程调度）。

判定阻塞的原理：

• go程序启动时会首先创建一个特殊的内核线程 sysmon，用来监控和管理，其内部是一个循环：

• 记录所有 P 的 G 任务的计数 schedtick，schedtick会在每执行一个G任务后递增

• 如果检查到 schedtick 一直没有递增，说明这个 P 一直在执行同一个 G 任务，如果超过10ms，就在这个G任务的栈信息里面加一个 tag 标记

• 然后这个 G 任务在执行的时候，如果遇到非内联函数调用，就会检查一次这个标记，然后中断自己，把自己加到队列末尾，执行下一个G

• 如果没有遇到非内联函数 调用的话，那就会一直执行这个G任务，直到它自己结束；如果是个死循环，并且 GOMAXPROCS=1 的话。那么一直只会只有一个 P 与一个 M，且队列中的其他 G 不会被执行！

如何优化以上场景？
Mysql 8.0支持select … for update nowait

当A事务没有rollback/commit 的情况下，B事务试图取锁会直接返回错误。伪代码如下：

//业务代码前置的试图取锁
if !util.GetLockFromLooperLocks("LOCK_DATA_LOOPER", "UPDATE_TASK_STATUS_ACCESS", tx) {
	util.LooperLocksCommitOrRollBack(tx, -1)
	time.Sleep(60 * time.Second)
	continue

//取锁的过程
func (util *Util) GetLockFromLooperLocks(loop_name string, lock_name string, tx *sql.Tx) bool {
	if tx == nil {
		tars.TLOG.Error("tx is nil")
		return false
	}
	sql_str := "select * from running_loop_locks where loop_name=? and lock_name=? for update nowait"
	results, err := tx.Query(sql_str, loop_name, lock_name)
	defer results.Close()
	if err != nil {
		tars.TLOG.Error(fmt.Sprintf("loop_name: %s,get lock error: %s", loop_name, err))
		return false
	}
	for results.Next() {
	}
	return true
	}
}

//取锁失败则回滚
func (util *Util) LooperLocksCommitOrRollBack(tx *sql.Tx, ret int) (int, error) {
	if tx == nil {
		return 1, nil
	} else if 0 == ret {
		tx.Commit()
	} else {
		tx.Rollback()
	}
	return 0, nil
}

以上代码利用了mysql8.0 对 select …from … for update进行的扩展——开始支持for update nowait 和for update skip locked

NOWAIT：表示无法获取到锁时直接返回错误，不用等待 innodb_lock_wait_timeout 的时间，再返回报错，这样就减少了线程的阻塞时间。