Tag: java.util.concurrent无

LinkedBlockingQueue和ConcurrentLinkedQueue之间有什么不同？

我已经阅读了博客，但我不确定他的结论是否正确： http://www.javacodegeeks.com/2010/09/java-best-practices-queue-battle-and.html#ixzz1seaiSLwp 他说： 从提供的性能结果可以看出，LinkedBlockingQueue实现了最佳的组合（添加和删除元素）性能结果，应该是实现生产者 – 消费者schenarios的头号候选者。 我想知道，如果我不在我的代码中使用锁，那么它不会更快吗？ 那么为什么LinkedBlockingQueue比无锁队列（ConcurrentLinkedQueue）更快？ 谢谢 ！

ForkJoinPool在invokeAll / join期间停止

我尝试使用ForkJoinPool来并行化我的CPU密集型计算。 我对ForkJoinPool的理解是，只要任何任务可以执行，它就会继续工作。 不幸的是，我经常观察到工作线程空闲/等待，因此并非所有CPU都保持忙碌状态。 有时我甚至观察到额外的工作线程。 我没想到这一点，因为我严格尝试使用非阻塞任务。 我的观察非常类似于ForkJoinPool似乎浪费了一个线程 。 在调试了很多ForkJoinPool之后，我有一个猜测： 我使用invokeAll（）在子任务列表上分配工作。 在invokeAll（）完成后执行第一个任务本身，它开始加入其他任务。 这样可以正常工作，直到下一个要连接的任务位于执行队列之上。 不幸的是，我提交了异步的其他任务而没有加入它们。 我期望ForkJoin框架首先继续执行这些任务，然后再转回加入任何剩余的任务。 但它似乎不是这样工作的。 相反，工作线程停止调用wait（）直到等待的任务准备好（可能由其他工作线程执行）。 我没有validation这一点，但似乎是调用join（）的一般缺陷。 ForkJoinPool提供了一个asyncMode ，但这是一个全局参数，不能用于单独的提交。 但我喜欢看到我的异步分叉任务很快就会执行。 那么，为什么ForkJoinTask.doJoin（）不是简单地在其队列之上执行任何可用任务，直到它准备好（由自己执行或被其他人窃取）？