Collect employees into a LinkedHashMap preserving insertion order using Collectors.toMap with a map supplier

The four-argument Collectors.toMap controls the concrete Map implementation.

• Key mapper – extracts the key, here Employee::getId.
• Value mapper – extracts the value, here Employee::getName.
• Merge function – a BinaryOperator required by this overload; it resolves duplicate keys.
• Map supplier – a factory such as LinkedHashMap::new that decides which Map type holds the result.

The default two-argument form uses a HashMap, so iteration order is unspecified. Supplying LinkedHashMap::new keeps entries in the order they were inserted.

Why does the default toMap lose order?

The two-argument and three-argument toMap overloads create a HashMap. A HashMap places entries in buckets based on their hash codes, so the iteration order has no relationship to the order elements entered the stream. Running the same code twice can even produce different orders across Java versions.

package com.bank.hr;

import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

public class UnorderedMapDemo {
    public static void main(String[] args) {
        List<Employee> employees = List.of(
            new Employee(30L, "Rajesh"),
            new Employee(10L, "Priya"),
            new Employee(20L, "Pankaj"));
        Map<Long, String> map = employees.stream()
            .collect(Collectors.toMap(Employee::getId, Employee::getName));
        System.out.println(map); // order is not guaranteed
    }
}

{20=Pankaj, 10=Priya, 30=Rajesh}

How do you preserve insertion order?

Use the four-argument overload and pass LinkedHashMap::new as the map supplier. This overload also requires a merge function, so provide one even when you do not expect duplicate keys.

package com.bank.hr;

import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

public class OrderedMapDemo {
    public static Map<Long, String> idToName(List<Employee> employees) {
        return employees.stream()
            .collect(Collectors.toMap(
                Employee::getId,
                Employee::getName,
                (existing, replacement) -> existing, // required merge
                LinkedHashMap::new));                // the map supplier
    }
}

{30=Rajesh, 10=Priya, 20=Pankaj}

The keys now appear in the exact order the employees sat in the original list.

How does LinkedHashMap keep order internally?

A LinkedHashMap extends HashMap but adds a doubly linked list threading through all entries. Lookups still use the hash buckets for speed, while the linked list records insertion order for iteration.

  Hash buckets (for fast get/put)      Linked list (for ordered iteration)
  bucket[3] -> (10, Priya)             head -> (30,Rajesh) -> (10,Priya) -> (20,Pankaj) -> tail
  bucket[5] -> (20, Pankaj)
  bucket[7] -> (30, Rajesh)

Because the list is maintained as entries are inserted, iteration follows insertion order while get remains constant time.

How do the toMap overloads compare?

| Overload | Merge function | Map supplier | Resulting map | Iteration order |
|----------|----------------|--------------|---------------|-----------------|
| toMap(k, v) | not allowed | not allowed | HashMap | unspecified |
| toMap(k, v, merge) | required | not allowed | HashMap | unspecified |
| toMap(k, v, merge, supplier) | required | required | whatever you supply | depends on supplier |

// Same data, three different ordering outcomes
map1 = stream.collect(Collectors.toMap(Employee::getId, Employee::getName));                 // HashMap
map2 = stream.collect(Collectors.toMap(Employee::getId, Employee::getName, (a,b)->a, LinkedHashMap::new)); // insertion order
map3 = stream.collect(Collectors.toMap(Employee::getId, Employee::getName, (a,b)->a, java.util.TreeMap::new)); // sorted keys

How is insertion order different from sorted order?

Insertion order follows the sequence elements arrived. Sorted order follows the natural ordering of the keys. They are only the same when the input happened to already be sorted.

// Insertion order: 30, 10, 20 as they appeared
Map<Long, String> inserted = employees.stream()
    .collect(Collectors.toMap(Employee::getId, Employee::getName, (a,b)->a, LinkedHashMap::new));

// Sorted by id: 10, 20, 30
Map<Long, String> sorted = employees.stream()
    .collect(Collectors.toMap(Employee::getId, Employee::getName, (a,b)->a, java.util.TreeMap::new));

inserted = {30=Rajesh, 10=Priya, 20=Pankaj}
sorted   = {10=Priya, 20=Pankaj, 30=Rajesh}

What are the common mistakes?

The first mistake is expecting the two-argument toMap to keep order and being surprised when it does not.

// WRONG: assumes HashMap preserves insertion order
Map<Long, String> map = employees.stream()
    .collect(Collectors.toMap(Employee::getId, Employee::getName));

// CORRECT: ask for a LinkedHashMap explicitly
Map<Long, String> map = employees.stream()
    .collect(Collectors.toMap(Employee::getId, Employee::getName,
             (a, b) -> a, LinkedHashMap::new));

The second mistake is forgetting that the four-argument overload makes the merge function mandatory, which causes a compile error if you try to skip it.

// WRONG: does not compile, missing the merge function
.collect(Collectors.toMap(Employee::getId, Employee::getName, LinkedHashMap::new));

// CORRECT: merge function comes before the supplier
.collect(Collectors.toMap(Employee::getId, Employee::getName, (a, b) -> a, LinkedHashMap::new));

What are the edge cases with duplicate keys in an ordered map?

When two employees share an id, the merge function decides the value, but the position in the LinkedHashMap stays where the key was first inserted. A later merge updates the value in place, not the order.

package com.bank.hr;

import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;

public class OrderWithDuplicates {
    public static void main(String[] args) {
        List<Employee> employees = List.of(
            new Employee(30L, "Rajesh"),
            new Employee(10L, "Priya"),
            new Employee(30L, "Rajesh Kumar")); // duplicate id 30, keep last
        Map<Long, String> map = employees.stream()
            .collect(Collectors.toMap(Employee::getId, Employee::getName,
                     (a, b) -> b, LinkedHashMap::new));
        System.out.println(map);
    }
}

{30=Rajesh Kumar, 10=Priya}

Notice id 30 keeps its original first position even though its value was replaced.

When should you use a map supplier, and which one?

Choose the supplier based on the iteration contract you need. Use LinkedHashMap::new to echo the source order, TreeMap::new to sort keys, and leave the default HashMap when order is irrelevant and you want the fastest option.

// Statement that lists accounts in the order they were opened
Map<Long, String> ledger = openings.stream()
    .collect(Collectors.toMap(Account::getId, Account::getHolder,
             (a, b) -> a, LinkedHashMap::new));

What should a senior engineer know?

• Parallel streams and order. LinkedHashMap records the order entries are merged, which in a parallel stream is the encounter order of the source if the stream is ordered. For predictable order prefer an ordered source like a List.
• Access-order mode. LinkedHashMap also has an access-order constructor used to build LRU caches, but toMap always uses the default insertion-order mode.
• Immutability. Wrap with collectingAndThen(toMap(...), Collections::unmodifiableMap) to return a read-only ordered view.
• Memory cost. LinkedHashMap carries two extra references per entry for the linked list, a small cost paid for predictable iteration.

What are common interview follow-up questions?

• "Does toMap guarantee order by default?" Answer: no, the default is a HashMap.
• "Which overload lets you choose the map type?" Answer: the four-argument toMap(key, value, merge, supplier).
• "Why must you pass a merge function when you only want ordering?" Answer: the supplier overload always requires all four arguments, so you give a trivial merge like (a, b) -> a.
• "Insertion order versus sorted order?" Answer: LinkedHashMap keeps arrival order; TreeMap keeps keys sorted by natural ordering.