其他数据库做不到这样，那是它们没有实现全链路异步化，这就是 lealone 的高明之处啊，也是 lealone 的核心竞争力。ClientScheduler 线程只处理非阻塞网络 IO，而 GlobalScheduler 线程不会因为锁而被阻塞，甚至不会一直陷在慢查询里面。能处理的并发请求数跟调度线程的数量无关，如果把并发请求数或连接数跟线程数绑定，那才是最大的错误。java 的虚拟线程已经详细压测过，哪怕用在 jdbc 客户端的场景都没有多少价值。 //@犽你怎么了:线程数等于 CPU 核心数的结论成立前提是任务不发生阻塞，这在数据库负载中通常不成立。数据库查询普遍受 IO、锁和网络延迟影响，CPU 利用率并非主要瓶颈。因此更合理的设计是保持有限的内核线程数，同时通过用户态线程、异步 IO 或虚线程来承载高并发请求，而不是简单限制并发线程数量。

@zhh-4096

假设 cpu 核数是 n，总任务数 > n，如果保证运行这些任务的线程不会阻塞，那么只需要启动 n 个线程就够了。压测的结果也验证了这一点，如果开启的线程数 > n，不但没有效果，反而因为线程切换有负面影响。基于这个结果，lealone 的 ClientScheduler 线程和 GlobalScheduler 线程默认都是 cpu 核数。 ​​​