用门闩CountDownLatch
- 用门闩
- t2如果不等于5,就latch.await等着
- t1中当size等于5是latch.countDown
- 门闩会不会被击穿???
/** * 曾经的面试题:(淘宝?) * 实现一个容器,提供两个方法,add,size * 写两个线程,线程1添加10个元素到容器中,线程2实现监控元素的个数,当个数到5个时,线程2给出提示并结束 * * 给lists添加volatile之后,t2能够接到通知,但是,t2线程的死循环很浪费cpu,如果不用死循环,该怎么做呢? * * 这里使用wait和notify做到,wait会释放锁,而notify不会释放锁 * 需要注意的是,运用这种方法,必须要保证t2先执行,也就是首先让t2监听才可以 * * 阅读下面的程序,并分析输出结果 * 可以读到输出结果并不是size=5时t2退出,而是t1结束时t2才接收到通知而退出 * 想想这是为什么? * * notify之后,t1必须释放锁,t2退出后,也必须notify,通知t1继续执行 * 整个通信过程比较繁琐 * * 使用Latch(门闩)替代wait notify来进行通知 * 好处是通信方式简单,同时也可以指定等待时间 * 使用await和countdown方法替代wait和notify * CountDownLatch不涉及锁定,当count的值为零时当前线程继续运行 * 当不涉及同步,只是涉及线程通信的时候,用synchronized + wait/notify就显得太重了 * 这时应该考虑countdownlatch/cyclicbarrier/semaphore * @author mashibing */package com.mashibing.juc.c_020_01_Interview;import java.util.ArrayList;import java.util.List;import java.util.concurrent.CountDownLatch;import java.util.concurrent.TimeUnit;public class T05_CountDownLatch { // 添加volatile,使t2能够得到通知 volatile List lists = new ArrayList(); public void add(Object o) { lists.add(o); } public int size() { return lists.size(); } public static void main(String[] args) { T05_CountDownLatch c = new T05_CountDownLatch(); CountDownLatch latch = new CountDownLatch(1); new Thread(() -> { System.out.println("t2启动"); if (c.size() != 5) { try { latch.await(); //也可以指定等待时间 //latch.await(5000, TimeUnit.MILLISECONDS); } catch (InterruptedException e) { e.printStackTrace(); } } System.out.println("t2 结束"); }, "t2").start(); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e1) { e1.printStackTrace(); } new Thread(() -> { System.out.println("t1启动"); for (int i = 0; i < 10; i++) { c.add(new Object()); System.out.println("add " + i); if (c.size() == 5) { // 打开门闩,让t2得以执行 latch.countDown(); } /*try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }*/ } }, "t1").start(); }}
上述程序存在的问题
- 当去掉t1中的sleep之后,会出错
- 线程运行的太快了—->打印太快了,该加锁,让t2在正确的位置输出
- 确实打开了,但是t1会继续向下运行,等t2打印出来就到后面了
- 正确做法:用两只门闩
- 一只最开始就拴住t2,在t1中等于5时打开
- 一只在等于5时拴住t1,在t2要结束的时候打开
- 用两个门闩就可以正确完成这个功能了—->和两对wait、notify是一个道理
- t1中sleep的作用是留时间给t2唤醒并输出
用简单方法LockSupport(最方便)
- 在t2中不等于5时park,在t1中等于5时unpark
- 最方便的写法—->本质和wait、notify差不多
/** * 曾经的面试题:(淘宝?) * 实现一个容器,提供两个方法,add,size * 写两个线程,线程1添加10个元素到容器中,线程2实现监控元素的个数,当个数到5个时,线程2给出提示并结束 * * 给lists添加volatile之后,t2能够接到通知,但是,t2线程的死循环很浪费cpu,如果不用死循环,该怎么做呢? * * 这里使用wait和notify做到,wait会释放锁,而notify不会释放锁 * 需要注意的是,运用这种方法,必须要保证t2先执行,也就是首先让t2监听才可以 * * 阅读下面的程序,并分析输出结果 * 可以读到输出结果并不是size=5时t2退出,而是t1结束时t2才接收到通知而退出 * 想想这是为什么? * * notify之后,t1必须释放锁,t2退出后,也必须notify,通知t1继续执行 * 整个通信过程比较繁琐 * * 使用Latch(门闩)替代wait notify来进行通知 * 好处是通信方式简单,同时也可以指定等待时间 * 使用await和countdown方法替代wait和notify * CountDownLatch不涉及锁定,当count的值为零时当前线程继续运行 * 当不涉及同步,只是涉及线程通信的时候,用synchronized + wait/notify就显得太重了 * 这时应该考虑countdownlatch/cyclicbarrier/semaphore * @author mashibing */package com.mashibing.juc.c_020_01_Interview;import java.util.ArrayList;import java.util.List;import java.util.concurrent.CountDownLatch;import java.util.concurrent.TimeUnit;import java.util.concurrent.locks.LockSupport;//TODO park unparkpublic class T06_LockSupport { // 添加volatile,使t2能够得到通知 volatile List lists = new ArrayList(); public void add(Object o) { lists.add(o); } public int size() { return lists.size(); } public static void main(String[] args) { T06_LockSupport c = new T06_LockSupport(); CountDownLatch latch = new CountDownLatch(1); Thread t2 = new Thread(() -> { System.out.println("t2启动"); if (c.size() != 5) { LockSupport.park(); } System.out.println("t2 结束"); }, "t2"); t2.start(); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e1) { e1.printStackTrace(); } new Thread(() -> { System.out.println("t1启动"); for (int i = 0; i < 10; i++) { c.add(new Object()); System.out.println("add " + i); if (c.size() == 5) { LockSupport.unpark(t2); } /*try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }*/ } }, "t1").start(); }}
上述程序存在和单个门闩相同的问题
- 解决方案:用两个LockSupport
- 在t1等于5时,先调用unpark解除t2的阻塞,再调用park将自己阻塞,等待t2线程的执行输出
- 当t2执行结束,t2调用unpark将t1的阻塞状态解除,让t1继续向下执行
- 必须保证t2先执行
- 本质上和wait、notify差不多!!!
- 不会出现t2来不及运行,t1直接运行完的情况,因为t1会在等于5是park自己
- t2中的等于5的判断可以不用,可以一上来就将自己park
- 线程t1中unpark(t2)在park之前是可以的,因为unpark(t2)只能解除t2的阻塞而不能解除t1的阻塞,unpark是有针对性的
- t1不park时,可能会出现当t1已经输出了6、7个元素的时候,t2才会得到继续向下运行的机会—->是一个抢占cpu时间片的过程(线程调度器、线程调度算法!!!)—->可能会出现即使将t2唤醒了,t2也得不到执行的机会,而t1执行得非常快,造成t1继续向下打印输出而t2要过会才能输出!!!(要过会才能得到输出的机会)
- 多线程的程序得多探讨!!!
/** * 曾经的面试题:(淘宝?) * 实现一个容器,提供两个方法,add,size * 写两个线程,线程1添加10个元素到容器中,线程2实现监控元素的个数,当个数到5个时,线程2给出提示并结束 * * 给lists添加volatile之后,t2能够接到通知,但是,t2线程的死循环很浪费cpu,如果不用死循环,该怎么做呢? * * 这里使用wait和notify做到,wait会释放锁,而notify不会释放锁 * 需要注意的是,运用这种方法,必须要保证t2先执行,也就是首先让t2监听才可以 * * 阅读下面的程序,并分析输出结果 * 可以读到输出结果并不是size=5时t2退出,而是t1结束时t2才接收到通知而退出 * 想想这是为什么? * * notify之后,t1必须释放锁,t2退出后,也必须notify,通知t1继续执行 * 整个通信过程比较繁琐 * * 使用Latch(门闩)替代wait notify来进行通知 * 好处是通信方式简单,同时也可以指定等待时间 * 使用await和countdown方法替代wait和notify * CountDownLatch不涉及锁定,当count的值为零时当前线程继续运行 * 当不涉及同步,只是涉及线程通信的时候,用synchronized + wait/notify就显得太重了 * 这时应该考虑countdownlatch/cyclicbarrier/semaphore * @author mashibing */package com.mashibing.juc.c_020_01_Interview;import java.util.ArrayList;import java.util.List;import java.util.concurrent.CountDownLatch;import java.util.concurrent.TimeUnit;import java.util.concurrent.locks.LockSupport;//TODO park unparkpublic class T07_LockSupport_WithoutSleep { // 添加volatile,使t2能够得到通知 volatile List lists = new ArrayList(); public void add(Object o) { lists.add(o); } public int size() { return lists.size(); } static Thread t1 = null, t2 = null; public static void main(String[] args) { T07_LockSupport_WithoutSleep c = new T07_LockSupport_WithoutSleep(); t1 = new Thread(() -> { System.out.println("t1启动"); for (int i = 0; i < 10; i++) { c.add(new Object()); System.out.println("add " + i); if (c.size() == 5) { LockSupport.unpark(t2); LockSupport.park(); } } }, "t1"); t2 = new Thread(() -> { //System.out.println("t2启动"); //if (c.size() != 5) { LockSupport.park(); //} System.out.println("t2 结束"); LockSupport.unpark(t1); }, "t2"); t2.start(); t1.start(); }}
🤏随想
- java可以先给变量进行声明,声明了之后再进行赋值;这样就不存在两个变量循环依赖但另一个变量没有定义的情况了!!!

- lambda表达式中必须是final或者effectively final的
