Java Consumer vs Supplier: When to Use Each

When you need to pass behavior as a method argument, Java's functional interfaces give you two common choices: Consumer<T> and Supplier<T>. Understanding java consumer vs supplier comes down to whether your function consumes a value or produces one. The Consumer interface defines an operation that takes a single input and returns no result, while the Supplier interface defines an operation that takes no input and returns a result. Both are used heavily with streams, Optional, and method references.

The Core Difference Between Consumer and Supplier

The signatures tell the whole story. Consumer<T> has an abstract method void accept(T t). It receives a value and performs some action on it, typically a side effect like printing, storing, or updating state. Supplier<T> has an abstract method T get(). It takes no arguments and produces a value, acting as a factory or a source of data.

import java.util.function.Consumer;
import java.util.function.Supplier;

Consumer<String> print = s -> System.out.println(s);
Supplier<String> greeting = () -> "Hello, world!";

The print consumer accepts a string and prints it. The greeting supplier returns a string without needing input. This fundamental difference drives every other decision about when to use each interface.

Consumer in Practice: Side Effects and Callbacks

A Consumer is useful when you need to apply an operation to every element of a collection or to perform a callback after some processing. The most common usage is with Iterable.forEach() or Stream.forEach().

List<String> names = List.of("Alice", "Bob", "Charlie");
names.forEach(name -> System.out.println("Hello, " + name));

Here the lambda acts as a Consumer<String>. It consumes each name and produces no return value. Consumers are also useful for building fluent APIs where you configure an object step by step.

public void configure(Consumer<Builder> configurator) {
    Builder builder = new Builder();
    configurator.accept(builder);
    // use builder
}

This pattern lets callers specify what they want without exposing the builder's internals. The Consumer receives the builder and modifies it, but returns nothing.

Supplier in Practice: Lazy Evaluation and Factories

A Supplier is ideal for deferred execution. Instead of computing a value eagerly, you pass a supplier that computes it only when needed. A classic example is Optional.orElseGet().

Optional<String> maybeValue = Optional.empty();
String result = maybeValue.orElseGet(() -> fetchFromDatabase());

The fetchFromDatabase() method is not called until the Optional is empty. If the Optional contains a value, the supplier never runs, saving the cost of an unnecessary database query.

Suppliers also serve as factories for creating new instances. Stream.generate() takes a supplier to produce an infinite stream.

Stream<Double> randomStream = Stream.generate(Math::random);
randomStream.limit(5).forEach(System.out::println);

Math::random is a method reference that matches Supplier<Double>. The stream calls the supplier repeatedly to generate elements.

Combining Consumer and Supplier in Pipelines

In many real-world scenarios, you use both together. A stream pipeline often starts with a supplier to generate data and ends with a consumer to process it. The intermediate operations transform the data without either interface.

Supplier<Integer> counter = new Supplier<>() {
    private int value = 0;
    public Integer get() { return ++value; }
};

Consumer<Integer> printEven = n -> {
    if (n % 2 == 0) System.out.println(n);
};

Stream.generate(counter)
      .limit(10)
      .filter(n -> n % 2 == 0)
      .forEach(printEven);

Here the supplier maintains state and produces sequential integers. The consumer prints only even numbers. This separation makes each part testable and reusable.

Performance and Allocation Considerations

Lambdas that capture no external variables are typically implemented as singleton instances, so they don't allocate a new object each time they are used. However, a lambda that captures a mutable variable or a this reference may allocate a new instance per invocation. This matters when you create millions of consumers or suppliers in a hot loop.

// Captures local variable, may allocate each time
int threshold = 10;
Consumer<Integer> check = n -> { if (n > threshold) log(n); };

In contrast, a non-capturing lambda like Math::random is a constant. If you're building a high-throughput system, prefer method references or non-capturing lambdas when possible. The difference is usually negligible, but it's worth knowing that the JVM may not always inline or optimize away the allocation.

Another performance aspect is that Supplier enables lazy evaluation, which can avoid expensive computations entirely. Using Optional.orElseGet() instead of orElse() with a precomputed value is a common optimization.

Choosing Between Consumer and Supplier in Real Code

Ask yourself: does this function need an input to do its job, or does it provide an output? If you're writing a method that takes a value and returns void, use Consumer. If you're writing a method that takes no arguments and returns a value, use Supplier.

For example, a logging framework might accept a Supplier<String> to avoid building log messages that are never used:

logger.debug(() -> "Expensive message construction: " + buildDetails());

The supplier defers string concatenation until the debug level is enabled. A Consumer would not fit here because the logger needs to receive the message, not produce it.

Similarly, a retry mechanism might take a Supplier<T> to re-execute an operation, and a Consumer<Throwable> to handle errors. This separation keeps the retry logic generic and the caller responsible for both the action and the error handling.

When you see a method parameter that is a functional interface, check the signature. If the method returns a value, it likely expects a Supplier. If it returns void, it likely expects a Consumer. This simple check resolves most confusion in API design.

Method References and Edge Cases

Method references can make code more readable. A Consumer can be a reference to an instance method that returns void, like System.out::println. A Supplier can be a reference to a static method or a getter, like LocalDate::now. But be careful with overloaded methods: the compiler needs enough type information to pick the correct overload.

Supplier<String> s = String::new; // works, returns empty string
Consumer<String> c = String::intern; // works, returns void? Actually intern returns String, so this is not a Consumer

String::intern returns a String, so it cannot be a Consumer. The compiler will reject it. This is a common compile-time error when you accidentally try to use a method that returns a value as a Consumer. Always check the return type of the method reference against the functional interface's abstract method.

Another edge case is that Consumer has a default method andThen() for chaining consumers. This allows you to compose multiple operations without writing a new lambda.

Consumer<String> print = System.out::println;
Consumer<String> log = s -> logger.info(s);
Consumer<String> combined = print.andThen(log);

The combined consumer runs the first operation, then the second. Supplier has no equivalent composition method, but you can chain suppliers by writing a new lambda that calls one and then another.

When the Distinction Blurs

Sometimes a method returns a value but also has side effects, or a method takes a value but also returns something. In those cases, neither Consumer nor Supplier fits perfectly. You might need Function<T,R> or UnaryOperator<T>. The choice should reflect the primary contract: if the caller cares about the return value, use Supplier or Function; if the caller only cares about the side effect, use Consumer. Forcing a side-effect method into a Supplier is possible but misleading, and it makes the code harder to reason about.

For instance, List.add() returns a boolean, but its purpose is to modify the list. Using it as a Consumer is natural because the return value is usually ignored. Using it as a Supplier would be wrong because it requires an input. The Java standard library itself uses Consumer for Iterable.forEach even though the underlying method might return a value; the lambda simply ignores it.

In your own APIs, design parameters with the clearest intent. If a callback should perform an action, use Consumer. If a callback should provide data, use Supplier. This makes the API self-documenting and prevents misuse.