码迷,mamicode.com
首页 > 编程语言 > 详细

从生产者消费者窥探线程同步(下)

时间:2016-06-20 10:06:37      阅读:365      评论:0      收藏:0      [点我收藏+]

标签:

欢迎转载,转载请注明出处。尊重他人的一丢丢努力,谢谢啦!
阅读本篇之前,如果你还没有看过从生产者消费者窥探线程同步(上)
,那不妨先戳一下,两篇一起嚼才更好呢。

上一篇分析了使用BlockQueue和synchronized来实现生产者消费者模式。这一篇来看一下其他的实现,闲言少叙。

(3)Lock实现

核心:Lock的用法中规中矩,有点类似于非静态同步方法,只是前者是对lock对象显式加锁,而后者是对当前对象隐式加锁。

我相信大多数人在第一次接触Lock锁的时候,内心都会有这样的疑惑:明明提供了lock就能实现加锁解锁,而这多出来的Condition是干鸡毛的?怎么用?适用场合是啥?

事实上,Java 5之所以提供了Condition接口(可通过Lock.newCondition()来产生),主要是用来解决线程间的通信问题,通过condition的signalAll()和await()方法可以很方便地实现线程间的“广播”或者“悄悄话”。咦那不对吖,用Lock自身的方法岂不更方便?何必又引进Condition呢?

很不幸的是,Lock只是接口,它并不是Object的子类,而这个接口里面也没有提供类似于wait()和notify()的方法。虽然Condition也是个接口,但人家里面提供了signalAll()和await()哇。想来它的这种设计,可能基于这样的考虑:让锁的实现更加细颗粒度,更加精准。

怎么理解呢?不妨先来看张图。

技术分享

椭圆代表了等待lock锁的所有线程集合,而集合A、B和C则是执行不同任务的线程,此刻它们都在原地休整,等待任务的重新开始。

假设Lock里面提供了notify()方法,现在前一个线程执行完毕,Lock的notify()被调用了,它的方法受体是整个椭圆,接下来的场景就是椭圆内的所有线程立刻打了鸡血,原地复活,都去争夺唯一的一把锁,那可真是人仰马翻哭声震天,惨烈程度可想而知。并且很有可能出现的情况是,我只想让执行任务A的线程获取锁资源,偏偏被执行任务B的线程拿到了,然而B检查了一下发现自己并不具备运行的条件,那怎么办?只好放弃锁继续等待呗。这样的情况显然不是我们想看到的。

而Condition很好地处理了这个问题。现在仍然是椭圆里所有的线程都在等待,线程S在使用完锁资源之后,发现目前的条件适合A运行,那就调用A对应Condition实例的notify()方法,于是A内的线程开始躁动,然而B和C却是静悄悄的,就像不知道这回事一样。A中的小a拿到锁之后,离开就开始生产活动,小a在执行结束的时候,发现目前的条件适合B运行,于是她就不动声色地调用B对应Condition实例的notify()方法,然后自己又回去等待休息。B集合中的线程听到调动号令,自然要开始新一轮的争抢,无辜的C集合依然在漫长的等待,等待…

说了这么多,不妨通过代码来看一下。

