使用parallelStream进行遍历的坑,以及如何进行避免异步操作中出现的问题

灰太狼 2022-12-25 05:00 264阅读 0赞

Java8 已经很久了,现在都已经Java12版本了.

我所在的上家公司,在写代码时候推荐使用lambad来进行操作遍历集合

也就是像下面一样

1.  `List<Integer> list = new ArrayList<>();`
2.  `for (int j = 0; j < 1000; j++) {`
3.  `list.add(j);`
4.  `}`
5.  `list.stream().forEach(value -> {`
6.  `System.out.println(value);`
7.  `});`

这种效率其实和传统上的使用foreach以及for循环遍历效果差不多,因为点开forEach方法会发现内部其实使用的是下面的方法进行对集合遍历的

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70][]

内部其实使用的还是for进行遍历,所以两者相比较其实没有什么效率的差异的,当然这也会由于每个公司编程习惯不一样,有的人更喜欢传统上的for进行遍历

因为上面的遍历方式不会对效率有什么提升, 所以由此还有一种方式就是

parallelStream()

1.  `List<Integer> list = new ArrayList<>();`
2.  `for (int j = 0; j < 1000; j++) {`
3.  `list.add(j);`
4.  `}`
5.  `list.parallelStream().forEach(value -> {`
6.  `System.out.println(value);`
7.  `});`

上面的方法其实就是异步的,

这种遍历方式因为是异步遍历,会产生一种情况,就是遍历的顺序是无序的,当然也有相应的好处就是,遍历速度会快,当对生成结果不考虑排序问题而且数据量比较大的时候可以使用.

但是,有利自然有弊,因为异步的所以需要考虑线程的问题,就是生成的结果真的是你想要的么?

以下面的例子来运行一段代码:

1.  `public static void main(String[] args) {`
2.  `List<Integer> list = new ArrayList<>();`
3.  `for (int j = 0; j < 1000; j++) {`
4.  `list.add(j);`
5.  `}`
6.  `System.out.println("最开始生成的集合长度:"+list.size());`
7.  `//parallelStream遍历数据的时候会产生丢失的问题`
8.  `for (int i = 0; i < 10 ; i++) {`
9.   
10. `List<Integer> parseList = new ArrayList<>();`
11. `list.parallelStream().forEach(integer -> {`
12. `parseList.add(integer);`
13. `});`
14. `System.out.println("每次遍历的集合长度:"+ parseList.size());`
15. `}`
16. `}`

我首先创建了一个1000长度的集合,之后对这个集合使用多次遍历,然而呢,会发现,最后遍历的集合少数据,并且会在多次重复遍历的时候数组越界..

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 1][]

因为这种情况,之前工作使用parallelStream出现过2次问题, 我一直以为是使用parallelStream本身不够很安全导致的.实际上今天整理这篇博文突然才发现这个问题,就是遍历的结果转为的list是线程安全的么?

其实当正常进行遍历的时候, 可以对遍历出的结果核对,实际上每次遍历出的结果,仍然是与原来生成的结果一致的.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 2][]

所以这边只能将锅甩在接收这些数据的list上面了

这个时候就需要对list进行包装

List<Integer> synchronizedList = Collections.synchronizedList(parseList);

这会在看下修改后的代码以及结果

1.  `public static void main(String[] args) {`
2.  `List<Integer> list = new ArrayList<>();`
3.  `for (int j = 0; j < 1000; j++) {`
4.  `list.add(j);`
5.  `}`
6.  `System.out.println("最开始生成的集合长度:"+list.size());`
7.  `//parallelStream遍历数据的时候会产生丢失的问题`
8.  `for (int i = 0; i < 10 ; i++) {`
9.   
10. `List<Integer> parseList = new ArrayList<>();`
11. `List<Integer> synchronizedList = Collections.synchronizedList(parseList);`
12. `list.parallelStream().forEach(integer -> {`
13. `synchronizedList.add(integer);`
14. `});`
15. `System.out.println("每次遍历的集合长度:"+ synchronizedList.size());`
16. `}`
17. `}`

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 3][]

这样每次遍历的结果也都是一样的,而且速度也会由于异步的会比之前效率提升好多

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 4][]

同样的如何创建线程安全的set,map也就可以进行相应的包装,这样就避免了使用会出新一些明明感觉对,确和自己想要的结果不一致的bug

同理使用parallelStream用StringBuffer 而不适用StringBuilder,因为前者是线程安全的

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70]: /images/20221120/94b9499af11a4a1a9d0b51dac574500c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 1]: /images/20221120/94744b7a244049e196aa3947216dcec8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 2]: /images/20221120/b7629d8b623b4ee4ba749f12174f7d8a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 3]: /images/20221120/565c3c5ada694dd5b57bcfee55bb5669.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20190906152721274.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxODQwMDIz,size_16,color_FFFFFF,t_70