Consumer<T> is the functional interface for an operation that takes a value and does something with it, without producing a result to hand back. It declares one abstract method, accept(T value), and it exists purely for side effects — printing, logging, updating a shared counter, sending a notification — anything where the point of running the code is the action itself, not a value returned from it. It is the interface quietly behind every forEach call you have already written.

What Is Consumer?

Consumer<T> declares void accept(T value) as its single abstract method, making it the target for any lambda or method reference that takes one argument and returns nothing. Its one default method, andThen, chains two consumers together so both run, in order, on the same input value.

There is no compose method on Consumer, unlike Function. compose only makes sense when there is a return value to feed from one step into the next, and a Consumer never produces one.

Why Consumer Was Introduced

Before Java 8, performing the same action for every element of a collection meant writing a loop with that action's logic sitting directly inside it, with no way to reuse the action itself somewhere else without copying the code.

Java

Try it out

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

public class BeforeConsumer {
    public static void main(String[] args) {
        List<String> rideIds = List.of("RIDE-101", "RIDE-102", "RIDE-103");

        for (String rideId : rideIds) {
            System.out.println("Dispatching driver for " + rideId);
        }
    }
}

Output:
Dispatching driver for RIDE-101
Dispatching driver for RIDE-102
Dispatching driver for RIDE-103

Wrapped as a Consumer, the same action becomes a value on its own — something forEach can run directly, something that can be passed into another method, and something that can be combined with a second, unrelated action later without editing either one.

Java

Try it out

// File: AfterConsumer.java
import java.util.*;
import java.util.function.*;

public class AfterConsumer {
    public static void main(String[] args) {
        List<String> rideIds = List.of("RIDE-101", "RIDE-102", "RIDE-103");

        Consumer<String> dispatchDriver = rideId -> System.out.println("Dispatching driver for " + rideId);

        rideIds.forEach(dispatchDriver);
    }
}

Output:
Dispatching driver for RIDE-101
Dispatching driver for RIDE-102
Dispatching driver for RIDE-103

The output has not changed. What changed is that dispatchDriver is now a named, reusable action instead of logic buried inside one specific loop.

Syntax

accept runs the action, and andThen runs two separate consumers, one after the other, on the exact same input.

Java

Try it out

// File: ConsumerSyntaxForms.java
import java.util.*;
import java.util.function.*;

public class ConsumerSyntaxForms {
    public static void main(String[] args) {
        List<String> auditTrail = new ArrayList<>();

        Consumer<String> printEvent = event -> System.out.println("Event: " + event);
        Consumer<String> recordEvent = event -> auditTrail.add(event);

        Consumer<String> printThenRecord = printEvent.andThen(recordEvent);

        printThenRecord.accept("RIDE_STARTED");
        printThenRecord.accept("RIDE_COMPLETED");

        System.out.println("Audit trail: " + auditTrail);
    }
}

Output:
Event: RIDE_STARTED
Event: RIDE_COMPLETED
Audit trail: [RIDE_STARTED, RIDE_COMPLETED]

Common Use Cases

Running an Action for Every Element

Iterable.forEach accepts a Consumer directly, running it once per element without a visible loop anywhere in the calling code.

Java

Try it out

// File: ForEachConsumerExample.java
import java.util.*;
import java.util.function.*;

public class ForEachConsumerExample {
    public static void main(String[] args) {
        List<Double> fareAmounts = List.of(145.0, 320.0, 89.0);

        Consumer<Double> printFare = fare -> System.out.println("Fare: Rs." + fare);

        fareAmounts.forEach(printFare);
    }
}

Output:
Fare: Rs.145.0
Fare: Rs.320.0
Fare: Rs.89.0

Iterating a Map With BiConsumer

Map.forEach takes a BiConsumer<K, V> instead of a plain Consumer, since each entry has both a key and a value that need handling together.

Java

Try it out

// File: MapForEachBiConsumerExample.java
import java.util.*;
import java.util.function.*;

public class MapForEachBiConsumerExample {
    public static void main(String[] args) {
        Map<String, String> driverStatus = new LinkedHashMap<>();
        driverStatus.put("DRV-01", "ON_TRIP");
        driverStatus.put("DRV-02", "AVAILABLE");

        BiConsumer<String, String> printStatus = (driverId, status) ->
            System.out.println(driverId + " -> " + status);

        driverStatus.forEach(printStatus);
    }
}

