Java 8并行操作的性能分析

一心多用是我的拿手好戏。当我在写这篇博客的时候，我还在为昨天聚会上说过的话感到尴尬，当时大家看我跟看怪物一样。好吧，不过所幸的是我并不孤单——Java 8它也很擅长这口。来看下它是怎么回事。

Java 8中一个关键的新特性就是它支持并行数组操作。你可以使用lambda表达式来进行排序，过滤，分组等操作，它能自动的发挥多核架构的优势。带来的好处就是作为一名Java开发人员，你只需很小的工作量就可以立马获得性能的提升。相当酷的功能。

那么问题来了——它到底能有多快，我该在什么时候使用它？答案可能会让人有些失望——这得具体情况具体分析。想知道决定因素是什么吗？继续往下看就知道了。

新的API

Java 8的新的并行操作的API非常巧妙。我们来看下准备进行测试的几个接口：

1. 通过这个接口可以发挥多处理器的优势进行并行的数组排序：

   Arrays.parallelSort(numbers);

1. 根据指定的条件（比如是不是素数）对集合进行分组——

   Map<Boolean, List<Integer>> groupByPrimary = numbers
    .parallelStream().collect(Collectors.groupingBy(s -> Utility.isPrime(s)));

1. 过滤出你想要的值：

   Integer[]  prims = numbers.parallelStream().filter(s -> Utility.isPrime(s))
    .toArray();

看看这个，再想想如果你自己用多线程来实现的话。开发效率瞬间提高了有木有！这个新结构我个人比较喜欢的人一点是它的分割迭代器（Spliterator）的概念，它将一个目标集合分隔成不同的块，这些块可以并行的进行处理，然后再合并到一起。跟它的前辈迭代器那样，它可以遍历一个集合，同时这个架构非常灵活，你可以自定义遍历以及分隔集合的操作，并直接传入方法即可。

它的性能表现如何？

我通过两个场景来进行并行操作的性能测试——低竞争以及高竞争的情况。原因在于如果你直接运行某个多核运算的算法的话，结果通常都会非常不错。但如果在一个真实的环境中运行的话，问题就出现了。真实环境下有大量的线程在不停的争夺宝贵的CPU资源进行消息或者用户请求的处理。这就是性能变差的原因。为了测试这种情况我进行了如下的测试。随机生成长度为10万的整型数组，取值在0到100万之间。然后分别使用传统的方式和并行的方式进行排序，分组以及过滤操作。结果在我们的预料之中。

1. 快排的性能快了4.7倍。
2. 分组的性能快了5倍左右。
3. 过滤的性能快了5.5.倍。

结果还算满意？当然不是。

我后来又做了一个额外的测试，将上述程序重复执行了100次，结果也是一样的。测试的机器是 i7处理器的MacBook Pro。

高负载下的情况如何？

目前为止结果还算不错，这是由于CPU资源的竞争并不激烈。这是理想情况下的结果，不过不幸的是，现实环境中可没有这么理想。为了模拟现实环境中的场景我写了第二个测试用例。这个测试运行的是同样的程序，不同的是这次有10个线程在并发的执行，来模拟并行处理10个请求的情况 。每个请求都通过传统的串行方式以及新的并行的方式来进行处理。

结果

• 排序快了20% —— 性能降低了23倍
• 过滤快了20% ——性能降低了25倍
• 分组慢了15%。

竞争冲突更严重的情况下性能差距肯定还会继续加大。原因在于，在多线程环境下，增加线程来进行处理其实是于事无补的。只有当CPU越多的情况下性能才会越好——线程多则无剂于事。

结论

尽管这些接口非常强大并且易于使用，但它们可不是什么万能钥匙。我们还得看具体情况来决定是否使用它们。如果你事先知道要并行的处理多个请求的话，最好考虑使用一个队列来保证并行处理的线程和你实际的CPU数一致。难点在于运行时的性能实际取决于硬件的体系结构以及压力程度的大小。你的程序可能只见识过压测的环境就直接上线运行了，这很容易出现写起来容易，调试起来费劲的问题。

原创文章转载请注明出处： Java 8并行操作的性能分析

英文原文链接