第一章:并发编程的挑战①
我们的认知里,并发编程的目的是为了让程序运行的更快,更能充分利用现在的多核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?想多了吧,所以在并发的时候也要考虑这种实际情况,把资源的限制带进去。没有情景的问题是单薄的。所以我们就要根据实际情况来调整程序的并发度。做到不浪费也不溢出。