collect() is the terminal operation that gathers every element of a stream into a single mutable result — a List, a Set, a Map, a joined String, or a custom container — using a Collector that knows how to create that result, add elements into it, and, for a parallel stream, merge partial results back together. Where reduce() is built around producing a fresh, immutable value at every combining step, collect() is built around mutating one shared container as elements flow through it, which is exactly what makes it the right tool for accumulating into structures like List and Map efficiently.

What Is collect()?

collect() has two overloaded forms. The low-level one, <R> R collect(Supplier<R> supplier, BiConsumer<R, ? super T> accumulator, BiConsumer<R, R> combiner), takes three separate pieces directly: a Supplier that creates a new empty container, a BiConsumer that adds one element into it, and a second BiConsumer that merges two containers together when the stream runs in parallel. The high-level form, <R, A> R collect(Collector<? super T, A, R> collector), takes a single pre-built Collector object that already packages up all three of those pieces — this is the form almost every real codebase actually uses, through the java.util.stream.Collectors factory class and methods like toList(), toSet(), toMap(), and joining().

Why collect() Was Introduced

Building a new collection out of a stream's elements used to mean a loop, a manually created container, and an explicit add() call for every element.

Java

Try it out

// File: BeforeCollect.java
import java.util.*;

public class BeforeCollect {
    record Product(String sku, String name) {}

    public static void main(String[] args) {
        List<Product> catalog = List.of(
            new Product("SKU-1", "Mouse"),
            new Product("SKU-2", "Keyboard"),
            new Product("SKU-3", "Monitor")
        );

        List<String> names = new ArrayList<>();
        for (Product product : catalog) {
            names.add(product.name());
        }

        System.out.println(names);
    }
}

Output:
[Mouse, Keyboard, Monitor]

collect() keeps the same result but removes the container creation and the explicit add() call entirely — Collectors.toList() already knows how to do both.

Java

Try it out

// File: AfterCollect.java
import java.util.*;
import java.util.stream.*;

public class AfterCollect {
    record Product(String sku, String name) {}

    public static void main(String[] args) {
        List<Product> catalog = List.of(
            new Product("SKU-1", "Mouse"),
            new Product("SKU-2", "Keyboard"),
            new Product("SKU-3", "Monitor")
        );

        List<String> names = catalog.stream()
            .map(Product::name)
            .collect(Collectors.toList());

        System.out.println(names);
    }
}

Output:
[Mouse, Keyboard, Monitor]

Both versions build the same three-element list. The stream version has no ArrayList variable being created and populated by hand.

Syntax

The three-argument form is rarely written directly in real code — almost everything reaches for a Collector from the Collectors factory class instead.

Java

Try it out

// File: CollectSyntaxForms.java
import java.util.*;
import java.util.stream.*;

public class CollectSyntaxForms {
    public static void main(String[] args) {
        List<String> names = List.of("Mouse", "Keyboard", "Mouse", "Monitor");

        // Low-level three-argument form - rarely written by hand in real code
        ArrayList<String> viaThreeArg = names.stream()
            .collect(ArrayList::new, ArrayList::add, ArrayList::addAll);

        // The common, high-level form using a pre-built Collector
        List<String> viaCollectorsToList = names.stream()
            .collect(Collectors.toList());

        Set<String> viaCollectorsToSet = names.stream()
            .collect(Collectors.toSet());

        String viaJoining = names.stream()
            .collect(Collectors.joining(", "));

        System.out.println("Three-arg form: " + viaThreeArg);
        System.out.println("toList(): " + viaCollectorsToList);
        System.out.println("toSet() size: " + viaCollectorsToSet.size());
        System.out.println("joining(): " + viaJoining);
    }
}

Output:
Three-arg form: [Mouse, Keyboard, Mouse, Monitor]
toList(): [Mouse, Keyboard, Mouse, Monitor]
toSet() size: 3
joining(): Mouse, Keyboard, Mouse, Monitor

Common Use Cases

