Shulou(Shulou.com)06/01 Report--

This article mainly shows you how to use parallel streams correctly and efficiently in Java8. The content is simple and easy to understand. It is clearly organized. I hope it can help you solve your doubts. Let Xiaobian lead you to study and learn how to use parallel streams correctly and efficiently in Java8.

Correct use of parallel streams to avoid shared mutable state

The primary cause of errors with parallel streams is that the algorithm used changes some shared state. Here is another way to sum the first n natural numbers, but this changes a shared accumulator:

public static long sideEffectSum(long n) { Accumulator accumulator = new Accumulator(); LongStream.rangeClosed(1, n).forEach(accumulator::add); return accumulator.total;}public class Accumulator { public long total = 0; public void add(long value) { total += value; }}

What's the problem?

It is essentially sequential. There is a data race every time total is accessed. If you fix it with synchronization, you lose all sense of parallelism.

To illustrate this point, let's try making Stream parallel:

public static long sideEffectParallelSum(long n) { Accumulator accumulator = new Accumulator(); LongStream.rangeClosed(1, n).parallel().forEach(accumulator::add); return accumulator.total;}

Under test, output

Performance doesn't matter, the only thing that matters is that each execution returns a different result, far from the correct value. This is because multiple threads are accessing the accumulator at the same time, executing total += value, which is not an atomic operation. The root cause of the problem is that methods called in forEach have the side-effect of changing the mutable state of objects shared by multiple threads.

If you want to use parallel streams without causing similar accidents, you must avoid this situation.

So sharing mutable state affects parallel flow and parallel computation. Avoid sharing mutable state and make sure parallel streams get the right results.

Efficient use of parallel streams

Is parallel flow necessary?

If in doubt, test the results multiple times. Turning sequential flows into parallel flows is easy, but not necessarily good

Watch the packing. Automatic boxing and unpacking can significantly degrade performance

Java 8 has primitive type streams (IntStream, LongStream, DoubleStream) to avoid this kind of operation, but it is not easy to use them. Probably should have used these streams.

Some operations inherently perform worse on parallel streams than on sequential streams. In particular, operations such as limit and findFirst that depend on the order of elements are expensive to perform on parallel streams.

For example, findAny performs better than findFirst because it doesn't have to be executed sequentially. You can call the unordered method to turn an ordered stream into an unordered stream. Then, if you want n elements in the stream instead of the first n specifically, calling limit on an unordered parallel stream may be more efficient than a single ordered stream (e.g., the data source is a List).

Also consider the total computational cost of the flow's operational pipeline.

Let N be the total number of elements to be processed and Q be the approximate processing cost of an element through the pipeline, then N*Q is a rough qualitative estimate of this cost. A higher Q value means that parallel streaming is more likely to perform well.

For smaller data volumes, choosing parallel streams is almost never a good decision. What are the benefits of processing a few elements in parallel? No additional overhead due to parallelization

Consider whether the data structure behind the flow is easy to decompose.

For example, ArrayList splits much more efficiently than LinkedList because the former splits evenly without traversing, whereas the latter must traverse. In addition, primitive type flows created with the range factory method can also be decomposed quickly.

The characteristics of the flow itself, as well as the way intermediate operations in the pipeline modify the flow, can change the performance of the decomposition process.

For example, a SIZED stream can be split into two equal parts, so that each part can be processed efficiently in parallel, but the number of elements that the filtering operation might discard is unpredictable, resulting in an unknown size of the stream itself.

Also consider whether the cost of combining steps in terminal operations is large or small (e.g. combiner method in Collector)

If this step is costly, the cost of combining the partial results from each substream may outweigh the performance gains from parallel streams.

Data sources and decomposability of flows

Finally, the infrastructure behind parallel flow is the branching/merging framework introduced in Java 7.

The above is "Java 8 how to use parallel flow correctly and efficiently" all the content of this article, thank you for reading! I believe that everyone has a certain understanding, hope to share the content to help everyone, if you still want to learn more knowledge, welcome to pay attention to the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.