public class StorageLock {
    public static Integer MAX = 50;
    public static List<Product> list = new ArrayList<>();
    public static Lock lock = new ReentrantLock();
    public static Condition notEmpty = lock.newCondition();
    public static Condition notFull = lock.newCondition();

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        ExecutorService s = Executors.newCachedThreadPool();
        for (int i = 0; i < 20; i++) {
            s.submit(new Producer(10));
            s.submit(new Consumer(5));
        }
    }

    public static void produce(Integer num) {
        lock.lock();
        try {
            while (list.size() + num > MAX) {
                try {
                    System.out.println("数量过大,无法生产");
                    //队列太满了,生产的就先等一下吧,自动释放lock
                    notFull.await();
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
            for (int i = 0; i < num; i++) {
                list.add(new Product(i, ""));
            }
            System.out.println("生产后,存储量为: " + list.size());
            //生产后,队列里面有产品,消费的赶紧去消费吧。
            notEmpty.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public static void consume(Integer num) {
        lock.lock();
        try {
            while (list.size() < num) {
                System.out.println("数量过大,无法消费");
                try {
                    //消费的太多,没那么多货呃,那先等等吧,自动释放lock
                    notEmpty.await();
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }

            for (int i = 0; i < num; i++) {
                list.remove(0);
            }
            System.out.println("消费后,存储量为: " + list.size());
            //消费完了,仓库里有空间,要生产的赶紧去生产吧
            notFull.signalAll();
        } finally {
            lock.unlock();
        }
    }
}

部分输出:

生产后,存储量为: 10
消费后,存储量为: 5
生产后,存储量为: 15
消费后,存储量为: 10
生产后,存储量为: 20
消费后,存储量为: 15
消费后,存储量为: 10
生产后,存储量为: 20
...

这里采用了两个条件notEmpty和notFull,来控制不同角色的线程,前者控制消费行为,后者控制生产行为。当然,你也可以只是用一个条件来控制,比如把程序换成这样:

 public static void produce(Integer num) {
        lock.lock();
        try {
            while (list.size() + num > MAX) {
                try {
                    System.out.println("数量过大,无法生产");
                    notFull.await();
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }

            for (int i = 0; i < num; i++) {
                list.add(new Product(i, ""));
            }

            System.out.println("生产后,存储量为: " + list.size());
            notFull.signalAll();
        } finally {
            lock.unlock();
        }
    }

    public static void consume(Integer num) {
        lock.lock();
        try {
            while (list.size() < num) {
                System.out.println("数量过大,无法消费");
                try {
                    notFull.await();
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }

            for (int i = 0; i < num; i++) {
                list.remove(0);
            }
            System.out.println("消费后,存储量为: " + list.size());
            notFull.signalAll();
        } finally {
            lock.unlock();
        }
    }

部分输出:

生产后,存储量为: 10
生产后,存储量为: 20
消费后,存储量为: 15
消费后,存储量为: 10
消费后,存储量为: 5
消费后,存储量为: 0
数量过大,无法消费
...

结果也完全没问题,只是每执行一次signalAll(),所有线程都来竞争锁资源,增加了锁获取的难度。

(4)不常用的PV实现

PV,高中同学的外号就叫PV,算一算毕业许久,还真有点想念他们呐。

相比于synchronized,信号量Semaphore和互斥量Mutex使用的就少多了。而他们的侧重点也有所不同。synchronized偏重对资源的直接控制。而Semaphore更像是控制访问资源的并发量,它基于CAS(compareAndSwap,一种非阻塞的同步手段)实现,支持公平和不公平机制。Mutex,多用在链表中的锁传递,且这个类不在java.util路径下暂且不提。

拿著名的厕所理论来说吧。假如有5个人要上厕所,厕所有3个坑位。

现在这5个人死脑筋,都要用靠近窗户风景好的那个1号坑,谁也不让谁,只好请synchronized来裁决,synchronized对1号坑位加了锁,你拿到钥匙就去,否则就干等着。

假如这5个人比较现实,都说无所谓用几号坑。但是坑位只有3个,不能全部都进去,也是谁都不让谁,只好请Semaphore来裁决,Semaphore决定发号牌,注意不是对坑位加锁,领到号牌的进去,没领到的干等着。至于进去之后的事,Semaphore就不管了。这个时候进去的A和B看见唯一的公共厕纸质量炒鸡好,都争着去抢,又发生了竟态,就导致另外一个同步问题了。

说了这么多,相信对他们的区别已经有所了解,如果不,请仔细体味后,再继续往下看。

public class StorageSemaphore {
    public static Integer MAX = 50;
    public static List<Product> list = new ArrayList<>();
    // 公平锁,所谓的公平锁,就是讲究顺序,先申请先得。反之不公平锁,就是与大家机会均等,与顺序无关。
    public static Semaphore semaphore = new Semaphore(3, true);

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        ExecutorService s = Executors.newCachedThreadPool();
        for (int i = 0; i < 200; i++) {
            s.submit(new Producer(10));
            s.submit(new Consumer(5));
        }
    }

    public static void produce(Integer num) {
        try {
            semaphore.acquire();
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        // synchronized (StorageSemaphore.class) {

        while (list.size() + num < MAX) {
            for (int i = 0; i < num; i++) {
                list.add(new Product(i, ""));
            }
            System.out.println(Thread.currentThread().getName() + "\t已经生产数:"
                    + num + "\t现仓储量为:" + list.size());
        }
        System.out.println("要生产的数量:" + num + "\t库存量:" + list.size()
                + "\t暂时不能执行生产任务!");
        // }
        semaphore.release();
    }

    public static void consume(Integer num) {
        try {
            semaphore.acquire();
        } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        // synchronized (StorageSemaphore.class) {

        while (list.size() > num) {
            for (int i = 0; i < num; i++) {
                list.remove(0);
            }
            System.out.println(Thread.currentThread().getName() + "\t已经消费数:"
                    + num + "\t现仓储量为:" + list.size());
        }
        System.out.println("要消费的数量:" + num + "\t库存量:" + list.size()
                + "\t暂时不能执行消费任务!");
        // }
        semaphore.release();
    }
}

部分运行结果:

...
pool-1-thread-107   已经消费数:5 现仓储量为:35
pool-1-thread-108   已经消费数:5 现仓储量为:30
pool-1-thread-110   已经消费数:5 现仓储量为:36
pool-1-thread-111   已经生产数:10    现仓储量为:36
pool-1-thread-109   已经生产数:10    现仓储量为:46
pool-1-thread-112   已经消费数:5 现仓储量为:41
pool-1-thread-113   已经消费数:5 现仓储量为:36
pool-1-thread-115   已经生产数:10    现仓储量为:46
...

敏感的同学可能已经注意到了,怎么出现36和41这样的数据呢,我们代码中无论生产和消费都是5的倍数呀(注意不同的机器上运行效果可能不一样,请多运行几次,肯定会有类似情况)。唯一的解释就是出现了内部争夺”厕纸”的情况。不妨把注释同步的部分去掉,再运行一下看看。

这次无论你运行多少次,输出都不会有异常的数据。那,完美了?

并没有。狂汗…

先来看个问题,前面我们已经分析过使用if()会导致的后果,而在这段程序里如果你使用if(),得到的效果其实是一样的。究其原因,这里的程序并没有使用拥塞控制策略,也就是说一个线程如果不满足生产条件,那么它将结束自己,而不是循环中等待条件合适后继续生产,所以也就没什么区别了。若有疑问的话,可以自己动手尝试验证。

除了加synchronized同步块之外,那就没有别的办法了?我们还有个互斥量Mutex没用呢。下面用binary semaphore来模拟一下。将上面代码的public static Semaphore semaphore = new Semaphore(3, true);修改为public static Semaphore semaphore = new Semaphore(1, true);,其他的都不用动,同步问题就解决了。

但问题到这里并没有结束,上面已经说过,程序里没有采用拥塞控制,虽然解决了同步,但它用的实际上是一种抛弃策略:想生产的不能保证都能生产到,该消费的也不保证都能消费到。这是它的弊端,但这并不影响它满足生产者消费者模式的6个条件(啥条件?忘记的话,请回到上一篇查看)。

如果你精力充沛,完全可以在synchronized里面添加对象的notify()和wait()操作(天呐,人生都如此艰难了,何必为难自己呐…),不过要注意多重锁极易造成死锁,倒不如放弃semaphore直接使用synchronized来得直接。

(5)总是被误用的volatile

volatile很诱人,也很容易被用错。关于它,你只要记住一句话:volatile能保证从主内存读取到最新的值,但它并不是线程安全的。

这里还是说一下,Java内存模型讨论的线程安全一般都是围绕这原子性、可见性、有序性这三个方面来考虑的(速记规则:”可有缘”)。

volatile的内存同步机制保证了可见性,本身的禁止指令重排语义保证了有序性,但致命的是,它保证不了原子性。

一般说来JVM提供的原子操作,只有8个,分别是lock、unlock、read、load、assign、use、store和write(速记规则”allrsuuw”)。

常用的synchronized三个条件统统满足,也是jvm比较倚重的锁实现方式。相比volatile来说,synchronized在字节码层面提供了monitorenter(lock)和monitorexit(unlock)操作,从而保证了操作的原子性。

回到我们的话题。

得,直接看代码吧。

public class StorageVolatile {

    public static Integer MAX = 50;
    public static volatile List<Product> list = new ArrayList<>();

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        ExecutorService s = Executors.newCachedThreadPool();
        for (int i = 0; i < 200; i++) {
            s.submit(new Producer(5));
            s.submit(new Consumer(10));
        }
    }

    public static void produce(Integer num) {
        if (list.size() + num > MAX) {
            System.out.println(Thread.currentThread().getName()
                    + " 我是生产,我在等待... ");
        } else {
            for (int i = 0; i < num; i++) {
                list.add(new Product(i, ""));
            }
            System.out.println(Thread.currentThread().getName() + " 库存: "
                    + list.size());
        }
    }

    public static void consume(Integer num) {
        if (list.size() < num) {
            System.out.println(Thread.currentThread().getName()
                    + " 我是消费,我在等待... ");
        } else {
            for (int i = 0; i < num; i++) {
                list.remove(i);
            }
            System.out.println(Thread.currentThread().getName() + " 库存: "
                    + list.size());
        }
    }
}

部分输出

pool-1-thread-1 库存: 5
pool-1-thread-1 库存: 10
pool-1-thread-1 库存: 15
pool-1-thread-1 库存: 20
pool-1-thread-1 库存: 10
pool-1-thread-1 库存: 10
pool-1-thread-1 库存: 12
pool-1-thread-1 库存: 12
pool-1-thread-1 库存: 17
pool-1-thread-4 我是消费,我在等待... 
pool-1-thread-1 库存: 13
pool-1-thread-4 库存: 18

从输出可以发现,我们的生产和消费都是5的倍数,结果却出现了12,17这样的“异类”,也印证了我们的分析。

要用它来实现生产者和消费者模式,就必须借助synchronized或者lock锁,那样的话实际上又回到前三种方案了,感兴趣的娃娃请自行尝试吧。

(6)温和而低调的ThreadLocal

从实现原理上说,ThreadLocal与生产者消费者模式根本就不搭界。把它放在此处说,算是探究线程同步的延伸。

如果说前面的synchronized、Lock,还是BlockQueue(内部也是Lock实现的)、semaphore等PV操作,甚至是volatile关键字,它们都是从或者试图从(volatile就不是安全的)资源的访问权限上(存在竟态)来处理线程同步问题,那ThreadLocal则提供了另外一种完全不同的思路:从资源本身下手消除竟态。

具体来说,就是ThreadLocal为每个线程都提供了一份单独的资源,维护在它的静态内部类ThreadLocalMap中,和平共处互不干扰。它的思路就是,你们不是吃不饱吗你们不是抢吗,来,我就给你们每个人各搞一份,这下都满足了吧,你们这群难伺候的程序,汗…

ThreadLocal类本身使用起来也很方便,主要是get()和set()操作。所以在遇到不需要保证资源一致性的并发场景时,使用ThreadLocal类不失为一种优雅的解决方案。

那它到底该怎么使用呢?不妨来看一下代码(与生产者消费者模式无关)。

public class StorageThreadLocal {
    public static Integer MAX = 50;
    public static List<Product> listInit = new ArrayList<Product>();
    public static ThreadLocal<List<Product>> list = new ThreadLocal<List<Product>>() {
        @Override
        protected List<Product> initialValue() {
            // TODO Auto-generated method stub
            return new ArrayList<Product>();
        }
    };

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        ExecutorService s = Executors.newCachedThreadPool();
        for (int i = 0; i < 20; i++) {
            s.submit(new Producer(10));
            s.submit(new Consumer(10));
        }
    }

    public static void produce(Integer num) {
        List<Product> listP = list.get();
        while (listP.size() + num <= MAX) {
            listP.add(new Product(1, ""));
            System.out.println(Thread.currentThread().getName() + " 库存: "
                    + listP.size());
        }
        list.set(listP);
    }

    public static void consume(Integer num) {
        List<Product> listC = list.get();
        while (listC.size() < num) {
            listC.remove(0);        System.out.println(Thread.currentThread().getName() + " 库存: "
                    + listC.size());
        }
        list.set(listC);
    }
}

部分输出:

pool-1-thread-1 库存: 1
pool-1-thread-1 库存: 2
pool-1-thread-1 库存: 3
pool-1-thread-1 库存: 4
pool-1-thread-1 库存: 5
pool-1-thread-1 库存: 6
pool-1-thread-1 库存: 7
pool-1-thread-1 库存: 8
pool-1-thread-3 库存: 1
pool-1-thread-3 库存: 2
pool-1-thread-3 库存: 3
pool-1-thread-2 库存: 1
pool-1-thread-2 库存: 2
pool-1-thread-2 库存: 3
pool-1-thread-2 库存: 4
pool-1-thread-2 库存: 5
pool-1-thread-2 库存: 6
pool-1-thread-2 库存: 7
pool-1-thread-2 库存: 8
pool-1-thread-2 库存: 9
pool-1-thread-2 库存: 10
pool-1-thread-2 库存: 11
pool-1-thread-2 库存: 12
pool-1-thread-2 库存: 13
...

很明显,各个线程都有自己队列,大家互不干涉内政,和和气气,愉快生产,再也没有脸红耳赤的尴尬场面了…

总结:
常见的线程同步方案大概就这几种吧,而它们也分别代表了文章开头说的线程同步的三种实现方式,阻塞方式(synchronized、java.util.concurrent包中提供的各种集合(Lock同步))、非阻塞方式(Lock的内部实现)和本身就是安全的代码(ThreadLocal)。各有各的应用特点和应用场景,总的来说,synchronized的效率要高于Lock,毕竟是JVM原生的,但也是应用最广泛最泛滥的;而ThreadLocal的实现机理与前两者都不同,不好直接做比较。

回到生产者和消费者模式上,虽然文中给了四种实现方式,但PV操作的实现必须借助synchronized,所以还是要以前三种为主。

一窥之见,难免疏漏,有不到或待商榷之处,还请来往诸君在留言区热心提出,热烈讨论,热情补充,大家一块学习一起进步,何尝不是人生一乐事呢。

从生产者消费者窥探线程同步(下)

标签:

原文地址:http://blog.csdn.net/luochoudan/article/details/51698313

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!