Choosing Between toList, toSet, and toUnmodifiableList

toSet() removes duplicates as a side effect of the container it builds, and toUnmodifiableList() states its immutability guarantee directly in its name rather than leaving it implicit.

Java

Try it out

// File: CollectorVarietyExample.java
import java.util.*;
import java.util.stream.*;

public class CollectorVarietyExample {
    public static void main(String[] args) {
        List<String> categories = List.of("Electronics", "Books", "Electronics", "Home");

        List<String> asList = categories.stream().collect(Collectors.toList());
        List<String> asUnmodifiableList = categories.stream().collect(Collectors.toUnmodifiableList());
        long distinctCount = categories.stream().collect(Collectors.toSet()).size();

        System.out.println("As list: " + asList);
        System.out.println("Distinct count: " + distinctCount);

        try {
            asUnmodifiableList.add("Toys");
        } catch (UnsupportedOperationException e) {
            System.out.println("toUnmodifiableList() rejects add() as expected");
        }
    }
}

Output:
As list: [Electronics, Books, Electronics, Home]
Distinct count: 3
toUnmodifiableList() rejects add() as expected

Joining Elements Into a Formatted String

Collectors.joining() accepts a delimiter along with an optional prefix and suffix, which is exactly what a CSV-style export or a formatted display string needs.

Java

Try it out

// File: JoiningWithDelimitersExample.java
import java.util.*;
import java.util.stream.*;

public class JoiningWithDelimitersExample {
    public static void main(String[] args) {
        List<String> skus = List.of("SKU-1", "SKU-2", "SKU-3");

        String csvRow = skus.stream()
            .collect(Collectors.joining(",", "[", "]"));

        System.out.println(csvRow);
    }
}

Output:
[SKU-1,SKU-2,SKU-3]

Building a Lookup Map

Collectors.toMap() takes a key extractor and a value extractor, turning a List into a Map for fast lookups instead of repeated linear scans.

Java

Try it out

// File: ToMapLookupExample.java
import java.util.*;
import java.util.stream.*;

public class ToMapLookupExample {
    record Product(String sku, String name) {}

    public static void main(String[] args) {
        List<Product> catalog = List.of(
            new Product("SKU-1", "Mouse"),
            new Product("SKU-2", "Keyboard"),
            new Product("SKU-3", "Monitor")
        );

        Map<String, Product> bySku = catalog.stream()
            .collect(Collectors.toMap(Product::sku, product -> product));

        System.out.println(bySku.get("SKU-2").name());
    }
}

Output:
Keyboard

Summarizing With a Built-In Numeric Collector

Collectors.averagingDouble() and its relatives compute a single numeric summary directly, without a separate mapToDouble() step.

Java

Try it out

// File: SummarizingCollectorExample.java
import java.util.*;
import java.util.stream.*;

public class SummarizingCollectorExample {
    record Order(String id, double amount) {}

    public static void main(String[] args) {
        List<Order> orders = List.of(
            new Order("ORD-1", 450.0),
            new Order("ORD-2", 899.0),
            new Order("ORD-3", 250.0)
        );

        double averageOrderValue = orders.stream()
            .collect(Collectors.averagingDouble(Order::amount));

        System.out.println("Average order value: " + averageOrderValue);
    }
}

Output:
Average order value: 533.0

Real-World Example

A warehouse system frequently needs to find a product by scanning its SKU barcode, and searching through the full catalog with filter and findFirst every single time a scan happens wastes work the moment the catalog grows past a handful of items. Building a Map<String, Product> once, up front, with collect(Collectors.toMap(...)), turns every later lookup into a direct, constant-time read instead of a fresh scan through the entire list.

Java

Try it out

// File: Product.java

public record Product(String sku, String name, double price) {}

Java

Try it out

// File: ProductCatalogIndex.java
import java.util.*;
import java.util.stream.*;

public class ProductCatalogIndex {
    private final Map<String, Product> bySku;