Output:
DRV-01 -> ON_TRIP
DRV-02 -> AVAILABLE

Chaining Independent Actions

andThen runs both consumers unconditionally, which makes it a natural fit for two side effects that have nothing to do with each other but need to happen for the same event.

Java

Try it out

// File: ChainedActionsExample.java
import java.util.function.*;

public class ChainedActionsExample {
    static int notificationsSent = 0;

    public static void main(String[] args) {
        Consumer<String> logToConsole = message -> System.out.println("LOG: " + message);
        Consumer<String> sendNotification = message -> notificationsSent++;

        Consumer<String> handleEvent = logToConsole.andThen(sendNotification);

        handleEvent.accept("Payment received");
        handleEvent.accept("Ride completed");

        System.out.println("Notifications sent: " + notificationsSent);
    }
}

Output:
LOG: Payment received
LOG: Ride completed
Notifications sent: 2

Accepting a Consumer as a Callback

Passing a Consumer into a method turns that method into a reusable hook point, letting the caller decide what happens next without the method itself needing to know.

Java

Try it out

// File: CallbackConsumerExample.java
import java.util.*;
import java.util.function.*;

public class CallbackConsumerExample {
    static void processOrder(String orderId, Consumer<String> onComplete) {
        System.out.println("Processing " + orderId);
        onComplete.accept(orderId);
    }

    public static void main(String[] args) {
        processOrder("ORD-77", orderId -> System.out.println(orderId + " marked complete"));
    }
}

Output:
Processing ORD-77
ORD-77 marked complete

Real-World Example

A ride-booking app typically needs several unrelated things to happen whenever a ride's status changes — an audit log entry gets written, an analytics counter gets updated, and the customer gets notified. Writing all three directly inside the status-update method means every new listener requires editing that method again. Registering each action as a Consumer<RideEvent> lets the ride service publish one event and stay completely unaware of how many listeners are reacting to it.

Java

Try it out

// File: RideEvent.java

public class RideEvent {
    private final String rideId;
    private final String status;

    public RideEvent(String rideId, String status) {
        this.rideId = rideId;
        this.status = status;
    }

    public String getRideId() {
        return rideId;
    }

    public String getStatus() {
        return status;
    }
}

Java

Try it out

// File: RideEventPublisher.java
import java.util.*;
import java.util.function.*;

public class RideEventPublisher {
    private final List<Consumer<RideEvent>> listeners = new ArrayList<>();

    public void subscribe(Consumer<RideEvent> listener) {
        listeners.add(listener);
    }

    public void publish(RideEvent event) {
        for (Consumer<RideEvent> listener : listeners) {
            listener.accept(event);
        }
    }
}

Java

Try it out

// File: RideService.java

public class RideService {
    private final RideEventPublisher publisher;

    public RideService(RideEventPublisher publisher) {
        this.publisher = publisher;
    }

    public void updateStatus(String rideId, String status) {
        System.out.println(rideId + " status changed to " + status);
        publisher.publish(new RideEvent(rideId, status));
    }
}

Java

Try it out

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

public class RideEventDemo {
    public static void main(String[] args) {
        List<String> auditLog = new ArrayList<>();
        Map<String, Integer> statusCounts = new LinkedHashMap<>();

        RideEventPublisher publisher = new RideEventPublisher();

        // Each listener is a Consumer - new listeners register here without
        // RideService ever needing to know they exist
        publisher.subscribe(event -> auditLog.add(event.getRideId() + ":" + event.getStatus()));
        publisher.subscribe(event -> statusCounts.merge(event.getStatus(), 1, Integer::sum));
        publisher.subscribe(event ->
            System.out.println("Notify customer: ride " + event.getRideId() + " is now " + event.getStatus()));

        RideService rideService = new RideService(publisher);
        rideService.updateStatus("RIDE-201", "STARTED");
        rideService.updateStatus("RIDE-202", "STARTED");
        rideService.updateStatus("RIDE-201", "COMPLETED");

        System.out.println("Audit log: " + auditLog);
        System.out.println("Status counts: " + statusCounts);
    }
}

