MySql.Data中new Thread与ThreadPool对比：ThreadPool触发死锁问题咨询

1. MySql.Data 官方库的实现缺陷 #

你使用的 Oracle 官方 MySql.Data 类库中，同步方法 MySqlConnection.Open 的底层实现采用了异步转同步的错误写法：内部实际调用异步方法 OpenAsync 后直接用 .Wait() 或 .Result 阻塞等待执行结果，且内部所有异步调用均未添加 ConfigureAwait(false) 配置，会默认捕获当前执行上下文用于异步执行完成后的恢复调度。

2. 线程池与手动创建线程的调度逻辑差异 #

• 手动 new Thread 创建的是独立前台线程，不存在同步上下文捕获绑定逻辑：Open 内部的异步任务执行完成后，不需要回到调用 Open 的原线程就能继续执行剩余逻辑，不会出现互相等待的情况，因此可以正常运行。
• 通过 ThreadPool.QueueUserWorkItem 提交的任务运行在线程池工作线程上：线程池线程默认会携带同步上下文，Open 方法内部捕获上下文后，异步任务执行完成需要回到原调用线程恢复执行，但此时原线程已经被 .Wait() 阻塞，正在等待异步任务返回结果，二者形成循环等待的死锁。

为什么调大最小线程数没有效果 #

你调整线程池最小线程数为200只能解决线程池饥饿问题，但当前死锁本质是同一线程的执行流互相等待，和线程数量无关：每个卡在 Open 方法的线程池线程都在占着线程资源等待内部异步任务返回，而内部异步任务又在等待被占住的线程空闲才能恢复执行，即使线程池有更多空闲线程也无法打破这个等待链。

• 优先替换为 MySqlConnector 类库：该库是社区维护的高性能 MySQL 驱动，同步 Open 方法不存在异步转同步的错误实现，完全兼容 MySql.Data 的公共 API，替换后不需要修改业务代码就能解决死锁问题。
• 若必须使用官方 MySql.Data 库：将所有数据库连接逻辑改为全异步实现，调用 OpenAsync().ConfigureAwait(false) 替代同步 Open 方法，避免异步转同步的阻塞行为。

内容的提问来源于stack exchange，提问作者Ted