C#与Go并发模型深度对比：Task/async-await vs GMP调度器剖析

这几年我见过太多团队为了“服务器高并发”把并发模型当成信仰来吵。搞 C# 的觉得 Task 和 async/await 已经够优雅，看到 Go 那坨go func()加 channel 就皱眉，觉得像玩具；写 Go 的又嘲讽 C# 的 async/await 状态机、同步上下文、线程池饥饿这些概念太绕，还是 goroutine 根正苗红。说实话，两边撕来撕去，大多数争论都停在语法层，没有触及一个问题：运行时到底用什么单位调度，怎么分配 CPU 时间，如何对付 IO 阻塞？这篇文章我就直接把 C# ThreadPool / Task / async/await 和 Golang GMP 这条主线拆开，把每一层的设计意图、典型坑位、实测气质讲透。读完你至少能在下一次高并发服务改造之前，先在一个完整的模型里思考问题，而不是靠网络上的碎片结论。

1. 为什么拿 C# 和 Go 放在一起比？

1.1 这个对比解决什么问题

很多项目都面临同一个现实：既有 C# 的基础设施（上位机、WinForms 老系统、后端 API），又有 Go 的新服务（网关、采集器、云原生组件）。语言边界一旦混起来，原来在生态里亲切的并发写法到了对方语言里就变了个味——你以为在写“同一件事”，其实调度器在背后做了完全不同的动作。

我举个最常见的错位感：在 C# 里写await Task.Delay(100)，直觉告诉你“这 100 毫秒线程被释放了”；在 Go 里写time.Sleep(100 * time.Millisecond)，直觉告诉你“这个 goroutine 暂时睡下了，不等线程”。两种直觉都对，但**“释放线程”和“睡下 goroutine”是两个层面的概念**。C# 的await是把“线程控制权”交还给线程池，Go 的sleep只是让运行时把协程挂到定时器等待队列中，仍然是同一个线程继续跑其他 goroutine。你把两种直觉放在同一套系统里调试时，性能瓶颈的本质就会变得非常模糊。

这个对比的核心价值，不是判断谁好谁坏，而是搞清楚三件事：

1. 并发单位到底是什么：C# 的 Task 是逻辑任务，goroutine 是原生协程。
2. 调度器的资源视图是什么：C# 线程池以“线程”为底座，Go 以“P（处理器）和本地队列”为核心。
3. 异步 IO 和阻塞 IO 如何避免浪费线程：两边处理方式完全不同，但目标一样。

1.2 哪些人适合看这篇文章

如果你正在做以下事情，这篇文章能直接省你几个晚上的爬坑时间：

• 从 C# 转 Go，或者从 Go 转 C#，想快速建立并发模型迁移坐标；
• 用 C# 写上位机、工业通信网关，开始接触大量异步 IO，想要更稳的并发框架；
• 用 Go 写微服务，遇到 CPU 核数很多但 goroutine 调度依旧“不对劲”的案例；
• 或者只是好奇async/await和 goroutine 在运行时究竟有什么不同，想做一次系统性的知识归档。

我下面不会只讲语法糖，而是把两者放到“线程调度、内存开销、阻塞处理、错误传播”四个维度上做交叉对比。没有统一结论，但你会有自己的结论。

2. C# 的并发底座：ThreadPool、Task、async/await 是怎么嵌套的

2.1 线程池：全局队列和“补线程”策略

C# 的并发底层不是Task，而是ThreadPool。ThreadPool维护了一组线程，所有任务都会被投递到一个全局工作队列中。线程池内置了 IO 完成线程和工作线程两类，前者用于异步 IO 回调，后者用于 CPU 密集型任务。

线程数并不是固定的。CLR 内部有一个“爬山算法（hill-climbing）”在动态调整线程数量：它会持续观测任务吞吐量、线程等待时间、CPU 使用率，然后决定是否增开线程。这个设计非常像 PID 控制器——他不想让线程数长期处于过饱和状态，也不想让队列因为线程太少而堆积。

所以你在生产环境偶尔会看到线程池线程数在几十到几百之间波动，这是正常现象。真正要警惕的是两个极端：线程数持续上涨到接近上限但 CPU 使用率不高（典型的 io 阻塞 + 同步等待），或者线程数长期趴在最小值但任务积压（典型的上游响应突然变慢）。