    public ProductCatalogIndex(List<Product> catalog) {
        this.bySku = catalog.stream()
            .collect(Collectors.toMap(Product::sku, product -> product));
    }

    public Optional<Product> findBySku(String sku) {
        return Optional.ofNullable(bySku.get(sku));
    }

    public String listAllSkus() {
        return bySku.keySet().stream()
            .sorted()
            .collect(Collectors.joining(", "));
    }

    public int size() {
        return bySku.size();
    }
}

Java

Try it out

// File: ProductCatalogIndexDemo.java
import java.util.*;

public class ProductCatalogIndexDemo {
    public static void main(String[] args) {
        List<Product> catalog = List.of(
            new Product("SKU-1", "Wireless Mouse", 799.0),
            new Product("SKU-2", "Mechanical Keyboard", 2499.0),
            new Product("SKU-3", "27-inch Monitor", 8999.0)
        );

        ProductCatalogIndex index = new ProductCatalogIndex(catalog);

        System.out.println("Catalog size: " + index.size());
        System.out.println("All SKUs: " + index.listAllSkus());

        index.findBySku("SKU-2").ifPresentOrElse(
            product -> System.out.println("Found: " + product.name() + " at Rs." + product.price()),
            () -> System.out.println("Not found")
        );

        index.findBySku("SKU-9").ifPresentOrElse(
            product -> System.out.println("Found: " + product.name()),
            () -> System.out.println("SKU-9 not found in catalog")
        );
    }
}

Output:
Catalog size: 3
All SKUs: SKU-1, SKU-2, SKU-3
Found: Mechanical Keyboard at Rs.2499.0
SKU-9 not found in catalog

A mistake that appears often in fresher pull requests is calling catalog.stream().filter(p -> p.sku().equals(sku)).findFirst() every single time a lookup is needed, scanning the entire catalog from scratch on every scan. Building the Map once with collect(Collectors.toMap(...)) when ProductCatalogIndex is constructed turns every later findBySku call into a constant-time lookup instead of a linear scan repeated over and over.

Combining collect() With Other Features

collect() is almost always where a filter() and map() chain ends, turning a narrowed and transformed stream into a concrete List, Set, or Map. The Collectors factory class provides most of what real code needs — toList, toSet, toMap, joining, counting, averagingDouble, and the grouping and partitioning collectors covered in their own dedicated article. collect() and reduce() solve overlapping problems, but collect() is specifically optimized for accumulating into a mutable container, while reduce() is built around producing a fresh, immutable result at every combining step — a distinction the JDK's own documentation calls out directly.

Best Practices

Reach for a Collectors factory method instead of the low-level three-argument form. Almost no real code needs to hand-write its own supplier, accumulator, and combiner when Collectors.toList(), toMap(), and joining() already cover the vast majority of cases.

When using toMap(), think through what should happen if two elements produce the same key before writing the call. The two-argument form throws IllegalStateException on a duplicate key, and a three-argument merge function is required the moment duplicate keys are actually possible in the data.

Prefer toUnmodifiableList() or toUnmodifiableSet() over toList() or toSet() whenever the collected result should never be mutated by whatever receives it, since that guarantee then lives directly in the type rather than being an assumption a caller has to trust.

Build a lookup structure like a Map once, up front, with collect(Collectors.toMap(...)), rather than repeatedly filtering or searching the same source for every individual lookup.

Common Mistakes

Using Collectors.toMap() without considering duplicate keys throws IllegalStateException the moment two elements produce the same key, and the fix is a three-argument merge function that decides explicitly what should happen.

Java

Try it out

// File: ToMapDuplicateKeyMistake.java
import java.util.*;
import java.util.stream.*;

public class ToMapDuplicateKeyMistake {
    record Product(String sku, String name) {}

