上下文切换
上下文切换在某种程度上可以被看作多个线程共享同一个处理器的产物。
概念: 对于单核CPU来说（对于多核CPU，此处就理解为一个核），CPU在一个时刻只能运行一个线程，当在运行一个线程的过程中转去运行另外一个线程，这个叫做线程上下文切换（对于进程也是类似）
即使是单核CPU也支持多线程执行代码，CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间，因为时间片非常短，所以CPU通过不停地切换线程执行，让我们感觉多个线程时同时执行的，时间片一般是几十毫秒（ms）。
CPU通过时间片分配算法来循环执行任务，当前任务执行一个时间片后会切换到下一个任务。但是，在切换前会保存上一个任务的状态，以便下次切换回这个任务时，可以再次加载这个任务的状态，从任务保存到再加载的过程就是一次上下文切换。
自发性上下文切换:
线程在执行以下任一一个方法时:
- Thread.sleep()
- Object.wait()/wait(long)
- Thread.yield
- Thread.join
- lockSupport.park()
- 发起IO操作或等待其他线程持有的锁。
非自发性:
是指线程由于线程调度器的原因被迫退出，时间片用完或者被一个优先级更高的线程运行。
如何减少上下文切换
既然上下文切换会导致额外的开销，因此减少上下文切换次数便可以提高多线程程序的运行效率。减少上下文切换的方法有无锁并发编程、CAS算法、使用最少线程和使用协程。
- 无锁并发编程。多线程竞争时，会引起上下文切换，所以多线程处理数据时，可以用一些办法来避免使用锁，如将数据的ID按照Hash取模分段，不同的线程处理不同段的数据
- CAS算法。Java的Atomic包使用CAS算法来更新数据，而不需要加锁
- 使用最少线程。避免创建不需要的线程，比如任务很少，但是创建了很多线程来处理，这样会造成大量线程都处于等待状态
- 协程。在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换.
线程的活性故障
线程是为任务而生的。因此，理想情况下我们希望线程一直处于 RUNNABLE状态。 显然，事实并非如此:导致-一个线程可能处于非RUNNABLE状态的因素除了资源(主要 是处理器资源有限而导致的上下文切换)限制之外，还有程序自身的错误和缺陷。这些由于资源稀缺性或者程序自身的问题和缺陷导致线程一直处于非 RUNNABLE状态，或者线程 虽然处于RUNNABLE状态但是其要执行的任务却一直 无法进展的现象就被称为线程活性 故障(Liveness Failure )。
常见的活性故障包括以下几种。
死锁( Deadlock)。死锁好比鹬蚌相争故事中的情形:鹬啄住蚌的肉，蚌夹住鹬 的嘴。鹬对蚌说:“ 你先放开我的嘴我就不啄你的肉。”而蚌对鹬说:“ 你先放开 我的肉我就不夹你的嘴。”于是最后谁也不放开谁!死锁产生的典型场景是一个线 程X持有资源A的时候等待另外一个线程释放资源B,而另外一个线程Y在持 有资源B的时候却等待线程X释放资源A。死锁的外在表现是当事线程的生命周 期状态永远处于非RUNNABLE状态而使其任务一直无法进展。
●锁死(Lockout)。锁死就好比睡美人的故事中睡美人醒来的前提是她要得到王子 的亲吻，但是如果王子无法亲吻她(比如王子“挂了”....，那么睡美人将一 直沉睡!
●活锁(Livelock)。活锁好比小猫试图咬自己的尾巴，虽然它总是追着自己的尾巴咬，但却始终无法咬到。活锁的外在表现是线程可能处于RUNNABLE状态， 但是线程所要执行的任务却丝毫没有进展，即线程可能一直在 做无用功。
●饥饿(Starvation)。饥饿好比母鸟给雏鸟喂食的情形，健壮的雏鸟总是抢先从母 鸟的嘴中抢到食物，从而导致那此弱小的雏鸟总是挨饿。饥饿就是线程因无法教prton的可执行文件为: Windows安景装5yem2perfmon.exe。
调度策略
非公平调度策略是我们多数情况下的首选资源调度策略。其优点是吞吐率较大; 缺点是资源申请者申请资源所需的时间偏差可能较大，并可能导致饥饿现象。公 平调度策略适合在资源的持有线程占用资源的时间相对长或资源的平均申请时间 间隔相对长的情况下，或者对资源申请所需的时间偏差有所要求的情况下使用。 其优点是线程申请资源所需的时间偏差较小，并且不会导致饥饿现象;其缺点是吞吐率较小。
