How to split a String into a Stream of Strings?

问题:

What is the best method of splitting a String into a Stream?

I saw these variations:

1. Arrays.stream("b,l,a".split(","))
2. Stream.of("b,l,a".split(","))
3. Pattern.compile(",").splitAsStream("b,l,a")

My priorities are:

• Robustness
• Readability
• Performance

A complete, compilable example:

import java.util.Arrays;
import java.util.regex.Pattern;
import java.util.stream.Stream;

public class HelloWorld {

    public static void main(String[] args) {
        stream1().forEach(System.out::println);
        stream2().forEach(System.out::println);
        stream3().forEach(System.out::println);
    }

    private static Stream<String> stream1() {
        return Arrays.stream("b,l,a".split(","));
    }

    private static Stream<String> stream2() {
        return Stream.of("b,l,a".split(","));
    }

    private static Stream<String> stream3() {
        return Pattern.compile(",").splitAsStream("b,l,a");
    }

}

回答1:

String.split

Well, since String.split returns an array String[], I always recommend Arrays.stream as the canonical idiom for streaming over an array.

String input = "dog,cat,bird";
Stream< String > stream = Arrays.stream( input.split( "," ) );
stream.forEach( System.out :: println );

Stream.of

Stream.of is a varargs method which just happens to accept an array, due to the fact that varargs methods are implemented via arrays and there were compatibility concerns when varargs were introduced to Java and existing methods retrofitted to accept variable arguments.

Stream< String > stream = Stream.of( input.split( "," ) ); // works, but is non-idiomatic
Stream< String > stream = Stream.of( "dog", "cat", "bird" ); // intended use case

Pattern.compile

Pattern.compile(",").splitAsStream(string) has the advantage of streaming directly rather than creating an intermediate array. So for a large number of sub-strings, this can have a performance benefit. On the other hand, if the delimiter is trivial, i.e. a single literal character, the String.split implementation will go through a fast path instead of using the regex engine. So in this case, the answer is not trivial.

If the streaming happens inside another stream, e.g. .flatMap(Pattern.compile(pattern) ::splitAsStream) there is the advantage that the pattern has to be analyzed only once, rather than for every string of the outer stream.

Stream< String > stream = Pattern.compile( "," ).splitAsStream( input );

回答2:

Regarding (1) and (2) there shouldn't be much difference, as your code is almost the same.
Regarding (3), that would be much more effective it terms of memory (not necessarily CPU), but in my opinion, a bit harder to read.

回答3:

Robustness

I can see no difference in the robustness of the three approaches.

Readability

I am not aware of any credible scientific studies on code readability involving experienced Java programmers, so readability is a matter of opinion. Even then, you never know if someone giving their opinion is making an objective distinction between actual readability, what they have been taught about readability, and their own personal taste.

So I will leave it to you to make your own judgements on readability ... noting that you do consider this to be a high priority.

FWIW, the only people whose opinions on this matter are you and your team.

Performance

I think that the answer to that is to carefully benchmark the three alternatives. Holger provides an analysis based on his study of some versions of Java. But:

1. He was not able to come to a definite conclusion on which was fastest.
2. Strictly speaking, his analysis only applies to the versions of Java he looked at. (Some aspects of his analysis could be different on (say) Android Java, or some future Oracle / OpenJDK version.)
3. The relative performance is likely depend on the length of the string being split, the number of fields, and the complexity of the separator regex.
4. In a real application, the relative performance may also depend what you do with the Stream object, what garbage collector you have selected (since the different versions apparently generate different amounts of garbage), and other issues.

So if you (or anyone else) are really concerned with the performance, you should write a micro-benchmark and run it on your production platform(s). Then do some application specific benchmarking. And you should consider looking at solutions that don't involve streams.