※ 引述《eieio (好多目标)》之铭言： : 佳的写法。慢五倍的关键并不是 stream，而是 boxing/unboxing : integers.stream().reduce(...) : integers.stream().mapToInt(Integer::intValue).reduce(...) : 上面两个写法，有先 mapToInt 就可以避免掉过多的 boxing/unboxing，速度 : 跟 for loop 差不多。 : 同样的道理，下面这段 code 很不好： : String r = ""; : for (String s : strs) { : r = r + s; : } : 上面这段 code，每次 r = r + s 就会产生一个新的 String，效能会很低。 : 要避免产生无用的 String，要用 StringBuilder。 http://openhome.cc/Gossip/Programmer/Parallel.html Doug Lea在〈Stream Parallel Guidance〉文件中给了一些建议，对於 S.parallelStream().operation(F)，如果N为S的元素数量，而Q为F处理每个元素的成本 ，可以大略使用F中的操作或行数来计算，如果N*Q至少超过10000，才有平行化的价值。 因此，如果操作简单如x -> x + 1，那麽至少得有10000个以上的元素，才有平行化的价 值，相对地，如果每个元素涉及大量运算，那麽就越有平行化的价值。 在Java上得考量一种处理成本：基本资料型态与对应的包裹器型态间的转换。例如，int 与Integer之间的Boxing与Unboxing操作。如果实际上List中都是数值且进行数学运算， 考虑使用mapToInt转为专属於int的IntStream，而後再进行数学运算，可免去不必要的 Boxing与Unboxing成本。目前就JDK8的Stream程式库来说，也不建议对I/O做平行处理。 在想要免於I/O、同步处理等待之类情况下，其他并行、非同步I/O程式库或 CompletableFuture会是比较好的选择。 资料来源的结构也是一个考量，先前谈过，可思考将有序打为无序後，是否对平行处理有 益，另一方面，因为平行处理必须分而治之，在这之前采取易於划分的资料结构作为来源 ，对平行处理会有帮助，例如支援随机存取的阵列、ArrayList或具有一定范围的 IntStream.range，平行处理时会比较有效率；而HashSet、TreeSet等，因为涉及杂凑空 间与树平衡等考量，会是其次之选；然而，像是LinkedList这类链结资料，走访划分资料 的成本是O(N)，就不适合作为平行处理的来源结构，长度无法确定的资料来源，像是 Streams.iterate、BufferedReader.lines等，也不建议采用。 -- 良葛格学习笔记 http://openhome.cc --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 39.12.211.127 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/java/M.1449133393.A.7FB.html