Output:
RIDE-201 status changed to STARTED
Notify customer: ride RIDE-201 is now STARTED
RIDE-202 status changed to STARTED
Notify customer: ride RIDE-202 is now STARTED
RIDE-201 status changed to COMPLETED
Notify customer: ride RIDE-201 is now COMPLETED
Audit log: [RIDE-201:STARTED, RIDE-202:STARTED, RIDE-201:COMPLETED]
Status counts: {STARTED=2, COMPLETED=1}

A mistake that appears often in fresher pull requests is putting all three listener actions directly inside RideService.updateStatus. The moment a fourth listener needs adding, that method keeps growing, while the subscribe-based design here lets a new listener register in RideEventDemo without RideService or RideEventPublisher changing at all.

Combining Consumer With Other Features

Consumer pairs naturally with forEach on both Iterable and Stream, and andThen is how several independent side effects run for the same input without any of them knowing about the others — exactly the pattern RideEventPublisher relies on. BiConsumer<T, U> extends the same idea to two arguments, most often seen in Map.forEach. Unlike Function, Consumer has no compose, because there is no return value for an earlier step to feed into a later one.

Best Practices

Keep each Consumer responsible for exactly one side effect, and combine independent ones with andThen rather than writing a single consumer that tries to do everything, the way RideEventDemo keeps its audit logging, metrics counting, and customer notification as three separate registrations.

Avoid designing a system where the order consumers run in actually matters, unless andThen establishes that order explicitly. A list of independently registered listeners, like the ones inside RideEventPublisher, should ideally behave correctly no matter what order they happen to run in.

Remember that Consumer always returns void. The moment a caller needs a result back from an operation, Consumer is the wrong interface entirely, and reaching for Function instead avoids the awkward workarounds a Consumer forces on you.

Common Mistakes

Assuming andThen short-circuits the way Predicate.and() does is a mistake that catches people who have already learned Predicate first. Consumer.andThen always runs both consumers, because there is no boolean result to short-circuit on.

Java

Try it out

// File: ConsumerAndThenAlwaysRunsMistake.java
import java.util.function.*;

public class ConsumerAndThenAlwaysRunsMistake {
    public static void main(String[] args) {
        Consumer<Integer> checkAndWarn = amount -> {
            if (amount > 1000) {
                System.out.println("Warning: large amount " + amount);
            }
        };
        Consumer<Integer> processPayment = amount -> System.out.println("Processing payment of " + amount);

        // andThen always runs both consumers - there is no boolean result
        // to short-circuit on, unlike Predicate's and()
        Consumer<Integer> handlePayment = checkAndWarn.andThen(processPayment);

        handlePayment.accept(1500);
        handlePayment.accept(200);
    }
}

Output:
Warning: large amount 1500
Processing payment of 1500
Processing payment of 200

Trying to return a value from inside a Consumer lambda body does not compile, because accept is declared to return void.

Java

Try it out

// File: ConsumerReturnValueMistake.java
import java.util.function.*;

public class ConsumerReturnValueMistake {
    public static void main(String[] args) {
        // Consumer<String> broken = message -> {
        //     return message.toUpperCase();
        // };
        // This does not compile - accept() returns void, so a lambda body
        // implementing Consumer cannot return a value from it

        Function<String, String> correct = message -> message.toUpperCase();
        System.out.println(correct.apply("use function instead"));
    }
}

Output:
USE FUNCTION INSTEAD

A subtler version of the same mistake shows up when a Consumer is used to smuggle a transformed value out through a captured variable instead of simply returning it from a Function. It technically works, but it reintroduces the exact effectively-final and shared-mutable-state problems that make lambdas harder to reason about in the first place, for no real benefit over declaring the operation as a Function and letting it return its result normally.

Interview Questions

Q1. What is the Consumer interface in Java, and what is its single abstract method?

Consumer<T> represents an operation that takes one argument and returns nothing, declaring void accept(T value) as its single abstract method. It exists for side effects — printing, logging, updating shared state — and it is the interface behind forEach on both Iterable and Stream. Interviewers typically pair this question with asking how Consumer differs from Function, since confusing the two is common among freshers still getting comfortable with java.util.function.

Q2. What is the difference between Consumer and Function?

