Thread.sleep(0)的意义& 多线程详解

咱们可能常常会用到 Thread.Sleep 函数来使线程挂起一段时间。那么你有没有正确的理解这个函数的用法呢？思考下面这两个问题：

假设如今是 2008-4-7 12:00:00.000，若是我调用一下 Thread.Sleep(1000) ，在 2008-4-7 12:00:01.000 的时候，这个线程会 不会被唤醒？
某人的代码中用了一句看似莫明其妙的话：Thread.Sleep(0) 。既然是 Sleep 0 毫秒，那么他跟去掉这句代码相比，有啥区别么？
咱们先回顾一下操做系统原理。

操做系统中，CPU竞争有不少种策略。Unix系统使用的是时间片算法，而Windows则属于抢占式的。

在时间片算法中，全部的进程排成一个队列。操做系统按照他们的顺序，给每一个进程分配一段时间，即该进程容许运行的时间。若是在 时间片结束时进程还在运行，则CPU将被剥夺并分配给另外一个进程。若是进程在时间片结束前阻塞或结束，则CPU立即进行切换。调度程 序所要作的就是维护一张就绪进程列表，，当进程用完它的时间片后，它被移到队列的末尾。

所谓抢占式操做系统，就是说若是一个进程获得了 CPU 时间，除非它本身放弃使用 CPU ，不然将彻底霸占 CPU 。所以能够看出，在抢 占式操做系统中，操做系统假设全部的进程都是“人品很好”的，会主动退出 CPU 。

在抢占式操做系统中，假设有若干进程，操做系统会根据他们的优先级、饥饿时间（已经多长时间没有使用过 CPU 了），给他们算出一 个总的优先级来。操做系统就会把 CPU 交给总优先级最高的这个进程。当进程执行完毕或者本身主动挂起后，操做系统就会从新计算一 次全部进程的总优先级，而后再挑一个优先级最高的把 CPU 控制权交给他。

咱们用分蛋糕的场景来描述这两种算法。假设有源源不断的蛋糕（源源不断的时间），一副刀叉（一个CPU），10个等待吃蛋糕的人（10 个进程）。

若是是 Unix操做系统来负责分蛋糕，那么他会这样定规矩：每一个人上来吃 1 分钟，时间到了换下一个。最后一我的吃完了就再从头开始。因而，无论这10我的是否是优先级不一样、饥饿程度不一样、饭量不一样，每一个人上来的时候均可以吃 1 分钟。固然，若是有人原本不太饿，或者饭量小，吃了30秒钟以后就吃饱了，那么他能够跟操做系统说：我已经吃饱了（挂起）。因而操做系统就会让下一我的接着来。

若是是 Windows 操做系统来负责分蛋糕的，那么场面就颇有意思了。他会这样定规矩：我会根据大家的优先级、饥饿程度去给大家每一个人计算一个优先级。优先级最高的那我的，能够上来吃蛋糕——吃到你不想吃为止。等这我的吃完了，我再从新根据优先级、饥饿程度来计算每一个人的优先级，而后再分给优先级最高的那我的。

这样看来，这个场面就有意思了——可能有些人是PPMM，所以具备高优先级，因而她就能够常常来吃蛋糕。可能另一我的是个丑男，而去很ws，因此优先级特别低，因而好半天了才轮到他一次（由于随着时间的推移，他会愈来愈饥饿，所以算出来的总优先级就会愈来愈高，所以总有一天会轮到他的）。并且，若是一不当心让一个大胖子获得了刀叉，由于他饭量大，可能他会霸占着蛋糕连续吃好久好久，致使旁边的人在那里咽口水。。。
并且，还可能会有这种状况出现：操做系统如今计算出来的结果，5号PPMM总优先级最高，并且高出别人一大截。所以就叫5号来吃蛋糕。5号吃了一小会儿，以为没那么饿了，因而说“我不吃了”（挂起）。所以操做系统就会从新计算全部人的优先级。由于5号刚刚吃过，所以她的饥饿程度变小了，因而总优先级变小了；而其余人由于多等了一下子，饥饿程度都变大了，因此总优先级也变大了。不过这时候仍然有可能5号的优先级比别的都高，只不过如今只比其余的高一点点——但她仍然是总优先级最高的啊。所以操做系统就会说：5号mm上来吃蛋糕……（5号mm内心郁闷，这不刚吃过嘛……人家要减肥……谁叫你长那么漂亮，得到了那么高的优先级）。

那么，Thread.Sleep 函数是干嘛的呢？还用刚才的分蛋糕的场景来描述。上面的场景里面，5号MM在吃了一次蛋糕以后，以为已经有8分饱了，她以为在将来的半个小时以内都不想再来吃蛋糕了，那么她就会跟操做系统说：在将来的半个小时以内不要再叫我上来吃蛋糕了。这样，操做系统在随后的半个小时里面从新计算全部人总优先级的时候，就会忽略5号mm。Sleep函数就是干这事的，他告诉操做系统“在将来的多少毫秒内我不参与CPU竞争”。

看完了 Thread.Sleep 的做用，咱们再来想一想文章开头的两个问题。

对于第一个问题，答案是：不必定。由于你只是告诉操做系统：在将来的1000毫秒内我不想再参与到CPU竞争。那么1000毫秒过去以后，这时候也许另一个线程正在使用CPU，那么这时候操做系统是不会从新分配CPU的，直到那个线程挂起或结束；何况，即便这个时候恰巧轮到操做系统进行CPU 分配，那么当前线程也不必定就是总优先级最高的那个，CPU仍是可能被其余线程抢占去。

与此类似的，Thread有个Resume函数，是用来唤醒挂起的线程的。好像上面所说的同样，这个函数只是“告诉操做系统我从如今起开始参与CPU竞争了”，这个函数的调用并不能立刻使得这个线程得到CPU控制权。

对于第二个问题，答案是：有，并且区别很明显。假设咱们刚才的分蛋糕场景里面，有另一个PPMM 7号，她的优先级也很是很是高（由于很是很是漂亮），因此操做系统老是会叫道她来吃蛋糕。并且，7号也很是喜欢吃蛋糕，并且饭量也很大。不过，7号人品很好，她很善良，她没吃几口就会想：若是如今有别人比我更须要吃蛋糕，那么我就让给他。所以，她能够每吃几口就跟操做系统说：咱们来从新计算一下全部人的总优先级吧。不过，操做系统不接受这个建议——由于操做系统不提供这个接口。因而7号mm就换了个说法：“在将来的0毫秒以内不要再叫我上来吃蛋糕了”。这个指令操做系统是接受的，因而此时操做系统就会从新计算你们的总优先级——注意这个时候是连7号一块儿计算的，由于“0毫秒已通过去了”嘛。所以若是没有比7号更须要吃蛋糕的人出现，那么下一次7号仍是会被叫上来吃蛋糕。

所以，Thread.Sleep(0)的做用，就是“触发操做系统马上从新进行一次CPU竞争”。竞争的结果也许是当前线程仍然得到CPU控制权，也许会换成别的线程得到CPU控制权。这也是咱们在大循环里面常常会写一句Thread.Sleep(0) ，由于这样就给了其余线程好比Paint线程得到CPU控制权的权力，这样界面就不会假死在那里。

另外，虽然上面提到说“除非它本身放弃使用 CPU ，不然将彻底霸占 CPU”，但这个行为仍然是受到制约的——操做系统会监控你霸占CPU的状况，若是发现某个线程长时间霸占CPU，会强制使这个线程挂起，所以在实际上不会出现“一个线程一直霸占着 CPU 不放”的状况。至于咱们的大循环形成程序假死，并非由于这个线程一直在霸占着CPU。实际上在这段时间操做系统已经进行过屡次CPU竞争了，只不过其余线程在得到CPU控制权以后很短期内立刻就退出了，因而就又轮到了这个线程继续执行循环，因而就又用了好久才被操做系统强制挂起。。。所以反应到界面上，看起来就好像这个线程一直在霸占着CPU同样。

末了再说明一下，文中线程、进程有点混乱，其实在Windows原理层面，CPU竞争都是线程级的，本文中把这里的进程、线程当作同一个东西就行了。