我们的认知里，并发编程的目的是为了让程序运行的更快，更能充分利用现在的多核CPU。但是多线程就一定快吗？什么时候应该用多线程呢？这需要面临很多的挑战，也挑战着我们的认知。
首先我们要明白一个道理，没有免费的午餐，一切皆有成本。
第一个挑战：上下文切换
单核处理器也是支持多线程执行的。CPU会给每个线程分配CPU时间片来实现这个机制。这个时间通常很短（通常几十毫秒），所以CPU需要不停的切换线程去执行程序。在我们的感知里面就是同时执行的。
那么问题来了，CPU这么随意的切换不会混乱吗？这就需要保存上一个任务的状态了，也就是说任务从保存到再次加载的过程就是一个上下文的切换。用心的朋友肯定想到了，既然会保存状态，那么一定需要额外消耗，势必会影响效率。
举个例子，比如我们正在写数学题，突然有人敲门，你去开门，看看谁来了，有什么事，完事之后回来继续解题，那么就需要你记得你写到哪一道题了，写到哪一步了，之前的思路是如何的等等。所以上下文的切换会影响多线程的执行速度。
大家可以自己写一个小demo自己测试下。
下图是单线程和双线程的时间对比（参考一下就行了）
结论就是：线程的创建和上下文的切换都是有开销的，如果你的任务比这个开销要轻量，那么单线程比较好，如果比较重，那么多线程一定会大大的节约你的时间。
那么如何减少上下文的切换呢？
1、无锁并发编程
多线程竞争锁的时候会引起上下问的切换，所以可以用一些方法来避免使用锁，比如处理一段数据，我们可以不同线程处理不同位置的数据，互不干扰。
2、CAS算法
Java的Atomic包使用CAS算法来更新数据，而不需要加锁。
CAS是什么？
- CAS是英文单词CompareAndSwap的缩写，中文意思是：比较并替换。CAS需要有3个操作数：内存地址V，旧的预期值A，即将要更新的目标值B。
- CAS指令执行时，当且仅当内存地址V的值与预期值A相等时，将内存地址V的值修改为B，否则就什么都不做。整个比较并替换的操作是一个原子操作。
3、使用最少线程
避免创建不必要的线程
4、使用协程
在单线程中实现多任务的调度，并在单线程中维持多个任务间的切换。
第二个挑战：死锁
锁很有用，但是用的不好就是死锁了。慎用。
那么我们怎么样才能写个死锁呢？估计我们在写成死锁的时候也不知道他会死锁。正式的项目要比这个复杂很多，稍有不慎很容易造成死锁。
private static void deadLock() {
Thread thread1 = new Thread(new Runnable() {
@Override
public void run() {
synchronized (object1) {
try {
Thread.sleep(1000);
synchronized (object2) {
System.out.println("thread1----------");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
Thread thread2 = new Thread(new Runnable() {
@Override
public void run() {
synchronized (object2) {
synchronized (object1) {
System.out.println("thread2----------");
}
}
}
});
thread1.start();
thread2.start();
}
那么如何避免死锁呢？老生常谈的几个方法。说实话复杂情景下很容易由于理不清关系造成死锁，对于这个问题就需要大家尽量把逻辑和代码进行整理。
- 避免在一个线程同时获取多个锁
- 避免一个线程在锁内同时占用多个资源，尽量保证每个锁之占用一个资源
- 尝试使用定时锁，使用lock.tryLock(timeout)来代替使用内部锁机制
- 对于数据库锁，加锁和解锁必须在一个数据库连接里面，否则会出现解锁失败的情况。
第三个挑战：资源限制的挑战
资源限制包括网速，硬盘读写速度，CPU的处理速度等等。
这个就比较好理解了，比如你的带宽是2M，某个资源的下载速度是1m/s，然后你打算开十个线程，会不会就是10m/s？想多了吧，所以在并发的时候也要考虑这种实际情况，把资源的限制带进去。没有情景的问题是单薄的。所以我们就要根据实际情况来调整程序的并发度。做到不浪费也不溢出。