Consumer<T> takes a value and returns nothing, existing purely for its side effect. Function<T, R> takes a value and returns a transformed one, existing to produce a result the caller actually uses. The practical test is simple: if the code you are writing needs to hand a value back to whatever called it, it belongs in a Function; if it only needs to act on a value, Consumer is the correct shape.

Q3. Does Consumer.andThen short-circuit the way Predicate.and() does?

No. Predicate.and() short-circuits based on a boolean result, skipping the second predicate once the outcome is already decided. Consumer.andThen has no boolean result to make that decision with, so both consumers always run, in order, every time. This distinction is a common interview trap for candidates who assume every andThen-style method behaves the same way across every functional interface.

Q4. What is BiConsumer, and when would you use it instead of Consumer?

BiConsumer<T, U> is the two-argument version of Consumer, declaring accept(T first, U second) instead of a single parameter. It is used whenever an operation needs both a key and a value together, most commonly with Map.forEach, which hands each entry's key and value to the BiConsumer as two separate arguments rather than as one combined object.

Q5. Why does Iterable.forEach accept a Consumer instead of a Function?

Because forEach exists purely to perform an action on every element — it has no way to collect or return transformed values, and it does not need one. Accepting a Consumer matches that contract exactly: run this action for each element and produce nothing back. If a transformed result is actually needed, Stream.map combined with Function is the correct tool, not forEach.

Q6. Can a Consumer implementation throw a checked exception?

Only by catching it internally and handling it, or wrapping it as an unchecked exception before it leaves accept. The Consumer interface's accept method does not declare any checked exceptions in its signature, so a lambda assigned to Consumer cannot let a checked exception propagate out of it directly — the same restriction that applies to every other interface in java.util.function.

FAQs

Can Consumer have more than one input parameter?

Not through Consumer<T> itself, which takes exactly one argument. For two arguments, java.util.function provides BiConsumer<T, U>, most commonly used with Map.forEach.

Does Consumer support primitive types without boxing?

Not through Consumer<T> directly, since its type parameter must be a reference type. IntConsumer, LongConsumer, and DoubleConsumer exist specifically to accept primitive values without the cost of autoboxing.

Can I chain more than two consumers together with andThen?

Yes, without any limit. Each call to andThen returns a new Consumer, so a.andThen(b).andThen(c).andThen(d) runs all four actions in sequence for the same input, one after another.

What happens if the first consumer in an andThen chain throws an exception?

The exception propagates immediately, and the second consumer never runs. andThen provides no built-in error handling — if one consumer failing should not prevent the next one from running, that has to be handled explicitly, usually with a try-catch inside the individual consumer itself.

Is Consumer the same as Runnable?

No. Runnable takes no arguments and returns nothing, declaring void run(). Consumer<T> takes exactly one argument and returns nothing, declaring void accept(T value). Both exist for side effects, but Runnable has nothing to act on while Consumer always operates on the value it receives.

Can a Consumer capture and modify an outside variable?

Yes, as long as that variable is not a local variable being reassigned inside the lambda, since local variables captured by a lambda must remain effectively final. Modifying a field on a captured object, or a variable declared outside any method, works without restriction, exactly as statusCounts.merge(...) does inside the ride event example above.

Why does my Consumer lambda give a compile error about returning a value?

The lambda body contains a return statement that provides a value, but Consumer.accept is declared to return void. A Consumer lambda can use a bare return; with no value to exit early, but it can never return something — if a value genuinely needs to come back out, the operation should be written as a Function instead.

Summary

Consumer<T> gives every side-effect-only operation in your codebase a shared, reusable shape — accept performs the action, and andThen lets several unrelated actions run for the same input without any of them needing to know the others exist. It is the interface quietly running behind every forEach call, and the moment a caller genuinely needs a result handed back, that is the signal Consumer is the wrong tool and Function is the right one.

The event listener pattern the ride-booking example builds on here — publish once, let independently registered consumers react however many ways are needed — is one of the most common places Consumer earns its place in a real codebase, and it is worth recognizing the shape of that pattern the next time a method starts accumulating unrelated side effects that all belong somewhere else.

What to Read Next

Continue Learning Functional Programming

Next Step

Supplier

Learn how to write a function that produces a value with no input.

→

Why Generics?

Learn the problem generics were created to solve.

→

Lambda Expressions

Learn how to write a small function in a single line.

→

Optional

Learn how to represent a value that might not be there.