Akka.NET 的 Dispatcher 是调度策略抽象而非 ThreadPool 封装，它通过隔离队列、吞吐量控制和负载均衡等机制实现 Actor 级调度，配置变更需重启 ActorSystem 或显式指定才生效。
Dispatcher 在 Akka.NET 里不是 ThreadPool 的封装
Akka.NET 的 Dispatcher 是调度策略的抽象，不是对 ThreadPool 的简单包装。它决定 Actor 接收消息后由哪个线程执行，但背后可能用到 ThreadPool、TaskScheduler、甚至自定义线程池或同步上下文。默认的 ThreadPoolDispatcher 确实基于 .NET 的 ThreadPool，但它的行为受配置驱动，比如吞吐量限制、批处理逻辑、饥饿检测等，和裸用 ThreadPool.QueueUserWorkItem 完全不同。
-
ThreadPool是低层资源池，无队列隔离、无优先级、无 Actor 生命周期感知 - Akka.NET
Dispatcher为每个（或每组）Actor 分配专属消息队列，并控制“从队列取多少条连续执行”（Throughput）、“单次调度最大耗时”（ThroughputDeadlineTime）等关键参数 - 一个
Dispatcher实例可被多个 Actor 共享，但它们的消息队列是隔离的；而ThreadPool是全局共享，任务之间无隔离保障
怎么配 Dispatcher 才不意外掉进 ThreadPool 陷阱
常见误操作是以为改了 ThreadPool.SetMinThreads 就能解决 Actor 阻塞问题——其实没用。Akka.NET 不直接调用 ThreadPool API，而是通过 Task.Run 或 ThreadPool.UnsafeQueueUserWorkItem（取决于实现），且受自身配置压制。真正起作用的是 akka.actor.default-dispatcher 下的参数：
-
throughput = 5：默认一次最多处理 5 条消息，避免单个 Actor 长时间独占线程 → 若 Actor 内有同步 IO，这个值太小会放大延迟 -
thread-pool-executor.fixed-pool-size = 20：仅对FixedThreadPoolExecutor类型有效；默认的ThreadPoolExecutor是弹性伸缩的，上限由max-threads控制 -
attempt-teamwork = on（默认开启）：允许空闲线程主动“偷”其他线程队列里的消息，缓解负载不均 —— 但这会打破 Actor 消息顺序假设（仅限同一 Actor）
akka.actor.default-dispatcher {
type = "ThreadPoolDispatcher"
throughput = 10
thread-pool-executor {
core-pool-size-min = 8
core-pool-size-max = 64
max-threads = 128
}
}
什么时候该换 Dispatcher 而不是调大 ThreadPool
当出现以下现象时，大概率不是线程池不够，而是调度模型不匹配：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- Actor 日志显示消息积压（
Mailboxsize 持续 > 100），但 CPU 很低 → 可能是throughput过小 + 消息处理快，导致频繁线程切换开销 - 部分 Actor 响应明显变慢，其他却正常 → 某些 Actor 处理逻辑含同步阻塞（如
File.ReadAllText），应单独配BlockingIODispatcher，而不是全局扩ThreadPool - 使用
async/await后反而更卡 → 默认 Dispatcher 不支持 true async 调度（即不会释放线程等待 await 完成），需配TaskDispatcher或启用akka.actor.allow-java-serialization = off配合AsyncAwaitSupport
自定义 Dispatcher 和 ThreadPool 的边界在哪
你可以写一个继承 MessageDispatcher 的类，但绝大多数场景不需要。真正要动手的只有两种情况：
- 需要绑定到特定
SynchronizationContext（如 WinForms/WPF UI 线程）→ 用CurrentSynchronizationContextDispatcher，它根本不走ThreadPool - 必须复用已有线程池（比如已用
ConcurrentExclusiveSchedulerPair管理后台任务）→ 通过TaskSchedulerBasedEventExecutor包装，而非直接塞进ThreadPool
硬把 ThreadPool 的 QueueUserWorkItem 拉进 Dispatcher 实现，会丢失 Akka.NET 的监控（如 mailbox size 统计）、熔断机制和配置热更新能力。别为了“可控”放弃框架设计契约。
最常被忽略的一点：Dispatcher 配置变更后，**已启动的 Actor 不会自动迁移**，必须在 ActorSystem 重启时生效，或显式用 Props.WithDispatcher 为新 Actor 指定。
