线程管理这个系列写到第三篇终于碰上了最硬的一块骨头——调度器。前两篇我们把线程的创建、生命周期、同步原语这些静态的东西捋了一遍但线程真正跑起来之后谁先上 CPU、谁跑多久、谁被踢下来这些动态决策全部由调度器说了算。很多人写并发程序时遇到性能上不去、延迟抖动大、线程明明没干活 CPU 却满载的问题追到根上都是调度策略没配对。这篇我会从内核态调度器讲到用户态调度器再顺手把负载调度器和学习率调度器这两类名字里带调度的东西拉进来对比因为它们解决问题的骨架其实是同一个。不管你是写 C/C 后端、写 Go 服务、做 Java 中间件还是搞模型训练只要涉及把任务分配到有限的执行单元上这篇里的思路都能直接拿去用。1. 调度器到底在调度什么先把问题定义清楚1.1 三个层次的调度器其实是同一道题我们平时说调度器语境差别其实非常大。第一种是操作系统内核里的线程调度器它决定下一秒哪个内核线程占用哪个物理核心第二种是用户态运行时里的调度器比如 Go 的 GMP、Java 的 ForkJoinPool、各种协程库它在内核线程之上再虚拟出一层更轻的执行单元第三种是更广义的资源调度器像负载均衡器把请求分发给后端节点或者训练框架在每个迭代步调整学习率。这三者表面上八竿子打不着但抽象出来后是同一道题有一批待执行的任务有一组有限的执行资源有一个需要优化的目标函数调度器就是求解这个分配问题的策略。我在实际项目里发现一个很有意思的现象能把内核调度参数调明白的人通常也能很快上手用户态协程调度反过来写惯了协程调度的人如果不理解内核那一层很容易在 syscall 阻塞、线程数爆炸这类问题上翻车。原因就在于这两层是耦合的——用户态调度器的执行单元最终还是要落到内核线程上内核给它分多少 CPU决定了它上层再怎么调度都是无米之炊。所以理解调度器第一件事是把层次分清楚别把用户态能解决的问题推给内核也别指望内核能理解你业务上的优先级。这道题的边界感比具体算法重要得多。1.2 调度目标之间的取舍吞吐、延迟、公平调度算法没有一个全能最优解本质原因是几个目标天然互相打架。吞吐量希望 CPU 尽可能别闲着减少上下文切换次数让每个任务一次多跑一会儿延迟希望交互型任务一就绪就立刻抢占哪怕为此付出频繁切换的代价公平性希望没有任务被饿死每个任务都能分到应有的份额。这三者在资源紧张时必然冲突所以所有成熟调度器都是在做加权折中而不是追求单一指标。举个具体的Linux 的 CFS 默认调度延迟sched_latency是 6 毫秒意味着在一个周期内所有可运行任务至少各被调度一次。如果我把它调大到 20 毫秒吞吐会变好因为切换次数少了但交互延迟会明显变差一个刚被唤醒然后等着响应的线程可能要等接近 20 毫秒才上 CPU。反过来把它调到 1 毫秒界面响应丝滑了但 CPU 有大量时间浪费在保存恢复现场上。这个参数没有标准答案只有对当前负载是否合适。我个人的经验是纯计算型服务可以适当放大IO 密集或者有实时性要求的场景要调小但别小过 2-3 毫秒否则切换开销会吃掉收益。这里有个容易踩的坑很多人一看到延迟高就去调调度参数结果发现是锁竞争或者 GC 造成的白折腾。调参前一定要先量清楚瓶颈在哪一层调度只是众多嫌疑对象之一。我习惯的第一步永远是看vmstat的cs上下文切换次数和r运行队列长度如果这两个数都很健康那问题大概率不在调度器头上。1.3 选型之前先量一量你的负载画像在动任何调度参数之前你应该先回答三个问题任务是 CPU 密集还是 IO 密集对延迟的敏感度是毫秒级还是微秒级任务数量是稳定的还是突发波动的这三个答案基本决定了后续所有选型方向比抄任何最佳实践都管用。比如一个典型的 Web 后端请求处理里有大量数据库等待属于 IO 密集型任务数随流量波动。这种情况下你要的不是极致的内核调度优化而是让阻塞的线程别白白占着内核线程——要么用异步 IO要么用协程把阻塞点挪到事件循环里。而我之前做过的一个音视频转码服务纯 CPU 计算任务数固定等于核数的 1-2 倍这时候重点是减少不必要的抢占和切换甚至可以给线程绑核CPU affinity来提升 cache 命中率。量负载画像这一步我是吃过亏的。早年做日志聚合看到线程池排队就去无脑加线程数从 8 加到 64结果 QPS 没涨反而跌了CPU 大量时间花在切换上磁盘 IO 也成了瓶颈。后来回头一查任务根本不是 CPU 密集加线程只是把竞争从线程池内部搬到了 IO 层纯属把问题挪了个地方。先测量、再假设、最后才调参这个顺序千万别颠倒。常用的三个观测工具我这里先点一下pidstat -w看单进程切换perf sched看调度延迟分布/proc/pid/schedstat看线程在 CPU 上跑了多久、等了多久这仨配合起来基本能定位八成调度问题。2. Linux 内核线程调度的核心机制2.1 时间片、优先级与调度类Linux 内核把调度策略抽象成调度类scheduling class每个调度类有自己的优先级顺序内核从上往下遍历一旦某个类有可运行任务就交给它不再往下看。目前主流的顺序是stop_sched_class停机极少用、dl_sched_classDeadline、rt_sched_class实时即 SCHED_FIFO / SCHED_RR、fair_sched_class普通CFS、idle_sched_class空闲。这个层级结构的意思是实时任务的优先级天然高于普通任务只要实时队列里还有能跑的任务普通任务就别想上 CPU。这也是为什么线上服务千万别随便给线程设 SCHED_FIFO一个死循环的实时线程能把整个系统拖死。时间片这块普通任务SCHED_OTHER也就是 CFS没有一个固定值它是动态算出来的我放到 2.2 细说。实时任务则比较直白SCHED_FIFO 没有时间片概念一旦上 CPU 就一直跑直到自己主动让出或被更高优先级的实时任务抢占SCHED_RR 则有固定时间片走完一轮换下一个同优先级任务。优先级范围上普通任务是 nice 值 -20 到 19越小越不谦让实时任务是 1 到 99越大越优先两套体系互不干扰。我用得最多的还是 SCHED_OTHER因为绝大多数业务代码根本不需要实时语义而且一旦涉及实时调度你就得考虑 mlockall 防止缺页、考虑信号处理不能阻塞、考虑优先级反转该怎么防工程复杂度上一个台阶。真要用我的建议是只在极少数已知延迟敏感、且能保证短执行的线程上用 SCHED_RR 配一个中间优先级而不是 SCHED_FIFO 配最高优先级。设实时策略的代码长这样注意它需要 CAP_SYS_NICE 权限#include pthread.h #include sched.h #include string.h int make_thread_rr(pthread_attr_t *attr, int prio) { struct sched_param param; memset(param, 0, sizeof(param)); param.sched_priority prio; /* 1..99越大越优先 */ if (pthread_attr_setinheritsched(attr, PTHREAD_EXPLICIT_SCHED) ! 0) return -1; /* 不显式设置的话会继承父线程策略 */ if (pthread_attr_setschedpolicy(attr, SCHED_RR) ! 0) return -1; if (pthread_attr_setschedparam(attr, param) ! 0) return -1; return 0; }pthread_attr_setinheritsched这一步特别容易漏默认是PTHREAD_INHERIT_SCHED也就是新线程直接继承创建者的调度策略你后面设的 policy 和 priority 全被忽略查半天查不出问题。2.2 CFS 的 vruntime 到底怎么算CFS完全公平调度器的核心思想可以用一句话概括不追求谁跑得多而是追求每个任务累积占用的加权运行时间尽量相等。这个加权运行时间就是vruntimevirtual runtime它跟真实运行时间不是一回事中间隔着一个跟 nice 值挂钩的权重系数。具体算法是这样的每个任务有一个权重weight由 nice 值查表得到nice 0 对应 1024nice -20 对应 88761nice 19 对应 15跨度非常大。任务每次实际运行了delta_exec时间vruntime的增量就是vruntime delta_exec * (NICE_0_LOAD / weight)NICE_0_LOAD就是 nice 0 的权重 1024。所以 nice 0 的任务 vruntime 增长等于真实时间nice 为负高优先级的任务权重更大NICE_0_LOAD / weight小于 1vruntime 涨得慢于是它能在红黑树里排得靠前被更频繁地选中nice 为正的任务则相反。内核维护一棵以 vruntime 为 key 的红黑树每次调度就取最左边那个 vruntime 最小的任务——这就是 CFS 名字里完全公平的来源谁都从最小的那个开始。时间片怎么来CFS 有个目标调度延迟sched_latency默认 6ms意思是希望在这段时间里所有可运行任务都轮一遍。那么单个任务的时间片是sched_slice sched_latency * (weight_i / total_weight)但任务一多这么分下去每个任务分到的时间就微乎其微了切换开销受不了。所以还有一个最小粒度sched_min_granularity默认 0.75ms并规定当可运行任务数超过sched_latency / sched_min_granularity也就是 8时实际延迟按nr_running * sched_min_granularity来算。这就是为什么在 64 核机器上开 200 个计算线程每个线程真正拿到的时间片只有零点几毫秒切换开销非常大。经验值CPU 密集型线程数控制在核数的 1 到 1.5 倍比较稳超过 2 倍就要警惕切换损耗了。2.3 抢占点、上下文切换与成本账很多人以为抢占是随时能发生的实际上内核只在一系列特定时机才检查是否需要调度这些点叫抢占点。用户态代码主要在两种情况下被打断一个是系统调用返回用户态前一个是中断处理返回时。除此之外纯计算的任务只要不触发这些点理论上可以一直跑到时间片用完。这也是为什么while(1);这种死循环在普通策略下不会把系统搞死——时间片到了会被强制换下。上下文切换的成本很多人低估了。保存恢复寄存器本身可能只要 1-3 微秒但真正的代价是cache 和 TLB 的污染新任务上来它要访问的数据大概率不在 L1/L2 里得重新从内存加载这个延迟是几十到上百纳秒一次累积起来非常可观。有研究测过在数据密集型负载上一次上下文切换的实际总成本可以到 10-20 微秒量级。所以如果你的服务每秒发生几十万次切换光切换就吃掉了一两个核。观测切换我一般看两个地方pidstat -w -p pid 1看每秒的自愿/非自愿切换次数cat /proc/pid/status | grep ctxt看累计值。非自愿切换nvcswch高说明是被时间片或优先级抢占的自愿切换vcswch高说明是主动阻塞等锁或等 IO。前者一般意味着可运行线程太多后者意味着有等待点。这两个信号的排查方向完全不同别混为一谈。我个人判断的标准是如果单核上非自愿切换每秒长期超过 10 万次那就该考虑减少线程数或者用协程了。3. 用户态调度器从线程池到工作窃取3.1 为什么要在用户态再造一个调度器内核调度器已经很成熟了为什么 Go、Java 这些运行时还要自己搞一套核心原因是内核调度的粒度太粗、成本太高。内核线程的创建要分配栈、注册到调度器切换要陷入内核态一次能省下的就是几微秒。而协程的创建可能只要几百纳秒切换在用户态完成不经过内核成本低一个数量级。当你的并发单元从上万变成百万级时这个数量级差异就是能不能做的问题。第二个原因是调度信息的可见性。内核只知道线程在跑还是阻塞但它不知道你代码里的语义——比如这个任务是刚刚创建还没来得及跑的那个任务已经连续占用 CPU 很久了。运行时有更丰富的上下文可以做更聪明的决策比如 Go 的调度器知道某个 goroutine 刚发出一个网络请求就主动把它挂起把线程让给别的任务。不过用户态调度器也有它的天花板一个用户态线程如果执行了阻塞式系统调用它所属的内核线程就会被内核挂起运行时没法阻止这件事除非用非阻塞 IO 或 IO 多路复用。这就是为什么 Go 早期在重度 syscall 场景下会有 M 被偷走的问题后来引入了 sysmon 监控和 P 的重新绑定才缓解。这个细节我在实际用 cgo 的时候遇到过一个 C 函数里做同步文件读写直接把整个 P 卡住了其他 goroutine 一起等着GOMAXPROCS设多大都没用。3.2 手写一个最小可用的工作窃取调度器工作窃取work-stealing是目前用户态调度器的主流方案Go、Java 的 ForkJoinPool、Rust 的 Rayon 都用它。它的核心结构是每个工作线程维护一个自己的双端队列deque任务提交到某个线程的队列尾部线程自己从尾部取LIFO空闲线程从别人队列的头部偷FIFO。为什么自己取用 LIFO、别人偷用 FIFO因为 LIFO 能让刚提交的任务尽快执行数据局部性好而偷的时候从最老的任务开始这些任务往往是更大粒度、还没被细分的偷走不会破坏别人的局部性。下面这个 C 骨架是我自己写来理解原理的去掉了很多边界处理但主流程是完整的#include deque #include vector #include mutex #include atomic #include thread #include functional #include optional class WorkStealingPool { using Task std::functionvoid(); struct Worker { std::dequeTask q; std::mutex mtx; }; std::vectorWorker workers_; std::vectorstd::thread threads_; std::atomicbool stop_{false}; public: explicit WorkStealingPool(int n) : workers_(n) { for (int i 0; i n; i) threads_.emplace_back([this, i] { run(i); }); } void submit(int w, Task t) { Worker me workers_[w]; { std::lock_guardstd::mutex lk(me.mtx); me.q.push_back(std::move(t)); /* 提交到尾部 */ } } private: bool popLocal(int w, Task out) { Worker me workers_[w]; std::lock_guardstd::mutex lk(me.mtx); if (me.q.empty()) return false; out std::move(me.q.back()); /* 自己从尾部取LIFO */ me.q.pop_back(); return true; } bool steal(int thief, Task out) { int n (int)workers_.size(); for (int k 1; k n; k) { int v (thief k) % n; Worker vic workers_[v]; std::lock_guardstd::mutex lk(vic.mtx); if (vic.q.empty()) continue; out std::move(vic.q.front()); /* 偷别人从头部取FIFO */ vic.q.pop_front(); return true; } return false; } void run(int id) { while (!stop_.load(std::memory_order_relaxed)) { Task t; if (popLocal(id, t)) { t(); continue; } if (steal(id, t)) { t(); continue; } std::this_thread::yield(); /* 没活干就让出实战要换成条件变量 */ } } };这个版本我特意把所有队列都加了锁因为写起来清楚。生产环境里没人这么干工业级实现会用无锁队列或者只在偷的时候加锁、本地操作不加锁因为本地队列只有自己访问只有偷才需要同步。另外这里没处理任务嵌套提交任务里再 submit 到自己的队列实际用的时候队列会膨胀得很快需要有阈值判断超过阈值就把一半任务挪到全局队列——Go 里就是 P 本地队列超过 256 个时把一半推给全局队列。3.3 负载调度器的均衡策略与参数工作窃取解决的是线程级均衡而负载调度器load balancer解决的是节点级均衡两者思路一脉相承。最朴素的轮询round-robin假设所有节点处理能力相同、请求代价相同一旦有慢节点或者长请求队列就会在某个节点堆积。加权轮询引入了处理能力维度最小连接数least connections引入了实时负载维度一致性哈希解决了有状态服务的粘性问题。我做过的一个对比测试很能说明问题三个后端节点一个配置稍差用轮询时它经常成为队列最长的那一个P99 延迟被它拖着走换成最小连接数之后P99 直接降了三成。但最小连接数也不是银弹它要求负载均衡器能准确知道每个节点的活跃连接数跨机房或者多层代理时这个信息会失真。我的经验是无状态短请求用加权轮询长连接或有状态会话用一致性哈希混合负载考虑最少连接数并且一定要给节点配健康检查和熔断否则慢节点会持续吸流量。用户态线程调度和负载调度共享一个反直觉的结论追求绝对即时均衡反而会降低性能。工作窃取之所以不每次空闲就去偷是因为偷本身有同步开销负载均衡之所以不做实时全局最优分配是因为收集全局状态和迁移请求也有代价。两边的实践都指向局部决策 周期性再平衡这个模式。4. 另一种调度器学习率调度器的设计逻辑4.1 为什么训练也要调度如果你觉得调度器这个词只属于系统领域那学习率调度器learning rate scheduler会给你一个新的视角。训练神经网络时学习率决定了每次参数更新的步长。步长太大损失函数会在最优点附近来回震荡甚至发散步长太小收敛慢到让人崩溃。没有任何一个固定的学习率能同时满足训练早期快速下降和训练后期精细收敛这两个互相矛盾的需求所以必须让学习率随训练进程变化——这就是调度。把它和 CPU 调度对照一下会很有意思。CPU 调度器要在让每个任务都跑和减少切换开销之间取平衡学习率调度器要在探索大步长和利用小步长之间取平衡。两者都是把有限的资源CPU 时间 / 优化步长在时间维度上做有策略的分配。区别只是一个是离散的任务切换一个是连续的参数曲线。理解了这层同构关系你会发现很多调度思想是可以跨领域迁移的。我最早做深度学习时是完全不调度学习率的固定 0.01 硬跑结果模型在训练后期 loss 一直在 0.4 附近抖怎么调都下不去。后来加了余弦退火同样的模型结构最终 loss 降到了 0.28。同一个网络、同一份数据唯一变量就是学习率调度这个差距让我印象很深。调度不是锦上添花在很多任务上它是能不能收敛到好解的决定因素。4.2 常用学习率调度器的曲线与适用场景实际工作中常用的就那几种我把它们的曲线特征和适用场景整理成一张表方便对照选择调度器曲线形状关键参数适用场景注意事项StepLR阶梯下降step_size、gamma传统 CNN、结构简单拐点会造成 loss 突跳需配合 warmupMultiStepLR多段阶梯milestones、gamma需要人工指定衰减点对训练总轮数敏感CosineAnnealingLR余弦曲线平滑下降T_max、eta_min现代视觉任务主力周期结束时可能过拟合ReduceLROnPlateau平台期触发下降patience、factor指标波动大的任务依赖验证指标需防指标噪声误触发Warmup 线性衰减先升后降warmup_stepsTransformer、大模型上升太快会炸一般 warmup 占总步数 5%-10%OneCycleLR先升后降的单周期max_lr、total_steps追求快速收敛总步数必须提前固定Warmup 这块我想多强调一句因为它特别容易被忽略。Transformer 类模型在训练最初几百步如果直接用大学习率梯度范数会非常大很容易出现 loss 变成 NaN。解决办法就是在最开始的若干步把学习率从接近 0 线性升到目标值给模型一个适应期。这个思路和 CPU 调度里新创建的线程先给它一点 CPU 预热其实是同一类直觉——系统刚开始运行时状态未稳不宜给太激进的资源分配。4.3 把调度器抽象成同一个骨架写到这里我想把三个领域的调度器拉到一个抽象层面。任何一个调度器都可以拆成四个部分状态观测、策略计算、动作执行、反馈修正。内核调度器观测运行队列和 vruntime按 CFS 规则算出下一个该跑谁执行上下文切换然后根据任务的睡眠/唤醒模式持续修正。负载调度器观测各节点连接数和响应时间按策略选节点转发请求根据健康检查结果调整权重。学习率调度器观测训练步数和验证指标算出当前学习率更新优化器参数根据 loss 曲线决定是否提前触发衰减。这四个部分里最容易被低估的是反馈修正。很多调度器之所以在实验室好用、上线就翻车就是因为它们是开环的——只按预设规则走不根据实际效果调整。开源的调度框架之所以要做那么多自适应逻辑比如 CFS 的动态时间片、负载均衡的健康检查、学习率的 ReduceLROnPlateau本质都是把开环变成闭环。我在设计任何调度逻辑时第一件事就是问自己如果环境变了这个调度器能不能自己感知到并调整如果答案是不能那它就是个定时炸弹。另外还有一个通用原则值得记住调度粒度和调度频率是耦合的。粒度越细能做的决策越精细但每次决策的开销占比越高。内核把调度粒度定在毫秒级学习率把调度粒度定在百步级负载均衡把决策粒度定在秒级都是这么权衡出来的。你在设计自己的调度逻辑时也要先估一下单次决策成本和决策带来的收益哪个大收益盖不住成本的时候宁可粗一点。5. 常见问题与排查技巧实录5.1 线程饥饿、优先级反转与惊群线程饥饿是调度问题里最隐蔽的一类表现是某些线程长时间得不到执行日志上看就是任务提交了但迟迟没有输出。常见成因有三种一是优先级设置不均高优先级线程持续霸占 CPU二是持锁时间过长其他线程永远抢不到锁三是 CFS 里某个线程的 vruntime 被欠账太多一直在树的最左边反复被选中。诊断方法是看/proc/pid/task/tid/schedstat里的第三个字段等待时间如果某个线程的等待时间远高于其他线程基本可以确认。优先级反转是实时系统的经典坑低优先级线程持有锁高优先级线程等这把锁结果中优先级的线程把低优先级线程抢占掉导致高优先级线程被无限期阻塞。解决方案是优先级继承priority inheritancepthread 的互斥锁可以通过设置属性开启pthread_mutexattr_t attr; pthread_mutexattr_init(attr); pthread_mutexattr_setprotocol(attr, PTHREAD_PRIO_INHERIT); pthread_mutex_init(mtx, attr);惊群thundering herd则是另一类问题多个线程同时等待同一个事件事件到来时全部被唤醒结果只有一个能处理其他又回去睡白折腾一轮。经典场景是多个线程 accept 同一个监听套接字。现代内核的EPOLLEXCLUSIVE标志就是为解决这个设计的它保证一个事件只唤醒一个等待者。我自己的经验是凡是多个消费者等同一个队列的结构都要检查一下唤醒逻辑能用只唤醒一个就别用广播。5.2 上下文切换飙高的排查路径遇到cs指标异常高我会按这个顺序排查。第一步确认切换类型看pidstat -w的自愿和非自愿比例非自愿高就往可运行线程过多方向查自愿高就往锁竞争或 IO 等待方向查。第二步看线程数ps -eLf | wc -l或者读/proc/pid/status的Threads字段如果线程数远超 CPU 核数且任务都是 CPU 密集型那基本就是自己造成的。第三步看锁用perf lock或者strace -c -f -p pid统计 futex 调用频率竞争激烈的话会非常明显。我之前排查过一个线上问题一个 Java 服务的 CPU 只用了 30% 但 QPS 上不去pidstat -w显示每秒非自愿切换 40 万次。线程数一看200 个计算线程跑在 16 核机器上。把线程池从 200 调到 24QPS 直接翻倍切换降到 2 万以下。这个案例我反复在团队里讲因为结论太反直觉了——线程不是越多越好加线程在超过某个点之后是负收益。那个临界点大概在哪里我的经验公式是CPU 密集型任务线程数 ≈ 核数 × (1 等待时间/计算时间)等待时间接近 0 的时候这个倍数就是 1。5.3 调度相关常见问题速查表下面这张表是我这几年攒下来的遇到问题先对号入座现象可能原因快速验证处理方向线程迟迟不执行优先级过低或饥饿看 schedstat 等待时间调整优先级检查锁持有时间CPU 利用率低但延迟高上下文切换过多pidstat -w 看 cs减少线程数改用协程延迟周期性抖动调度延迟参数过大看 sched_latency 配置调小 sched_latency实时线程卡死系统SCHED_FIFO 死循环看实时线程 CPU 占用改用 SCHED_RR 并限优先级协程数暴涨内存涨任务嵌套提交失控看队列深度加阈值溢出转全局队列训练 loss 后期震荡学习率过大无衰减看 loss 曲线形状加余弦退火或 ReduceLROnPlateau训练早期 loss 变 NaN无 warmup看前 100 步梯度范数加 warmup最后分享一个我自己常用的技巧给关键线程命名然后按名字过滤监控。Linux 的线程可以通过pthread_setname_np设置名字Java 里通过线程工厂设置这样在top -H、perf top里一眼就能看出是哪个线程在吃 CPU比对着 TID 猜半天强太多。我在所有线上服务里都强制要求线程命名这个习惯帮我定位过至少五次疑难问题。至于内核参数怎么调我的态度一直是保守。除非有明确的测量数据支撑否则不要动sched_latency、sched_min_granularity这些参数默认值是无数场景验证过的折中。真正需要调优的时候也是在压测环境里一组一组做对照而不是凭感觉改。这些年我看过的调参酿成事故的案例比调参解决问题的案例要多得多。最后说点个人体会。调度这个东西越往深了做越会发现它是一门关于取舍的手艺而不是一套能背下来的公式。同一个参数在不同负载下效果可以完全相反同一个算法在不同规模下表现可以天差地别。我现在的习惯是每接手一个新系统先花半天时间建一张调度画像——任务类型、并发量级、延迟要求、资源上限把这四个维度写清楚选型和调参的方向自然就出来了。反过来如果跳过这一步直接抄配置最后大概率是在用别人的答案解自己的题。