How do I know if Java Stream collect(Collectors.toMap) is parallelized?

Question

I have the following code that attempts to populate a Map from a List in a parallel fashion by going through the Java Stream API:

class NameId {...}

public class TestStream
{
    static public void main(String[] args)
    {
        List<NameId > niList = new ArrayList<>();
        niList.add(new NameId ("Alice", "123456"));
        niList.add(new NameId ("Bob", "223456"));
        niList.add(new NameId ("Carl", "323456"));

        Stream<NameId> niStream = niList.parallelStream();
        Map<String, String> niMap = niStream.collect(Collectors.toMap(NameId::getName, NameId::getId));
    }
}

How do I know if the map is populated using multiple threads, i.e. in parallel? Do I need to call Collectors.toConcurrentMap instead of Collectors.toMap? Is this a reasonable way to parallelize the population of a map? How do I know what the concrete map is backing the new niMap (e.g. is it HashMap)?

Answer 1

From the Javadoc:

The returned Collector is not concurrent. For parallel stream pipelines, the combiner function operates by merging the keys from one map into another, which can be an expensive operation. If it is not required that results are inserted into the Map in encounter order, using toConcurrentMap(Function, Function) may offer better parallel performance.

So it sounds like toConcurrentMap will parallelize the inserts.

The backing map is, by default, a HashMap. It just calls the version of toMap which takes a Supplier<M> and passes HashMap::new. (source: the source)

Answer 2

How do I know if the map is populated using multiple threads, i.e. in parallel?

It is hard to tell. If your code is going surprisingly slowly it could be because you are trying to use multiple threads.

Do I need to call Collectors.toConcurrentMap instead of Collectors.toMap?

This would help make the parallel more efficient or put another way, a little less inefficient.

Is this a reasonable way to parallelize the population of a map?

You can do it as you suggest however you should note that the cost of starting a new thread is far more expensive than everything you are doing here so adding even one thread will slow it down a lot.

How do I know what the concrete map is backing the new niMap (e.g. is it HashMap)?

The documentation says you can't know for sure. The last time I checked toMap was using HashMap and groupingBy used LinkedHashMap but you can't assume it is any particular Map.