    public static void main(String[] args) {
        List<Product> catalog = List.of(
            new Product("SKU-1", "Mouse"),
            new Product("SKU-1", "Mouse (Refurbished)")
        );

        try {
            Map<String, Product> broken = catalog.stream()
                .collect(Collectors.toMap(Product::sku, product -> product));
            System.out.println("Never printed: " + broken);
        } catch (IllegalStateException e) {
            System.out.println("IllegalStateException - duplicate key SKU-1 with no merge function supplied");
        }

        // Supplying a merge function resolves the conflict explicitly
        Map<String, Product> resolved = catalog.stream()
            .collect(Collectors.toMap(Product::sku, product -> product, (existing, replacement) -> existing));

        System.out.println("Resolved: " + resolved.get("SKU-1").name());
    }
}

Output:
IllegalStateException - duplicate key SKU-1 with no merge function supplied
Resolved: Mouse

Assuming Collectors.toList() guarantees a specific, mutable List implementation is relying on behavior the API never actually promises. The JDK documentation is explicit that no guarantee exists about the returned list's type, mutability, or thread-safety, even though current versions happen to return a plain mutable ArrayList.

Java

Try it out

// File: ToListMutabilityAssumptionMistake.java
import java.util.*;
import java.util.stream.*;

public class ToListMutabilityAssumptionMistake {
    public static void main(String[] args) {
        List<String> names = Stream.of("Ananya", "Rohit")
            .collect(Collectors.toList());

        // This happens to work on current JDK versions, but Collectors.toList()
        // makes no documented guarantee about mutability, type, or thread-safety -
        // code relying on it staying mutable is relying on unspecified behavior
        names.add("Priya");
        System.out.println(names);

        // Collectors.toUnmodifiableList() states its contract explicitly instead
        List<String> guaranteedImmutable = Stream.of("Ananya", "Rohit")
            .collect(Collectors.toUnmodifiableList());

        try {
            guaranteedImmutable.add("Priya");
        } catch (UnsupportedOperationException e) {
            System.out.println("toUnmodifiableList() explicitly guarantees this fails");
        }
    }
}

Output:
[Ananya, Rohit, Priya]
toUnmodifiableList() explicitly guarantees this fails

Expecting Collectors.groupingBy() to preserve any particular order in its resulting Map is another common assumption that quietly breaks. Its default implementation returns a plain HashMap, which offers no ordering guarantee at all — code that needs a predictable order back from a grouped result has to request it explicitly, typically by supplying a TreeMap::new or LinkedHashMap::new supplier to the grouping collector.

Interview Questions

Q1. What does collect() do, and what are its two overloaded forms?

collect() is a terminal operation that gathers a stream's elements into a mutable result. Its low-level form takes a Supplier, a BiConsumer accumulator, and a BiConsumer combiner directly. Its high-level form takes a single Collector object that already packages all three, and this is the form used in the vast majority of real code through the Collectors factory class. Interviewers frequently ask for both forms specifically to see whether a candidate has ever looked past Collectors.toList() into what collect() is actually built on.

Q2. What is a Collector, and how does it relate to the three-argument collect() overload?

A Collector<T, A, R> is an object that bundles together the supplier, accumulator, and combiner the low-level collect() overload takes as three separate arguments, plus an optional finisher step for a final transformation. Collectors.toList(), Collectors.toMap(), and every other factory method on Collectors simply construct and return a pre-built Collector matching that shape, which is what makes collect(Collectors.toList()) equivalent to writing all three pieces out by hand.

Q3. What is the difference between collect() and reduce()?

reduce() is designed around producing a new, independent result at each combining step, which works well for immutable values like numbers and strings but performs poorly for building a mutable container, since every step would need to copy the entire container so far. collect() is designed specifically for mutable accumulation — the same container is created once and then mutated in place as elements flow through, which is far more efficient for building a List, Set, or Map.

Q4. What happens if Collectors.toMap() encounters two elements that produce the same key?

The two-argument form of toMap() throws IllegalStateException the moment a duplicate key is encountered, since it has no way to decide which of the two conflicting values should win. The three-argument form accepts an explicit merge function — a BinaryOperator<V> — that resolves the conflict deliberately, whether that means keeping the first value, the last one, or combining them somehow.

