adding numbers one to ten can easily lead to random results when done in parallel

RNG.java

import java.util.Optional;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.function.Supplier;
import java.util.stream.Stream;

public class RNG {
    static Supplier<Integer> countGen(AtomicInteger i) {
        return (()-> i.getAndIncrement());
    }

    public static void main(String[] args) {
        final Supplier<Integer> count = countGen(new AtomicInteger(1));
        final Optional<Integer> sum = Stream.generate(count).limit(10).parallel().reduce((a, b) -> a + b);
        System.out.println("sum = " + sum);
    }
}

well, but we go parallel after the limit. So it is somewhat the laziness of the stream operations that doesn't play well with concurrency and mutable state.

Oh, the position of the parallel() call isn't important. Only the last parallel() / sequential() call is important and defines if the stream operations will be called in parallel. It defines if all intermediate operations of the Stream will be called parallel or not. In the following example the filter will be called in parallel:

Arrays.asList(1,2,3,4).stream().sequential().filter(i -> {
            System.out.println(Thread.currentThread().getName());
            return true;
        }).parallel().findFirst();

The randomness does not come from limit() but from generate() - and I very much agree: this is, just from the method name, quite unexpected. iterate(T seed, UnaryOperator f) would probably be the right choice - at least I then get always the same result (55).

With iterate() there is also no need for AtomicInteger anymore.