All 15 Functional Interfaces & Method References questions
More in Functional Interfaces & Method References
What is a functional interface, and what are the four core functional interfaces in java.util.function (Function, Predicate, Consumer, Supplier)? What are the four kinds of method references in Java (static, instance-bound, instance-unbound, and constructor), and how does the compiler determine which form applies? How do the default methods andThen() and compose() on Function work, and what's the difference between them for chaining transformations? What is the difference between UnaryOperator<T> and Function<T,T>, and why does UnaryOperator exist as a separate, more specific interface? How does the Predicate interface's default methods and(), or(), and negate() enable composing complex boolean conditions from simpler ones? What is the difference between a Consumer<T> and a BiConsumer<T,U>, and how would you use BiConsumer for operations needing two inputs but no return value, such as Map.forEach()? How would you convert a checked-exception-throwing method into a lambda usable with a standard functional interface (which doesn't declare any checked exceptions), given standard interfaces like Function don't permit checked exceptions in their abstract method signature? How does a lambda expression capture variables from its enclosing scope, and why must captured local variables be effectively final? How would you implement a custom functional interface with generic type parameters, and what considerations apply when designing one instead of reusing a built-in java.util.function interface? How would you implement memoization (caching function results) as a higher-order function wrapping an existing Function, and what thread-safety considerations apply for a memoized function used concurrently?
Advertisement
Back to results for “Performance”
Java › Functional Interfaces & Method References

How do the primitive-specialized functional interfaces (IntFunction, ToIntFunction, IntPredicate, IntUnaryOperator, etc.) avoid the performance cost of autoboxing, and when should you prefer them over the generic equivalents?

Intermediate

Answer

The generic Function<Integer, Integer> and similar boxed-type functional interfaces incur autoboxing/unboxing overhead on every invocation (wrapping a primitive int into an Integer object and back), which can be measurably significant in a performance-sensitive hot path processing large volumes of primitive data -- the primitive-specialized interfaces (IntFunction<R> takes a primitive int without boxing, ToIntFunction<T> returns a primitive int without boxing, IntUnaryOperator both takes and returns primitive int, etc.) avoid this boxing overhead entirely, making them the recommended choice specifically for performance-sensitive code operating on primitive numeric streams (like IntStream), while the generic versions remain perfectly fine for typical, non-performance-critical code.
// Generic version: boxing overhead on every call
Function<Integer, Integer> square1 = x -> x * x;

// Primitive-specialized: no boxing overhead
IntUnaryOperator square2 = x -> x * x;

IntStream.rangeClosed(1, 1_000_000)
    .map(square2)  // IntStream.map() specifically expects IntUnaryOperator, avoiding boxing entirely
    .sum();
Real-world example A numerical computation processing a stream of a million primitive integers uses IntStream combined with IntUnaryOperator throughout, avoiding the autoboxing overhead that using the generic Function<Integer,Integer> equivalent across a million elements would have measurably added to the computation's total runtime.

Common follow-ups: What specific primitive-specialized interfaces exist for long and double in addition to int?;How much actual performance difference does boxing avoidance make in practice for a typical workload size?

Streams & Lambdas;Diagnostics & Performance
All 15 Functional Interfaces & Method References questions