Java多线程 （二）—— 上下文切换

一、什么是上下文切换？

单核CPU处理器是如何处理多线程呢（这里的多线程是假像多线程，具体后面会说）？处理器会通过给每个线程分配一个CPU时间片，线程会在分配的时间片内执行任务，时间片用完了就切换下一个线程。时间片非常短，一般只有几十毫秒，所以CPU通过不停地切换线程执行时我们几乎感觉不到任务的停滞，让我们感觉是多个线程同时执行，这个就是假象多线程。CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个 任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。

二、什么是时间片？

在宏观上：我们可以同时打开多个应用程序，每个程序并行不悖，同时运行。

但是在微观上：由于只有一个CPU，一次只能处理程序要求的一部分，如何处理公平，一种方法就是引入时间片，通过时间片轮转交替执行程序。

那么什么是时间片的轮转呢？

  时间片轮转调度是一种最古老，最简单，最公平且使用最广的算法是时间片调度。每个进程被分配一个时间段，称作它的时间片，即该进程允许运行的时间。如果在时间片结束时进程还在运行，则CPU将被剥夺并分配给另一个进程。如果进程在时间片结束前阻塞或结束，则CPU当即进行切换。调度程序所要做的就是维护一张就绪进程列表，，当进程用完它的时间片后，它被移到队列的末尾。

  时间片轮转调度中唯一有趣的一点是时间片的长度。从一个进程切换到另一个进程是需要一定时间的–保存和装入寄存器值及内存映像，更新各种表格和队列等。假如进程切换(process switch) - 有时称为上下文切换(context switch)，需要5毫秒，再假设时间片设为20毫秒，则在做完20毫秒有用的工作之后，CPU将花费5毫秒来进行进程切换。CPU时间的20%被浪费在了管理开销上。

  为了提高CPU效率，我们可以将时间片设为500毫秒。这时浪费的时间只有1%。但考虑在一个分时系统中，如果有十个交互用户几乎同时按下回车键，将发生什么情况？假设所有其他进程都用足它们的时间片的话，最后一个不幸的进程不得不等待5秒钟才获得运行机会。多数用户无法忍受一条简短命令要5秒钟才能做出响应。同样的问题在一台支持多道程序的个人计算机上也会发生。

结论可以归结如下：时间片设得太短会导致过多的进程切换，降低了CPU效率；而设得太长又可能引起对短的交互请求的响应变差。将时间片设为100毫秒通常是一个比较合理的折衷。

三、如何减少上下文切换来提高线程运行效率？

线程的上下文切换分为让步式上下文切换和抢占式上下文切换。

前者是指执行线程主动释放CPU，与锁竞争严重程度成正比，可通过减少锁竞争来避免；

后者是指线程因分配的时间片用尽而被迫放弃CPU或者被其他优先级更高的线程所抢占，一般由于线程数大于CPU可用核心数引起，可通过调整线程数，适当减少线程数来避免。

1、无锁并发编程。锁竞争时会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash取模分段，不同的线程处理不同段的数据。

2、减少锁的使用，能用CAS代替锁时尽量用CAS代替。Java的Atomic包使用CAS算法来更新数据，而不需要加锁。CAS机制下一节会继续分析。

在多线程竞争下，加锁、释放锁会导致比较多的上下文切换和调度延时，引起性能问题。

多个线程使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试（只要cpu分配给线程的时间片没有过，就可以不断的重试，但是时间片过后，如果还是没有成功，也会进行上下文切换，所以说只是减少了上下文切换）。

3、使用最少线程。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态。

4、使用协程。在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。