提示：别把 ThreadPool 线程数设置得太太随意。除非你已经用dotnet-counters或ThreadPool.GetAvailableThreads()验证过饥饿，否则盲目调大SetMinThreads只会把排队问题变成上下文切换开销。

2.2 Task：一个轻量化的执行单元

Task是对线程池工作项的封装，但它不是一个线程。它包含状态、执行回调、取消令牌、异常列表、调度器引用等字段。一个新的Task在默认情况下会被投递到全局队列，由任意一个空闲线程池线程取走执行。

从创建开销上看，Task比直接new Thread()小得多。线程默认栈空间是 1MB（Windows），任务本身可能只有一百字节左右。也就是说，同样一台 4GB 内存的服务器，如果线程上限撑死几千个，用Task可以短时间内处理数十万次异步调用。这也是为什么很多人说“线程不能随便 new，但 Task 可以随便 new”——这句话是对的，但前提是Task执行体内不能有同步阻塞，否则异步轻量化的意义就被同步等待吃掉了。

另外，Task还提供了Task.Run和直接构造两种不同路径：

• Task.Run(Action)会把委托投递到线程池，由线程池线程执行；
• new Task(Action, TaskCreationOptions.LongRunning)会为这个任务单独创建一个专用线程，适合长时间运行的监听循环或后台服务。

我见过不少同事在“消息队列消费者”这种场景里用普通任务包一个while(true)，结果线程池被这种长期占据线程的任务占满，其他轻量任务全部排队。这属于典型的任务类型选错。

2.3 async/await 的状态机并没有想象中神秘

async/await是编译器在Task之上做的一层语法糖，本质是把一个异步方法编译成一个状态机结构。每次await，方法就把当前执行位置、局部变量、同步上下文保存到状态机中，然后把不完整的Task返回给调用者。当被等待的任务完成时，状态机会通过线程池回调继续执行后续代码。

这个设计里最关键的一个点是：await不保证“线程不变”，只保证“逻辑连续”。默认情况下，如果一个SynchronizationContext存在（比如 WinForms、WPF、旧 ASP.NET），await 后面的代码会尝试回到原来的上下文线程执行；如果没有上下文（比如控制台应用、ASP.NET Core），await 恢复时的线程是哪个空闲线程池线程都行。

我在上位机项目里踩过比较经典的坑：在 WinForms 里写了一个await Task.Run()然后直接访问 UI 控件，如果Task.Run内部因为某个同步上下文配置不对，恢复逻辑跑到后台线程，就会在UI 线程访问控件上抛异常。虽然ConfigureAwait(false)可以强制避免回到 UI 上下文，但这句话不能乱用——它会让 await 后的代码在任意线程池线程上执行，适合库代码，不适合 UI 层。

2.4 SynchronizationContext：GUI 与 ASP.NET 的特别之处

SynchronizationContext是 C# 异步模型里最容易忽视、也最影响跨层设计的东西。它抽象了“代码应该继续在哪个线程执行”的规则。WinForms 的上下文把回调继续调度到 UI 线程；WPF 的DispatcherSynchronizationContext做类似事情；ASP.NET Core 里通常没有上下文，因为框架本身已经多线程化了。

理解这东西的意义在于：如果你在写一个可以被 WinForms、控制台、服务端多重环境调用的底层库，不要依赖 SynchronizationContext 自动存在。库方法内部一律用ConfigureAwait(false)避免把上层上下文带进底层，同时不要假设 await 之后的线程还是原线程。这也是为什么现在很多 C# 库代码里到处都是ConfigureAwait(false)的原因之一——不是洁癖，是防呆。

3. Golang 的 GMP 调度器到底在调度什么

3.1 G、M、P 三件套

Go 的 GMP 三个字母分别指：

• G（Goroutine）：一个协程对象，包含栈、指令指针、状态。初始栈很小，Go 1.x 里面大概是 2KB，随后按需扩容到最多 1GB，所以创建十几万个 goroutine 在内存上是可行的；
• M（Machine）：一个操作系统线程。M 负责真正在 CPU 上执行 G。Go 运行时在启动时会按需创建 M，上限取决于系统限制；
• P（Processor）：一个逻辑处理器，是调度器的工作单元。P 持有本地可运行队列，数量由GOMAXPROCS决定，默认是 CPU 逻辑核数。

