这是C#并行编程系列笔记的第五节聊一个很容易被低估的枚举TaskCreationOptions。很多人写后台任务new Task只传一个Action从来没管过第二个参数。可一旦牵扯到父子任务Task构造函数里这个参数就成了决定行为的分水岭父子任务之间到底是“各走各的”还是父任务乖乖等所有子任务跑完完全由它说了算。这篇文章会把枚举的几个值拆开讲透再结合代码看实际执行顺序最后聊几个我在生产环境里踩过的真实坑。先给个结论默认情况下父任务不会等待任何子任务。只有当你创建子任务时显式传入TaskCreationOptions.AttachedToParent父任务才会在完成前等所有附加的子任务执行完。而Task.Run创建的父任务又因为内置DenyChildAttach会反过来拒绝这种附加。这几个选项之间的关系如果只靠看文档很容易绕晕但用代码一跑行为立马就清晰了。1. Task构造函数与TaskCreationOptions的定位1.1 从构造函数重载看Task能接收什么Task构造函数并不只有一个简单版本。在.NET里常见重载大致有这些构造函数签名主要用途Task(Action)创建动作任务默认调度无取消支持Task(Action, TaskCreationOptions)创建任务时指定创建选项Task(Action, CancellationToken)创建可取消任务Task(Action, CancellationToken, TaskCreationOptions)创建同时支持取消和创建选项的任务Task(Actionobject, object)带状态对象的任务Task(Actionobject, object, TaskCreationOptions)带状态对象同时指定创建选项Task(Actionobject, object, CancellationToken, TaskCreationOptions)组合最多的情况如果用的是最新TAP还可能有带TaskScheduler的重载。不过我们重点不在这里而是要意识到TaskCreationOptions是构造函数里一个独立的入参它不决定你的业务逻辑它决定任务调度器怎么看待这个任务。构造函数创建出来的任务默认是“冷任务”也就是你调用new Task(...)之后任务并没有进入执行队列必须手动调用Start()。很多人一开始会忽略这一点把创建和启动混在一起。这里有个比较隐蔽的点AttachedToParent等选项只是在你创建任务时登记了它的“身份属性”真正建立父子关系要等到Start()之后并且它是在父任务内被启动时才会发生。1.2 为什么同一个枚举能影响“父子关系”严格来说Task和Thread不是一回事Task是线程池之上的调度单元底层可能复用线程也可能不创建线程。大家习惯说“父子线程”但准确讲应该是“父子任务”。之所以TaskCreationOptions能影响父子关系是因为TPL框架内部维护了一张任务依赖图。框架在调度一个任务时会检查这个任务的创建选项然后决定它的完成条件如果任务是普通任务那么它的委托执行完任务状态就是RanToCompletion。如果任务被标记为AttachedToParent那它执行完还需要通知父任务父任务的状态机要等所有附加子任务都完成才进入完成态。如果父任务被标记为DenyChildAttach那框架在创建子任务时会直接忽略子任务的附加请求。这就像盖房子时的一个“设计图纸”TaskCreationOptions不是钢筋水泥而是施工流程里的一个个钩子决定了哪些墙体要互相挂靠哪些墙体要独立承重。理解这点就理解了大半。2. TaskCreationOptions枚举值逐个拆解2.1 AttachedToParent是父子任务的粘合剂AttachedToParent这个选项要加在子任务上而不是父任务上。它的意思是如果当前存在父任务并且父任务没有拒绝子任务附加那么这个子任务就会挂到父任务下面。父任务会等待所有附加子任务执行完毕再把自己标记为完成。代码长这样var parent new Task(() { var child new Task(() { Thread.Sleep(500); Console.WriteLine(子任务完成); }, TaskCreationOptions.AttachedToParent); child.Start(); Console.WriteLine(父任务体结束); }); parent.Start(); parent.Wait(); Console.WriteLine(外部等待结束);有了AttachedToParent之后外部调用parent.Wait()一定会等到子任务执行完才返回。如果没有这个选项外部Wait()可能在子任务还在跑的时候就返回了。这就是父子任务之间最基本的行为差异。需要特别提醒一件事AttachedToParent只在“子任务是在父任务执行过程中被创建并启动”的场景下才有效。如果你在父任务体外部预先创建了一个任务对象然后让父任务去启动它这种嵌套关系并不成立附加也会失败。这个坑我在后面排查部分还会展开。2.2 DenyChildAttach把子任务挡在门外DenyChildAttach是加在父任务上的选项。一旦父任务设置了它它就会拒绝所有尝试附加的子任务。就算子任务声明了AttachedToParent父任务也不会等待这些子任务。一个典型的例子是Task.Run。很多人不知道Task.Run(Action)其实等价于Task.Factory.StartNew(action, CancellationToken.None, TaskCreationOptions.DenyChildAttach, TaskScheduler.Default);也就是说Task.Run创建的父任务天然自带DenyChildAttach。这也就解释了为什么很多人在Task.Run里创建AttachedToParent子任务发现父任务根本不等子任务。这个选项的实用价值在于任务库设计。如果你在写一个基础组件不希望调用方传入的后续操作被附加到你的任务图中用DenyChildAttach可以强制隔离内部任务和外部任务的关系。否则外部任务一旦附加进来可能会拖住你的组件任务完成导致一些难以排查的时序问题。2.3 LongRunning、PreferFairness、HideScheduler、RunContinuationsAsynchronously速览这几个选项和父子任务的关系没那么大但既然在同一个枚举里顺便一起理清。LongRunning提示调度器这个任务会长时间运行。调度器会倾向于让它使用独立线程而不是一直占着线程池里的一个工作线程不放。适合监听、阻塞循环这类场景。但现代化程序里能用async/await处理等待就尽量让线程在等待期间被释放LongRunning用得越来越少。PreferFairness让调度器尽量按任务创建顺序公平调度而不是利用线程池本地队列的先进后出。这个会牺牲一部分吞吐普通场景基本用不到。HideScheduler防止任务内部看到外部的TaskScheduler.Current。如果任务在某个自定义调度器环境中创建不设置这个选项它内部创建的子任务可能会使用外部调度器设置之后内部调度器会回到默认调度器。做库封装时比较有用。RunContinuationsAsynchronously这是.NET 4.6之后加的。意思是延续任务不要同步执行在当前的上下文里。在某些单线程同步上下文比如老的GUI环境里这能减少死锁。它不是为父子任务设计的但和任务的执行模式有关。我们可以用一张表快速记住它们选项面向对象核心作用AttachedToParent子任务让父任务等待自己完成DenyChildAttach父任务拒绝所有子任务附加LongRunning任务本身提示使用独立线程PreferFairness任务本身按创建顺序公平调度HideScheduler任务本身隐藏外部调度器RunContinuationsAsynchronously任务延续避免同步上下文死锁3. 父子任务实操从执行顺序看懂选项3.1 默认写法父任务不会等子任务先看默认行为。下面这段代码足够简单但能直观反映大多数人一开始的直觉和真实情况的差距var parent new Task(() { Console.WriteLine(父任务开始); var child new Task(() { Thread.Sleep(500); Console.WriteLine(子任务完成); }); child.Start(); Console.WriteLine(父任务体结束); }); parent.Start(); parent.Wait(); Console.WriteLine(外部等待结束);运行一次很可能输出父任务开始 父任务体结束 外部等待结束 子任务完成注意“很可能”三个字很重要。因为线程调度是并发的子任务未必一定晚于外部等待结束但父任务和外部Wait()都没有义务等子任务。只要父任务体执行完父任务就完成了外部Wait()自然返回。这就导致一个典型问题有些人用父任务启动一堆子任务然后parent.Wait()以为能等所有任务结果程序早就往下走了子任务还在后台慢慢跑。尤其在需要汇总结果的场景里这个默认行为会直接导致结果丢失。3.2 加上AttachedToParent之后父任务开始等把子任务构造函数加上TaskCreationOptions.AttachedToParentvar parent new Task(() { Console.WriteLine(父任务开始); var child new Task(() { Thread.Sleep(500); Console.WriteLine(子任务完成); }, TaskCreationOptions.AttachedToParent); child.Start(); Console.WriteLine(父任务体结束); }); parent.Start(); parent.Wait(); Console.WriteLine(外部等待结束);这次输出顺序可以保证的是外部等待结束一定在子任务完成之后。父任务体自己的代码可能比子任务先完成也可以比子任务后完成但父任务的最终完成状态会一直挂到所有附加子任务结束。这里有个很关键的概念父任务的委托返回了不等于父任务完成。任务框架在委托返回后会检查是否存在附加子任务如果存在就会进入等待子任务完成的状态。你可以打印parent.Status可能会看到WaitingForChildrenToComplete这类中间状态。这在调试时非常有用后面我会再说。3.3 Task.Run自带“拒收”属性很多人在生产代码里不会用new Task而是直接用Task.Run。这时候容易踩到一个隐形坑Task parent Task.Run(() { Task child new Task(() { Thread.Sleep(1000); Console.WriteLine(子任务完成); }, TaskCreationOptions.AttachedToParent); child.Start(); }); parent.Wait(); Console.WriteLine(外部等待结束);你以为父任务会等子任务实际上Task.Run创建的父任务自带DenyChildAttach子任务附加上去直接被无视。运行结果大概率是外部等待结束 子任务完成而且这里的parent.Wait()不会超时也不会报错子任务照样执行只是父任务不等它。这是最坑的地方——没有异常没有警告只有时序不符合预期。所以我的习惯是如果需要父任务等待附加子任务就不要用Task.Run来创建父任务。改用new Task(...)启动后由框架自动处理附加关系或者干脆放弃附加方案改成把子任务收集起来外部用Task.WhenAll统一等待。现代代码里后者更常见也更清晰。3.4 Task.Factory.StartNew里的选项要怎么传如果你确实需要用工厂方法创建父任务并且希望它允许子任务附加那就要显式传入TaskCreationOptions.AttachedToParent而不是DenyChildAttach。比如Task parent Task.Factory.StartNew(() { Task child new Task(() { Thread.Sleep(1000); Console.WriteLine(子任务完成); }, TaskCreationOptions.AttachedToParent); child.Start(); }, CancellationToken.None, TaskCreationOptions.AttachedToParent, TaskScheduler.Default);这里我显式指定了TaskScheduler.Default是为了避免Task.Factory.StartNew使用当前线程的TaskScheduler.Current。很多人不知道在异步方法里使用Task.Factory.StartNew默认调度器可能不是线程池而是当前的同步上下文调度器这会带来另一个维度的坑。不过说实话Task.Factory.StartNew是一个很老的API默认行为有不少陷阱。只要不是必须精确控制调度器和创建选项直接用Task.Run或new Task会更安全。微软官方也建议能用Task.Run就不要用StartNew。4. 常见问题与排查技巧实录4.1 明明加了AttachedToParent父任务为什么没等这是我被问过最多的一种情况。代码看起来是标准父子任务父任务却没有等子任务。常见原因有四个父任务是用Task.Run创建的自带DenyChildAttach子任务附加被拒绝。子任务是通过Task.Run创建的而Task.Run内部创建的父任务有DenyChildAttach所以子任务无法附加。子任务不是“在父任务体内创建并启动”的而是在父任务体外部创建只是拿着引用在父任务内Start()。附加关系的判定和创建上下文有关这种跨上下文的启动不会建立真正的父子关系。子任务创建时虽然带了AttachedToParent但没有调用Start()。冷任务不启动父任务自然会一直等下去看起来就像卡住了如果加了超时则表现为等超时后父任务没完成。排查时可以做一个最小化复现把父任务改成new Task创建子任务也保持new Task(..., TaskCreationOptions.AttachedToParent)然后看行为是否恢复正常。如果恢复正常那就是创建方式的问题。4.2 父任务里Wait附加子任务一不小心就假死这个操作我觉得有必要单独拿出来说。有人会在父任务体里写var parent new Task(() { var child new Task(() { Thread.Sleep(1000); Console.WriteLine(子任务完成); }, TaskCreationOptions.AttachedToParent); child.Start(); child.Wait(); // 不推荐 });外部再调用parent.Wait()。这种写法非常危险。附加子任务本来就会让父任务在委托完成后等待它而你又在父任务体内同步等待它相当于两套等待逻辑叠在一起。在某些线程池调度场景下可能直接进入互相等待的状态最终表现为任务一直不完成甚至程序卡死。我的建议是父任务体内不要对附加子任务调用Wait。让父任务委托正常返回由框架的附加机制自动等待就可以了。如果确实需要控制等待顺序可以改用Task.WhenAll结合async/await而不是用嵌套任务加手动Wait的组合。4.3 快速定位任务关系的小工具与调试思路遇到任务时序问题时我会在关键节点打日志记录Task.CurrentId、Environment.CurrentManagedThreadId和任务开始结束时间。比如var parent new Task(() { Console.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] 父任务 {Task.CurrentId} 开始); var child new Task(() { Console.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] 子任务 {Task.CurrentId} 开始); Thread.Sleep(1000); Console.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] 子任务完成); }, TaskCreationOptions.AttachedToParent); child.Start(); Console.WriteLine($[{DateTime.Now:HH:mm:ss.fff}] 父任务体结束); });运行后看时间戳基本能判断谁先谁后。如果父任务已经“体结束”但状态迟迟不是RanToCompletion那多半是进入了等待附加子任务的状态。另外Task.Status在等待附加子任务期间通常会显示Running或者WaitingForChildrenToComplete。看到这个状态就不会误认为任务没被调度而是知道父任务被附加关系挂住了。还有一个排查利器是超时。所有Wait尽量都加超时参数bool finished parent.Wait(TimeSpan.FromSeconds(3)); if (!finished) { Console.WriteLine(父任务没能在预期时间内完成); }这不会帮你找到根因但可以避免排查问题时把自己耗死。5. 落地建议与个人体会5.1 能用await就用awaitAttachedToParent别硬上我在实际项目里的体会是遇到需要等待子任务完成的情况现代写法应该优先考虑await和Task.WhenAll。例如Task parent Task.Run(async () { Task child1 Task.Run(() DoWork1()); Task child2 Task.Run(() DoWork2()); await Task.WhenAll(child1, child2); });这样的代码只要有await就能保证父任务逻辑后续部分在子任务全部完成后执行。可读性比AttachedToParent好很多也避免了“到底谁在等谁”的困惑。AttachedToParent不是不能用而是更适合特定场景你正在构建一棵嵌套的任务树并且希望通过父任务的状态来统一管理整棵树的完成节点而你又不想在每个层级都手动收集子任务时它才有优势。5.2 什么场景真的适合AttachedToParent比较典型的场景是递归分治类的任务。比如一个任务会把一个大集合拆成若干子任务处理子任务继续拆分子任务最后所有子孙任务全部完成最外层任务才叫完成。这种情况下每个子任务都打上AttachedToParent标记最外层父任务只维护自己的状态就能自动感知整棵任务树的完成情况不用逐层WaitAll。但要注意这种写法必须保证所有层级都用可附加的机制创建。中途只要有一层用了Task.Run附加链条就断了整棵树的完成信号也会失真。所以如果要用就统一用new Task加AttachedToParent创建配合一个统一的启动入口。5.3 最后分享一个组合参数的小细节TaskCreationOptions不是随便乱组合的。比如LongRunning和AttachedToParent可以组合在一起Task t new Task(() { // 长时间任务 }, TaskCreationOptions.LongRunning | TaskCreationOptions.AttachedToParent);这样父任务会等待它同时调度器会给它独立线程的优先级。但LongRunning意味着线程资源占用高如果同时开几十个这种任务线程池压力会很大反而拖垮整体性能。我在一个后台调度模块里试过大规模使用后来还是改成了分批处理。还有一个我在测试环境遇到的细节PreferFairness和LongRunning同时设置语义上有点拧巴。一个希望任务公平轮流调度一个希望任务独立长时间运行框架在处理时不会报错但实际效果并不理想。所以组合选项之前一定要想清楚哪个选项才是这个任务最本质的需求。回到最开始的问题父子任务之间到底要不要互相等待决定权主要在TaskCreationOptions里这两三个选项手上。把它们的行为理解清楚任务调度这块的很多疑惑都会顺带解开。我自己的习惯是新代码尽量用现代化异步方法老代码里看到AttachedToParent时也不会急着改而是先确认任务链是否清晰。毕竟排错最怕的不是老语法而是不知道背后发生了什么。