调度机制简介¶

在Linux平台中，神通数据库线程池有以下几种特殊的调度方式：

优先级连接调度¶

即使线程池对同时运行的查询数量进行了限制，由于连接的已启动事务将被放到队列末尾，线程池打开的事务数量仍然可能会保持较高。大量的已启动事务可能会加剧事务冲突，降低并发性能，因此引入了新的配置参数 THREADPOOL_HIGH_PRIO_TICKETS 解决这一问题。

每当由于没有可用线程、查询必须排队时，如果满足以下条件，则线程池会将连接置于高优先级队列中，tickets值递减：

1、连接中存在活跃事务

2、THREADPOOL_HIGH_PRIO_TICKETS 大于0

若以上条件不成立，连接将与 THREADPOOL_HIGH_PRIO_TICKETS 的初值一起放入普通队列。

每次线程池查找要处理的新连接时，都会首先检查高优先级队列，并仅在高优先级队列为空时从普通队列中选择连接。

这样做的目的是最大限度地减少服务器中活跃事务数量，让短期内运行过的事务有机会更快提交，在很多情况下高优先级队列的使用可以减少资源和锁的分配。

默认情况下，线程池总是将已经启动的事务中的事件放入高优先级队列中。

THREADPOOL_HIGH_PRIO_TICKETS 值为0的所有连接总是放在普通队列中， THREADPOOL_HIGH_PRIO_TICKETS 值越高，每个事务进入高优先级队列，并在其进入普通队列之前被提交的可能性更大。

在某些情况下，无论是作为多语句事务的一部分还是以自动提交模式执行，都需要优先处理特定连接的所有语句。反之亦然，有些连接可能需要无条件地为所有语句让步，使用低优先级队列。用户可以使用 THREADPOOL_HIGH_PRIO_MODE 参数进行配置。

当线程组由于活动线程达到上限，但是大多数工作线程正在等待连接(S1)已获得的锁，而连接(S1)尚未获得处理线程时，可能会限制线程池性能，极端情况下甚至会导致高并发死锁。

为了避免可能存在的死锁风险，等待锁的连接被标记为等待状态，不计入活跃线程数。但是这会使得线程池中的线程数量（活动和等待）增长，直到达到 THREADPOOL_MAX_THREADS 值。如果被等待的的连接成功进入线程池，线程池中并发运行的线程数量很大，从而导致性能不理想。

神通数据库通过限制低优先级队列来阻止这种情况，也就是说，如果工作线程过多，神通数据库不会从普通队列中启动新的事务，也不再创建新的线程，只处理来自优先队列的事件。

某些类型的工作负载（大型结果集，BLOB，慢速客户端）在网络I / O（套接字读取和写入）上可能会有较长的等待时间。

每当产生这种等待时，线程池会唤醒等待线程或创建一个新的线程来启动新的事件。