不要被名字误导，P 并不是“物理 CPU 核心”，而是调度器中用来控制并行度的抽象。一个 M 要执行 G，必须先绑定一个 P；绑定 P 的 M 才有资格调度本地队列里的 G。P 的数量决定了同一时刻最多有多少个 goroutine 在同时运行在用户态逻辑上。

每次go func()调用，运行时都会创建一个 G，并优先放到当前 P 的本地队列；如果本地队列满了，才放入全局队列。调度器会不断从本地队列拿 G 给绑定的 M 执行，执行完后再拿下一个。这个设计有点像一个餐厅出菜：P 是厨师岗位，本地队列是每个厨师的备菜盘，全局队列是食材总库，M 就是正在切菜的厨师本人。

3.2 工作窃取和全局队列的平衡艺术

只靠本地队列会导致某些 P 过载而另一些 P 空闲。所以 Go 调度器实现了工作窃取（work stealing）：当一个 P 的本地队列为空时，它不会立刻让自己绑定的 M 休眠，而是会随机挑一个其他 P，从它的本地队列尾部偷一半左右的任务过来执行；如果所有 P 的本地队列都是空的，才去看全局队列。

这个机制让 Go 调度器在多核场景下天然具备负载均衡能力。它和 C# 线程池全局队列最大的区别在于，Go 更多是“按局部分配、按需要偷取”，C# 则是“所有任务丢到全局池，线程各自取，存在一些本地工作窃取但协作模型不同”。实际效果就是：在同样的 CPU 密集任务下，Go 程序很少出现“某个核心忙死、其他核心闲着”的严重倾斜。

不过这里有个微妙的点：全局队列不是完全没用的。调度器每隔一段时间会检查全局队列是否有积压，可能因为某些 G 被阻塞过久，需要重新平衡。这种设计在“大量短生命协程”场景下表现非常好，但在“极少量重调度”场景下，work stealing 带来的随机性和内存缓存不友好也可能成为小瓶颈。

3.3 抢占：不是想跑多久就跑多久

Go 的抢占机制经历过一个很关键的变化。Go 1.14 之前，调度器主要靠协作式抢占：goroutine 在进入函数调用时通过编译器插入的栈检查（stack check）来确认是否要被抢占，如果一个 goroutine 里写了死循环且不调用任何函数、不触发任何调度点，其他 goroutine 可能一直无法运行，整个程序“假死”。

Go 1.14 之后引入了基于信号的异步抢占，操作系统定时发送 SIGURG 给运行中的 M，M 在处理信号时检查当前 G 是否运行超时，然后把它切换到调度执行队列。这样即使一个 G 疯狂循环，调度器也能强制把它踢下来给别的 G 让出时间片。

但异步抢占不是万能的。某些 C 库调用、汇编代码片段、长时间运行的系统调用期间，信号处理可能无法及时打断。你在真实生产里还是会遇到“某些 goroutine 一直占着 CPU 导致 GC 停顿变长”的情况。排查时，不要只想到“这函数太密了”，还要看是不是进入了不可抢占的系统调用区域。

3.4 网络轮询：让 M 不至于被打满

Go 调度器对网络 IO 也做了专门优化。标准库里的网络读写走的是非阻塞 IO，底层由netpoller统一管理。当一个 goroutine 发起 socket 读操作但数据还没到，运行时不会让 M 阻塞，而是把 G 挂到pollWait列表里，M 继续去执行其他 G。等到 epoll/kqueue 上报这个 fd 可读，运行时才把一个 G 塞回队列。

对比 C# 的 async/await + SocketAsyncEventArgs，底层的 OS 异步 IO 模型不一样，但用户态感知非常接近：你写conn.Read，代码看起来是阻塞的，实际上在等待期间，这个 goroutine 所在的 M 并没有闲着，它转去跑了其他 G。这就是为什么 Go 的语言级并发模型能让“同步风格代码”达到近似异步的性能——它把“等待”这件事从线程级搬到了调度器内部，代价是运行时复杂度更高。

4. 对比表：调度单位、内存开销、阻塞处理、错误传播

4.1 调度单位的粒度与开销

为了不空谈，我先给一张直接对比表：

这里要展开说说“代码跑在复用线程的栈上”的含义。C# 里每个线程是一个操作系统线程，栈是固定的；Task 的执行不会单独分配栈，而是用当前线程池线程的栈空间。如果你在Task.Run内部写了一个深度递归函数，它依然会消耗那个线程的栈——这和 Go 动态增长的 goroutine 栈在异常行为上很不一样。Go 的栈扩容是有代价的：扩容到新栈后需要把所有指针从旧栈拷贝到新栈，并对栈帧做一些修正，这个过程如果频繁触发，GC 暂停会略长。

4.2 阻塞与非阻塞：谁在“假装不累”

这是两套模型差异最明显的地方。

在 C# 里，如果你用Thread.Sleep、Task.Wait()、lock等同步阻塞方式，你的线程就是真的在等，线程池线程被占住，可并行度下降。正确做法是用await Task.Delay、await SemaphoreSlim.WaitAsync这种非阻塞等待，让线程回池。

在 Go 里，goroutine 阻塞时，它所在的那个 M 不一定阻塞。比如你写time.Sleep(100ms)，调度器会把 G 放入定时器队列，M 继续执行其他 G；channel读写阻塞时，G 会被挂到 channel 的 wait queue，M 也不会一直空转。这种设计让 Go 程序员可以使用同步写法，却不一定付出“线程阻塞”的代价。

但“不一定”三个字很重要。如果 goroutine 阻塞在一个系统调用（比如os.ReadFile读本地磁盘、syscall调用）上，它的 M 可能确实会阻塞，此时 Go 运行时会把这个 M 丢下，换一个新的 M 来接管 P。这种 handoff 机制避免了 P 空闲，但会造成线程的创建和销毁，成本并不为零。在极端场景（大量磁盘同步 IO），Go 程序的 OS 线程数依然会涨。所以工业界仍然建议在 Go 高 IO 场景里直接用read/write的异步封装，或者尽量用标准库提供的os.File内部异步化路径，而不要自己包一层裸系统调用。

4.3 取消、超时、异常传播：两套控制哲学

C# 的 async/await 里，取消是显式的，通过CancellationToken贯穿所有 IO 操作。一个 Task 被取消，只是让 await 抛OperationCanceledException，调用方可以捕获、继续、清理资源。异常传播走的是异常栈：await 前一个方法被 try/catch 捕获，整个链路可以顺着状态机往回穿。

Go 里更多用的是context.Context。通过context.WithTimeout或context.WithCancel把取消意图扩散给下游 goroutine，但 goroutine 本身必须主动检查ctx.Done()，否则取消不会自动生效。注意 Go 没有“异常栈”传递，panic 默认会终止整个进程，除非 goroutine 自己defer recover()。这也意味着 Go 里并发任务错误传播往往要依赖显式返回 error，或者通过 channel 把错误汇总给主协程。

哪种更舒服完全取决于团队习惯。C# 的异常机制在复杂异步链路里追踪起来更直接，但代价是异常处理和状态机编译器生成的代码更复杂。Go 的显式 error 虽然繁琐，但每个协程的错误路径都是图片化的，梳理时非常透明。

4.4 并发原语各自的“舒适区”

从日常编码角度我总结一句话：

• C# Task/async-await 的舒适区在**“异步 IO + 业务链路编排”**，比如 Web API、消息处理、上位机采集调度，代码可以保持线性逻辑，同时不卡线程。
• Go GMP 的舒适区在**“海量轻量任务 + 内部通信”**，比如网关、日志采集、爬虫框架、分布式代理，go func的开销低到你很容易写出几万并发任务。

反过来讲，如果你在 C# 里做海量短任务但没用好异步，大量同步阻塞会让线程池线程不断膨胀；如果你在 Go 里做复杂业务编排又迷信 goroutine 无成本，最终就是一堆无法追踪的协程泄漏和 context 传得满天飞。

适合那种工程才会让你选对模型，而不是语言决定一切。

5. 用同一个“批量任务 + 超时”例案把两套直接跑起来

5.1 C# 版本：SemaphoreSlim + CancellationToken

我拿一个常见的批量远程调用场景做演示：假设要并发拉取 1000 个设备状态，但担心同时把下游打爆，需要限制并发为 20，整体超过 5 秒就取消。

using System.Diagnostics; var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5)); using var semaphore = new SemaphoreSlim(20); var tasks = Enumerable.Range(1, 1000) .Select(async id => { await semaphore.WaitAsync(cts.Token); try { return await FetchDeviceStatusAsync(id, cts.Token); } finally { semaphore.Release(); } }); try { var results = await Task.WhenAll(tasks); // 处理 results } catch (OperationCanceledException) { Console.WriteLine("超时或取消"); } static async Task<string> FetchDeviceStatusAsync(int id, CancellationToken ct) { await Task.Delay(50, ct); // 模拟网络 IO return $"device-{id}:ok"; }

这段代码关键点在于WaitAsync而非同步Wait。SemaphoreSlim的WaitAsync在限流令牌未释放时不会阻塞线程，而是挂起一个Task，等待释放后再恢复。整体 1000 个任务全部投递到线程池，但同一时刻最多只有 20 个在执行。CancellationToken贯穿到了Task.Delay，超时后所有未完成任务会统一抛取消异常，并被Task.WhenAll聚合成一个异常。

注意Task.WhenAll的异常聚合行为：它会把所有任务里的异常打包成一个AggregateException。如果你在循环里每个任务内部直接 catch，那就不会看到聚合。用异步代码时，尽量把异常处理放在任务内部边界，而不是依赖外层 catch，否则排查时经常看不清是哪个设备挂了。

5.2 Go 版本：带缓冲 channel + sync.WaitGroup + context

同样的场景，Go 版可以用带缓冲的 channel 做限流，用context.WithTimeout做整体超时：

package main import ( "context" "fmt" "sync" "time" ) type DeviceStatus struct { ID int Data string Err error } func main() { ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() const total = 1000 const limit = 20 jobs := make(chan int) results := make(chan DeviceStatus, total) var wg sync.WaitGroup for i := 0; i < limit; i++ { wg.Add(1) go func() { defer wg.Done() for id := range jobs { select { case <-ctx.Done(): // 超时直接返回，任务被丢弃 return default: } data, err := fetchDeviceStatus(ctx, id) results <- DeviceStatus{ID: id, Data: data, Err: err} } }() } go func() { for id := 1; id <= total; id++ { select { case jobs <- id: case <-ctx.Done(): close(jobs) return } } close(jobs) }() go func() { wg.Wait() close(results) }() okCount := 0 for r := range results { if r.Err != nil { fmt.Println("失败:", r.ID) continue } okCount++ } fmt.Println("成功数量:", okCount) } func fetchDeviceStatus(ctx context.Context, id int) (string, error) { select { case <-ctx.Done(): return "", ctx.Err() case <-time.After(50 * time.Millisecond): return fmt.Sprintf("device-%d:ok", id), nil } }

Go 版本里你会看到另一种哲学：主流程一直在for r := range results接收结果，而生产者和 worker 都是独立的 goroutine。sync.WaitGroup负责等所有 worker 退出，关闭resultschannel；超时通过ctx.Done()在 worker 循环里主动检查，而不是依赖于某个框架强制取消。这段代码初看不简洁，但它把“结束条件”完全显式化，谁该由谁close、什么时候退出，全都在代码面上可审计。

5.3 两者运行时表现和改造点

从行为结果看，两种实现都能达到同样的目标：并发 20、5 秒超时、稳定处理 1000 任务。但如果你用dotnet-trace或者 Go pprof 去观察，会发现非常有意思的区别：

• C# 版本在线程池里的工作项大多数时间处于“等待 SemaphoreSlim / 等待 Task.Delay”状态，线程池线程往往会动态增长到几十个，但 CPU 占用并不高。
• Go 版本默认 GOMAXPROCS 是 8 的话，只有 8 个 P 并发调度 worker goroutine，但每个 worker goroutine 内部可以连续处理多个任务，而不是像 C# 那样每个任务拆成一个状态机等待。

也就是说，C# 的调度颗粒度更细（每个 await 都是调度点），Go 的调度颗粒度受队列和 worker 结构影响，是任务级和消息级混合的。如果你把limit从 20 调到 200，C# 的SemaphoreSlim会让 200 个状态机同时等待恢复；Go 的 200 个 goroutine 只是增加了 channel 队列长度，并不会直接增加 200 个活跃调度单位。这也是为什么同样功能在 Go 里“默认更抗压”的体感来源。

不过换个角度看，C# 的Task.WhenAll和 LINQ 式组合让“按返回值重新组织数据”非常自然；Go 的 channel 分发需要手写更多关闭和错误汇总逻辑。真实项目里，团队更熟悉哪个模型，往往比理论吞吐量更重要。

6. 性能调优和排错经验：这两套系统各自的坑

6.1 C# 线程池饥饿和死锁：最容易被异步写坏的一类问题

C# 异步代码最常见的生产故障不是“CPU 高”，而是“线程池饥饿”：线程池线程全被某个长期阻塞的任务占据，其他异步任务排队等至少一个线程空闲，但等待的线程本身又需要线程池线程来被释放，形成互相等待。

举一个我实际碰到的例子：一个 ASP.NET Core 接口调用了某个第三方 SDK，这个 SDK 内部是同步阻塞，且会Task.Wait()等待一个异步结果。当请求量上来时，所有线程池线程都堵在 SDK 内部，新的异步回调排不上，最终线程池自动扩容到几千，CPU 没满，但请求全部超时。解决办法从根本上讲是换异步 SDK 或把这个调用隔离到独立线程/消息队列，而不是盲目调大线程池上限。

排查口诀：

• 用dotnet-counters看threadpool-worker数量，暴涨意味着线程在阻塞；
• 用dotnet-stack取线程栈，看大量WaitHandle.InternalWait的堆栈；
• 如果进程 CPU 不高但延迟飙高，优先怀疑线程池饥饿。

同时强调ConfigureAwait(false)不是饥饿的解药，它只是防止上下文回流。真正的解药是让 await 链路上没有任何同步阻塞。

6.2 Go 的死循环协程引发的“CPU 50% 假死”现象

Go 调度器虽然抢占比早期强，但死循环依然很危险。比如一个 goroutine 里写了for {} : select {}但没有任何函数调用、channel 读写、系统调用，编译器不一定能及时插入栈检查。即使 Go 1.14 之后有异步抢占，如果你的循环里长时间不触发预占检查反应，可能只有部分核心被打满，看起来程序“卡住但 CPU 又还活着”。

更常见的还有goroutine 泄漏：ctx没有传到下游，worker 阻塞在读 channel 上，外层的取消信号无法让它退出。排查这种问题，最重要的工具是 Go 自带的 pprof。

go tool pprof http://localhost:6060/debug/pprof/goroutine

在 pprof 页面上看goroutine数量，如果数量随时间线性上涨，基本就是泄漏。检查每个 goroutine 的栈是否停滞在某个chan receive或sync.Mutex.Lock，顺着栈找到是哪个“任务渠道”没有正常 close 或 context 没有传递。

6.3 常见错误速查表

这张表读下来，你会发现两边不是“一个好一个坏”，而是各自的失败模式完全不同。一个团队如果只写一个语言，往往只会熟悉自己那侧的记忆，遇到对方语言里的问题就满头问路。所以我强烈建议：不管是转语言还是做混合架构，先把自己原语言里的坑列出来，再拿同样场景去对方语言里做一次等价测试，比看十篇对比文章都有用。

最后说几句个人体会

我自己的感觉是，C# 的 async/await 更像“分层的异步编排工具”，它帮你把 IO 等待做成非阻塞，但线程和调度的责任永远在 ThreadPool 手里，稍不注意就会回到同步阻塞的老路。Go 的 GMP 更像“运行时替你扛了协程调度的全部脏活”，写起来舒服，但一旦协程失控，代码层面的追踪成本很高。

如果你现在正在做一个跨语言的系统，比如 C# 上位机采集数据，Go 网关做清洗转发，我的建议是：不要追求两种语言里并发写法一致，而是先把“通信边界”定死。上位机侧用 C# 的事件驱动和异步采集，状态变更通过 MQTT/消息队列发出去；Go 侧用 channel + context 处理内部流水线，对外只暴露网关接口。各自用最擅长的那套模型，中间用明确的协议隔开，这样即使某一边出了问题，排查边界非常清晰。

最后分享一个我实测下来的小经验：不管写 C# 还是 Go，把并发调度参数（线程数、GOMAXPROCS、SemaphoreSlim 容量、channel 缓冲）都放在配置里显式声明，不要靠运行时默认值。很多诡异的性能问题，根本不是模型不好，而是你在测试机上让调度器自动侦查，到了生产环境资源完全不同，行为就发生了不可预估的漂移。显式配置之后，你至少能在一个确定的环境里复现和调优。这一条，在两边都是通用的。