我完全同意其他评论和答案，但实际上，如果目标很低，您的测试会表现得很奇怪。在我的普通笔记本电脑上，当给出非常低的目标时，并行版本平均要慢60倍。这种极端的差异无法用流API中的并行化开销来解释，所以我也很惊讶:-)。IMO的罪魁祸首就在这里：
Math.random()
在内部，此调用依赖于的全局实例
java.util.Random。在Random的文档中这样写：
java.util.Random的实例是线程安全的。但是，跨线程并发使用同一java.util.Random实例可能会引起争用并因此导致性能下降。考虑在多线程设计中改用ThreadLocalRandom。
因此，我认为与顺序执行相比，并行执行的真正糟糕的性能是由线程竞争以随机方式而不是其他任何开销来解释的。如果
ThreadLocalRandom改用（按照文档中的建议），则性能差异不会那么明显。另一种选择是实施更高级的号码供应商。