Q5. Does Collectors.toList() guarantee the returned list is mutable?

No, and this is a common misconception. The documented contract of Collectors.toList() makes no guarantee about the returned list's type, mutability, or thread-safety — current JDK versions happen to return a mutable ArrayList, but code that depends on that specifically should use Collectors.toCollection(ArrayList::new) instead, which states the intended container type explicitly rather than relying on unspecified behavior.

Q6. How does Collectors.joining() differ from manually concatenating strings in a loop?

Collectors.joining() handles delimiters, an optional prefix, and an optional suffix correctly without any special-casing for the first or last element, and internally it uses a StringBuilder-based accumulation rather than repeated string concatenation, which avoids the quadratic performance cost of concatenating strings with + inside a loop. Manually joining strings in a loop usually needs extra logic just to avoid a trailing delimiter after the last element, logic joining() already handles.

FAQs

Is collect() a terminal or intermediate operation?

Terminal. collect() consumes the entire stream and produces a final result — a List, Map, String, or whatever the supplied Collector builds — and nothing can be chained after it.

What is the difference between Collectors.toList() and Collectors.toUnmodifiableList()?

toList() makes no documented guarantee about the mutability of the list it returns, while toUnmodifiableList() explicitly guarantees an immutable list that throws UnsupportedOperationException on any attempt to modify it. Use toUnmodifiableList() whenever the collected result genuinely should never change after it is built.

Can collect() be used to build a custom object instead of a List or Map?

Yes. Collectors.toCollection() accepts any collection type as its target, and a fully custom Collector can be written to accumulate into any object at all, using Collector.of() to define its own supplier, accumulator, combiner, and finisher.

Does collect() work differently on a parallel stream?

The final result is the same as long as the Collector is properly associative and thread-safe in how it combines partial results, but the mechanics differ — a parallel stream builds several partial containers independently across threads and then merges them using the collector's combiner, rather than accumulating into a single container from start to finish.

What is the difference between Collectors.toMap() and Collectors.groupingBy()?

toMap() produces exactly one value per key, throwing or requiring a merge function on any duplicate. groupingBy() produces a Map where each key maps to a collection of every matching element, making it the correct choice whenever multiple elements can legitimately share the same key — it is covered in depth in its own dedicated article.

Can I collect a stream directly into an array instead of a List?

Not through collect() — arrays use a separate method, toArray(), which is not part of the Collector framework at all. collect(Collectors.toList()) followed by .toArray() is one way to get there, but stream.toArray(String[]::new) is the more direct route for a typed array.

Is Collectors.joining() the same as String.join()?

They produce similar results but operate on different inputs. String.join() takes a delimiter and a CharSequence... elements varargs array or an Iterable<CharSequence> directly. Collectors.joining() is a Collector meant specifically for use inside a stream's collect() call, working on whatever String elements the stream happens to be producing at that point in the pipeline.

Summary

collect() is how a stream turns into something concrete — a List, a Set, a Map, a formatted String — and nearly all of that work happens through a pre-built Collector from the Collectors factory class rather than the low-level three-argument form. toList(), toSet(), toMap(), and joining() cover most everyday needs, and the product catalog index example above shows exactly why toMap() earns its place: turning a repeated linear search into a single upfront build followed by constant-time lookups.

The two habits worth carrying forward are thinking through duplicate keys before calling toMap(), and reaching for toUnmodifiableList() the moment a collected result is meant to stay fixed. reduce() remains the right tool for building an immutable value one combining step at a time — collect() takes over the moment the goal shifts to building something mutable that gets filled in as the stream runs.

What to Read Next

Continue Learning Streams

Next Step

sorted()

Learn how to sort the elements in a Stream.

→

Collectors & groupingBy()

Learn how to group and summarize Stream results.

→

ListIterator

Learn how to loop through a List in both directions.

→

Streams Overview

Learn how to process collections in a clean, functional style.