|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-07-13
melin 写道 sdh5724 写道 性能不好， 用了同步。 可以分割同步。
每个线程存放自己相加的结果，计算完以后，再相加各个线程统计的结果，避免了同步。 哦，原来这样，那这样就需要Callable和Future了。 |
| 返回顶楼 | |
|
发表时间：2010-07-13
真的很讨厌je拷贝代码时，前有行数号。讨厌之极 啊
|
| 返回顶楼 | |
|
发表时间：2010-07-13
来不及看所有的恢复，但是提醒大家注意，在注意算法的同时，注意越界的问题。
两个int相加，都可能越界，何况“很大的List”。所以实战的话，可能需要BigInteger。 而BigInteger的话，更体现了线程的优势。N个较小的BI相加，比一个巨大的BI参与的计算快多了。 |
| 返回顶楼 | |
|
发表时间：2010-07-13
个人觉的你的这些算法啊，线程操作可能都是白忙活，或者说对这种问题处理的很浅，还不深入。算法挺简单的实现起来也有很多办法，多线程调度什么的也都是基本java知识。
我个人觉的的你要抓住问题的重点，要是用多cpu充分发挥多cpu的优势，首先要把任务分发，你只是起多个线程并不一定操作jvm和操作系统就会把任务分发到多cpu上执行，只有可能时间片切的更小，在执行这些任务。 所以这个过程中考虑的重点应该是 1：操作系统（开多个jvm，规定每个jvm进程运行在指定cpu上，肯定比一个进程下的多个线程只占用一个cpu对多cpu的压榨更好） 2：jvm调整（大数据量必然涉及到垃圾回收） 3：程序编写 上面这些弄好了，再深入一点就考虑，同步消耗问题 cpu多了，同步因素也是决定是否能把多cpu和性能转化率提高出来的一个重要环节。 |
| 返回顶楼 | |
|
发表时间：2010-07-13
melin 写道 sdh5724 写道 性能不好， 用了同步。 可以分割同步。
每个线程存放自己相加的结果，计算完以后，再相加各个线程统计的结果，避免了同步。 这个严重同意。用不到那么大的synchronize. |
| 返回顶楼 | |
|
发表时间：2010-07-13
captmjc 写道 来不及看所有的恢复，但是提醒大家注意，在注意算法的同时，注意越界的问题。
两个int相加，都可能越界，何况“很大的List”。所以实战的话，可能需要BigInteger。 而BigInteger的话，更体现了线程的优势。N个较小的BI相加，比一个巨大的BI参与的计算快多了。 同意！ |
| 返回顶楼 | |
|
发表时间：2010-07-13
viei 写道 个人觉的你的这些算法啊，线程操作可能都是白忙活，或者说对这种问题处理的很浅，还不深入。算法挺简单的实现起来也有很多办法，多线程调度什么的也都是基本java知识。
我个人觉的的你要抓住问题的重点，要是用多cpu充分发挥多cpu的优势，首先要把任务分发，你只是起多个线程并不一定操作jvm和操作系统就会把任务分发到多cpu上执行，只有可能时间片切的更小，在执行这些任务。 所以这个过程中考虑的重点应该是 1：操作系统（开多个jvm，规定每个jvm进程运行在指定cpu上，肯定比一个进程下的多个线程只占用一个cpu对多cpu的压榨更好） 2：jvm调整（大数据量必然涉及到垃圾回收） 3：程序编写 上面这些弄好了，再深入一点就考虑，同步消耗问题 cpu多了，同步因素也是决定是否能把多cpu和性能转化率提高出来的一个重要环节。 怎么指定一个jvm对应单个cpu ,高手？ |
| 返回顶楼 | |
|
发表时间：2010-07-13
阿里巴巴也问过我类似的问题
|
| 返回顶楼 | |
|
发表时间：2010-07-13
ExecutorCompletionService和Executor配合就行了。
CyclicBarrier和CountDownLatch和BlockingQueue提供了相同的语义,条件阻塞，说白了还是AbstractQuquedSynchronizor的实现。 |
| 返回顶楼 | |
|
发表时间：2010-07-13
dilantaya 写道 sunwenran 写道 赞一个。
问题是我用你的例子比较直接加 long noCurrentSum=0L; for(Integer i:list){ noCurrentSum+=i; } 发现时间差不多。而且有时候直接加更快。纠结了。。我的是双核。 可能是你给的数据量还不够大 调整到50000000 for (int i = 1; i <= 50000000; i++) { list.add(i); } 单线程时间比并发更快 |
| 返回顶楼 | |
