SecureRandom stream weird behavior with multiple threads

Question

I'm trying to generate random values using SecureRandom, specifically its support of streams. Ideally the values should be generated on a constant basis, so the stream could be infinite:

SecureRandom secureRandom = new SecureRandom();
Iterator<Integer> idIterator = secureRandom.ints().distinct().iterator();

The documentation states that "SecureRandom objects are safe for use by multiple concurrent threads." However when multiple threads retrieve the next value from the iterator, I get an error in (at least) one of the threads that appears to be due to a race condition:

Thread t1 = new Thread(() -> idIterator.next());
Thread t2 = new Thread(() -> idIterator.next());
t1.start();
t2.start();


Exception in thread "Thread-1" java.lang.IllegalStateException: source already consumed or closed
    at java.base/java.util.stream.AbstractPipeline.sourceSpliterator(AbstractPipeline.java:409)
    at java.base/java.util.stream.AbstractPipeline.lambda$spliterator$0(AbstractPipeline.java:367)
    at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.init(StreamSpliterators.java:142)
    at java.base/java.util.stream.StreamSpliterators$AbstractWrappingSpliterator.doAdvance(StreamSpliterators.java:157)
    at java.base/java.util.stream.StreamSpliterators$IntWrappingSpliterator.tryAdvance(StreamSpliterators.java:358)
    at java.base/java.util.Spliterators$2Adapter.hasNext(Spliterators.java:726)
    at java.base/java.util.Spliterators$2Adapter.nextInt(Spliterators.java:732)
    at java.base/java.util.PrimitiveIterator$OfInt.next(PrimitiveIterator.java:128)
    at java.base/java.util.PrimitiveIterator$OfInt.next(PrimitiveIterator.java:86)
    at example.Example.foo(Example.java:39)

When I run the code several times, I sometimes get another kind of exception (NullPointerException).

The behavior is the same if I limit the stream and remove the distinct() operation:

secureRandom.ints().limit(100).iterator();

EDIT:

On the other hand, if I avoid using a stream and just call SecureRandom.nextInt() from each thread, no race condition is observed as expected.

Thread t1 = new Thread(() -> secureRandom.nextInt());
Thread t2 = new Thread(() -> secureRandom.nextInt());
t1.start();
t2.start(); // code is thread-safe

I'm wondering why the iterator changes behavior? Especially that the Javadocs of the ints() method states that "a pseudorandom int value is generated as if it's the result of calling the method nextInt()".

P.S.: Of course I can solve this but synchronizing the threads acquiring the next value.

score 1 · Accepted Answer · answered Dec 02 '20 at 13:59

1

While SecureRandom itself is thread-safe, streams are not. The entire Streams API was built to be accessed by a single thread. While intermediate operations may be executed in parallel, they must be called from a single thread.

Therefore neither ints() nor its iterator are thread-safe.

So what you can do, is create one stream per thread.

Thread t1 = new Thread(() -> secureRandom.ints().distinct().iterator().next());
Thread t2 = new Thread(() -> secureRandom.ints().distinct().iterator().next());
t1.start();
t2.start();

answered Dec 02 '20 at 13:59

spongebob

8,370
15
50
83

Thanks for the answer. Would be interesting to know more about how thread-safety works with streams, specifically with `iterator()`. The proposed solution, however, is not very suitable, as the intention is to ensure distinct values (i.e. no values are repeatedly generated even if this is highly unlikely). – M A Dec 02 '20 at 14:09
@MAnouti I explained thread-safety of streams. What else would you like to know? To ensure distinct values across multiple threads you will need to implement your solution (maybe use a concurrent hash set). – spongebob Dec 02 '20 at 15:19
Here I'm interested specifically in the `iterator()` operation which seems special in that it does not evaluate the entire stream, unlike other terminal operations. The docs of the `ints()` method state "a pseudorandom int value is as if it's the result of calling the method `nextInt()`." Now if I simply use `nextInt()`, no race condition occurs. So just wondering why `iterator()` would behave differently (I've updated the question to clarify). – M A Dec 02 '20 at 15:51
I can accept the answer if there is a reference to the fact that streams are just not thread-safe in general (like an official docs or discussion). Though it would still feel like it's breaking the thread-safety guarantee of `SecureRandom`. – M A Dec 02 '20 at 15:53
1

@MAnouti I think thread-safe classes can have spun-off classes that are not thread-safe. The contract of `Iterator` does not mandate that it be thread-safe. The stream's iterator would behave differently because it is generated from a stream, and streams are not thread-safe. – spongebob Dec 02 '20 at 20:35

SecureRandom stream weird behavior with multiple threads

1 Answers1