线程池不直接参与分片路由切换，但通过与路由生命周期协同设计（如独立调度池、读写锁、版本隔离线程池、连接池联动及指标监控），保障元数据刷新、新旧规则并行及连接优雅下线过程的稳定性与平滑性。
线程池本身不直接参与分片路由表的切换，但它在网关层支撑路由元数据刷新、连接重建和请求过渡阶段的稳定性。真正的“平滑”来自线程池与路由生命周期的协同设计：避免刷新期间任务堆积、阻塞或丢失，同时保障新旧分片规则并行生效窗口内请求不中断。
路由元数据刷新需避开线程池阻塞点
ShardingSphere-JDBC 或自研网关中，分片路由规则（如 sharding-algorithm、actual-data-nodes）常从配置中心（Nacos/Apollo）动态加载。若刷新逻辑写在同步初始化路径中，且依赖数据库查询（如查 sys_db 表），就容易卡在 JDBC 连接获取或 SQL 执行上——尤其当目标库正在做分片迁移时响应变慢。
建议做法：
- 将路由元数据加载逻辑放入独立的调度线程池（非 I/O 密集型的共用业务池），配置 CallerRunsPolicy，使超载时由触发刷新的管理线程（如 Spring 的
@Scheduled）本地执行，便于快速失败或重试 - 加载过程加读写锁（如
ReentrantReadWriteLock），读锁开放给路由计算线程，写锁仅限刷新线程持有，确保ShardingDataSource中targetDataSources映射更新原子性 - 避免在
ShardingDataSource构造或getConnection()中做实时元数据拉取；应预加载+定时异步刷新+版本比对机制
新旧分片规则共存期靠线程池隔离流量
平滑扩容（如从 4 分片扩到 8 分片）往往采用双写+灰度路由策略：一部分请求按旧规则走，一部分按新规则走，中间有数小时甚至数天的并行期。此时不能让所有请求挤在同一个线程池里排队，否则旧规则慢会导致新规则请求也被拖慢。
立即学习“Java免费学习笔记（深入）”；
推荐方式：
- 为不同分片版本（如
v1、v2）配置独立的轻量级线程池（ThreadPoolTaskExecutor），核心线程数按预期流量比例分配 - 在网关路由 Filter 中识别请求所属分片版本（通过 header、path 前缀或用户 ID 哈希），将任务提交至对应线程池，实现天然的流量分组与资源隔离
- 配合 DiscardOldestPolicy + 小容量队列（如
ArrayBlockingQueue(5)），让高时效性请求（如订单创建）优先使用新分片通道，老通道只承接低优日志或补单类请求
连接池与线程池联动防止“假平滑”
分片切换后，旧数据源（DruidDataSource）需优雅下线，但若业务线程池仍在向其提交查询任务，就会出现连接超时或拒绝异常——表面看服务没挂，实则部分请求已不可用。
关键控制点：
- 在
ShardingDataSource切换时，同步调用旧DruidDataSource.close()，并设置removeAbandonedOnMaintenance和timeBetweenEvictionRunsMillis加速空闲连接回收 - 线程池拒绝策略统一设为 AbortPolicy，并在
RejectedExecutionException捕获逻辑中检查当前是否处于路由切换窗口（如标记switchingFlag.get() == true），若是则自动降级为本地缓存路由或返回 503 + Retry-After - 前端网关（如 Spring Cloud Gateway）启用虚拟线程支持后，可将每个分片路由的下游调用包裹在
VirtualThreadCarrier中，避免因某一分片抖动导致整个网关线程池被阻塞
监控与回滚依赖线程池指标闭环
平滑切换不是一次操作，而是一组可观测行为。线程池运行指标是判断切换是否成功的最直接信号之一。
必须采集并告警的维度：
- 活跃线程数突增：说明新分片连接未就绪或路由算法异常，导致大量请求重试
- 队列积压长度持续 > 80%：反映下游分片节点处理能力不足，需触发自动扩缩容或切回旧规则
- 拒绝任务数非零且上升：结合路由版本标签，定位是哪一组分片通道出问题，支持秒级回滚
- 将线程池名（如
shard-v2-executor）作为 Prometheus 标签上报，Grafana 中可按分片版本对比 P95 延迟与错误率
