第一章:并发编程的挑战①

2018-11-12  本文已影响80人  猪_队友

我们的认知里,并发编程的目的是为了让程序运行的更快,更能充分利用现在的多核CPU。但是多线程就一定快吗?什么时候应该用多线程呢?这需要面临很多的挑战,也挑战着我们的认知。

首先我们要明白一个道理,没有免费的午餐,一切皆有成本。

第一个挑战:上下文切换

单核处理器也是支持多线程执行的。CPU会给每个线程分配CPU时间片来实现这个机制。这个时间通常很短(通常几十毫秒),所以CPU需要不停的切换线程去执行程序。在我们的感知里面就是同时执行的。

那么问题来了,CPU这么随意的切换不会混乱吗?这就需要保存上一个任务的状态了,也就是说任务从保存到再次加载的过程就是一个上下文的切换。用心的朋友肯定想到了,既然会保存状态,那么一定需要额外消耗,势必会影响效率。

举个例子,比如我们正在写数学题,突然有人敲门,你去开门,看看谁来了,有什么事,完事之后回来继续解题,那么就需要你记得你写到哪一道题了,写到哪一步了,之前的思路是如何的等等。所以上下文的切换会影响多线程的执行速度。

大家可以自己写一个小demo自己测试下。

下图是单线程和双线程的时间对比(参考一下就行了)

打脸数据

结论就是:线程的创建和上下文的切换都是有开销的,如果你的任务比这个开销要轻量,那么单线程比较好,如果比较重,那么多线程一定会大大的节约你的时间。

那么如何减少上下文的切换呢?

1、无锁并发编程
多线程竞争锁的时候会引起上下问的切换,所以可以用一些方法来避免使用锁,比如处理一段数据,我们可以不同线程处理不同位置的数据,互不干扰。

2、CAS算法
Java的Atomic包使用CAS算法来更新数据,而不需要加锁。

CAS是什么?

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();

    }

那么如何避免死锁呢?老生常谈的几个方法。说实话复杂情景下很容易由于理不清关系造成死锁,对于这个问题就需要大家尽量把逻辑和代码进行整理。

第三个挑战:资源限制的挑战

资源限制包括网速,硬盘读写速度,CPU的处理速度等等。

这个就比较好理解了,比如你的带宽是2M,某个资源的下载速度是1m/s,然后你打算开十个线程,会不会就是10m/s?想多了吧,所以在并发的时候也要考虑这种实际情况,把资源的限制带进去。没有情景的问题是单薄的。所以我们就要根据实际情况来调整程序的并发度。做到不浪费也不溢出。

上一篇下一篇

猜你喜欢

热点阅读