`
linchao198401
  • 浏览: 6986 次
  • 性别: Icon_minigender_1
  • 来自: 上海
最近访客 更多访客>>
社区版块
存档分类
最新评论

答复: 淘宝面试题:如何充分利用多核CPU,计算很大的List中所有整数的和

阅读更多
lanxiazhi 写道
看过主贴和评论,学习了。
发现的问题:
(1)CyclicBarrier不适合这种并发任务。单个线程完成任务之后完全可以终止了,没必要全部等待着,这可能是很大的资源浪费。使用CountDownLatch也会有这个问题。
(2)楼主使用了线程同步,考虑到同步的代价,这是可能是个很大的时间浪费。
(3)楼主使用CyclicBarrier的唯一用处在于,保证所有的任务都完成了。但是杀鸡焉用牛刀?这可能是...的浪费

  其实实现这样的功能,可以不用那么复杂,而且可以不用加锁。这里需要一个AtomicInteger(设为atom)。每个线程获得自己的sublist求和任务之后,计算一个和,保存到某个成员变量(设为subsum)中(如某楼上所说),把那个atom加1,然后结束。
  在主方法中,启动所有线程,然后添加一条语句,等待所有线程完成任务:
while(atom.intValue()<threadCounts)
  Thread.yield();
最后从所有死掉的线程对象中,获取subsum并累加即可。




我比较同意lanxianzhi的说法。
使用CountDownLatch,其他所有的计算线程都在计算,最后输出的线程肯定在等所有的线程算好才行。
更进一步的问题是:如果我想知道目前算好的实时总数是多少,以及目前多少个线程已经算好了,那么使用CountDownLatch是没有办法的。
比如,有10000个计算线程,一个输出线程在wait,输出线程只能等10000个计算线程都计算完,wait才会结束,然后才能输出。只有一次输出。

也许你想在计算的线程里面把目前被同步的sum给实时打印出来,这样每个计算线程计算结束之后就把当时的实时的结果打印出来,那么计算线程就不符合单一责任原则了。

对于目前已经完成多少个任务,再加个线程共享的变量(任务完成计数器)来自增也不好。
就算用上AtomicInteger也是一种负担。

所以我不觉得应该使用CountDownLatch

线程同步synchronized是不需要的,用AtomicInteger会快一些。

CyclicBarrier就更不需要了,我没有写代码测试,但是按照我的理解,如果你开启11个线程,10个线程在计算,1个线程等待输出,只有当所有线程都执行到await()才能继续。
如果你开的线程就上千个,那么且不是上千个线程都在那边等待?

我还是推荐使用ExecutorCompleteionService

1. ExecutorCompleteionService可以随时拿到完成计算的线程的结果,然后在这个基础上继续进行加运算,而且不需要创建一个在线程之间共享的变量,每个线程有自己的结果变量,这个变量最终会作为task的结果之一返回。
2. 可以随时知道完成的计算线程的计数,当然需要ExecutorCompleteionService执行够快才行,如果计算线程执行很快就结束的话,完成的线程数会不准

我没有在机子上试
贴个Java核心技术的例子代码
ExecutorCompleteionService service = new ExecutorCompleteionService(executor);
for(Callable<Integer> task : tasks) {
    service.submit(task);
}
for(int i = 0; i < tasks.size(); i++) {
    count += service.take().get();// 如果有线程返回,马上可以得到结果,如果没有任何线程返回,阻塞等待结果
}
这里不需要sum这个所有的线程都共享的变量。因此也不需要同步或者AtomicInteger。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics