线程障碍,其实就是为线程制作一个集合点,相关知识网上一堆。
这次主要记录一下使用CyclicBarrier遇到的一点小问题。
需求:在主线程中创建两个子线程,希望能在子线程执行完成之后再执行主线程中的剩余代码。
代码一:
package com.iteye.wwwcomy.thread; import java.util.concurrent.BrokenBarrierException; import java.util.concurrent.CyclicBarrier; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class RaceCondition implements Runnable { Counter counter; final static CyclicBarrier cb = new CyclicBarrier(2, new Runnable() { @Override public void run() { System.out.println(Thread.currentThread().getName() + "执行"); } }); RaceCondition() { } RaceCondition(Counter counter) { this.counter = counter; } /** * @param args * @throws Exception */ public static void main(String[] args) throws Exception { Counter counter = new Counter(); ExecutorService service = Executors.newCachedThreadPool(); Thread t1 = new Thread(new RaceCondition(counter)); Thread t2 = new Thread(new RaceCondition(counter)); service.execute(t1); service.execute(t2); service.shutdown(); System.out.println(counter.count); } @Override public void run() { for (int i = 0; i < 5000000; i++) counter.add(1); try { System.out.println("before"); cb.await(); System.out.println("complete"); } catch (InterruptedException e) { e.printStackTrace(); } catch (BrokenBarrierException e) { e.printStackTrace(); } finally { } } } class Counter { /** * 此处加上volatile并没有起到预期作用,依旧要把方法同步 * NOTICE 这里count的值的范围是多少? * 循环十次的极限情况: * 1.线程一拿到了0,等待线程二 * 2.线程二拿到了0,并且计算了9次,得到结果9并且写了回去 * 3.线程一第一次计算完,并且把1写入 * 4.线程二第十次取到了1 * 5.线程一计算完成,把结果写入 * 6.线程二把第十次的计算结果2写入 */ protected volatile long count = 0; public void add(long value) { this.count++; } }
结果发现: 主线程依旧在子线程之前执行到了。
再看代码二:
package com.iteye.wwwcomy.thread; import java.util.ArrayList; import java.util.concurrent.Callable; import java.util.concurrent.CyclicBarrier; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class RaceConditionWithCyclicBarrier implements Callable<Boolean> { Counter2 counter; static CyclicBarrier cb = null; RaceConditionWithCyclicBarrier() { } RaceConditionWithCyclicBarrier(Counter2 counter) { this.counter = counter; } /** * @param args * @throws Throwable */ public static void main(String[] args) throws Throwable { Counter2 counter = new Counter2(); cb = new CyclicBarrier(2, new Runnable() { // 等到线程到达后执行一个后续task @Override public void run() { System.out.println(Thread.currentThread().getName() + "a"); } }); ArrayList<Callable<Boolean>> listCall = new ArrayList<Callable<Boolean>>(); listCall.add(new RaceConditionWithCyclicBarrier(counter)); listCall.add(new RaceConditionWithCyclicBarrier(counter)); ExecutorService executor = Executors.newFixedThreadPool(2); // 必须是allThread的个数 try { executor.invokeAll(listCall); } catch (Throwable e) { executor.shutdown(); throw e; } finally { System.out.println("over"); } executor.shutdown(); // 这句是在所有线程都跑完之后才会执行 System.out.println(counter.count); } @Override public Boolean call() throws Exception { for (int i = 0; i < 500000; i++) counter.add(1); cb.await(); return true; } } class Counter2 { /** * 此处加上volatile并没有起到预期作用,依旧要把方法同步 * NOTICE 这里count的值的范围是多少? * 循环十次的极限情况: * 1.线程一拿到了0,等待线程二 * 2.线程二拿到了0,并且计算了9次,得到结果9并且写了回去 * 3.线程一第一次计算完,并且把1写入 * 4.线程二第十次取到了1 * 5.线程一计算完成,把结果写入 * 6.线程二把第十次的计算结果2写入 */ protected volatile long count = 0; public void add(long value) { this.count++; } }
竟然发现这次主线程在executor.invokeAll(listCall);后被挂起了,直到子线程执行完成之后才执行。
其实就是使用Runnable和Callable之后executor的API使用不同而已,怎么结果差距这么大。
断个点,在visualVM里面dump了一下线程发现Callable的executor执行代码中将主线程挂起了,见线程堆栈,具体源码按照堆栈进去跟就是了:
引用
"pool-1-thread-2" prio=6 tid=0x00000000067f7800 nid=0x1534 at breakpoint[0x000000000876f000]
java.lang.Thread.State: RUNNABLE
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:60)
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000007d5f2ca10> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"pool-1-thread-1" prio=6 tid=0x00000000067f6800 nid=0x1da4 at breakpoint[0x000000000866f000]
java.lang.Thread.State: RUNNABLE
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:60)
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000007d5f2c7d8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"main" prio=6 tid=0x00000000002ae800 nid=0x168c waiting on condition [0x000000000251f000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007d5f2c770> (a java.util.concurrent.FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:205)
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.main(RaceConditionWithCyclicBarrier.java:46)
Locked ownable synchronizers:
- None
java.lang.Thread.State: RUNNABLE
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:60)
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000007d5f2ca10> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"pool-1-thread-1" prio=6 tid=0x00000000067f6800 nid=0x1da4 at breakpoint[0x000000000866f000]
java.lang.Thread.State: RUNNABLE
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:60)
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.call(RaceConditionWithCyclicBarrier.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Locked ownable synchronizers:
- <0x00000007d5f2c7d8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"main" prio=6 tid=0x00000000002ae800 nid=0x168c waiting on condition [0x000000000251f000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000007d5f2c770> (a java.util.concurrent.FutureTask$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)
at java.util.concurrent.FutureTask.get(FutureTask.java:83)
at java.util.concurrent.AbstractExecutorService.invokeAll(AbstractExecutorService.java:205)
at com.iteye.wwwcomy.thread.RaceConditionWithCyclicBarrier.main(RaceConditionWithCyclicBarrier.java:46)
Locked ownable synchronizers:
- None
可见只有代码二的做法才能使主线程在子线程完成之后再执行,CyclicBarrier自身并不保证主线程在子线程完成之后执行。
CyclicBarrier仅仅是为调用await方法的线程设置一个集合点![/b]
[b]代码一的写法其实稍微做一点改变,也可以实现效果:
1.修改CyclicBarrier的初始线程数+1,
2.在主线程里面也加入 cb.await(); 就可以了
当时先写的代码二,所以有点先入为主了。。本来正在研究volatile,遇到这个问题先记录一下。
另外,CyclicBarrier的第二个参数,是使用最后一个执行完的线程执行的。
----2017.05.10补充-------------
最近在面试,又回看了一下当时写的这个blog,实际上代码二中主线程在子线程之后执行的原因是调用的executor方法不同,这个在blog里面没提出来,
代码一里面使用的是(submit方法同样,区别见http://stackoverflow.com/questions/3929342/choose-between-executorservices-submit-and-executorservices-execute)
executor.execute()
代码二里面使用的是
executor.invokeAll()
代码二中会在子线程执行完之后才执行主线程的后续内容。代码一会直接执行主线程后续内容。