224

When I iterate over a collection using the new syntactic sugar of Java 8, such as

myStream.forEach(item -> {
  // do something useful
});

Isn't this equivalent to the 'old syntax' snippet below?

myStream.forEach(new Consumer<Item>() {
  @Override
  public void accept(Item item) {
    // do something useful
  }
});

Does this mean a new anonymous Consumer object is created on the heap every time I iterate over a collection? How much heap space does this take? What performance implications does it have? Does it mean I should rather use the old style for loops when iterating over large multi-level data structures?

2
  • 74
    Short answer: no. For stateless lambdas (those that do not capture anything from their lexical context), only one instance will ever be created (lazily), and cached at the capture site. (This is how the implementation works; the spec was carefully written to allow, but not require, this approach.) Commented Dec 17, 2014 at 16:23
  • 9
    infoq.com/articles/Java-8-Lambdas-A-Peek-Under-the-Hood Commented Dec 17, 2014 at 16:28

3 Answers 3

202
+200

It is equivalent but not identical. Simply said, if a lambda expression does not capture values, it will be a singleton that is re-used on every invocation.

The behavior is not exactly specified. The JVM is given big freedom on how to implement it. Currently, Oracle’s JVM creates (at least) one instance per lambda expression (i.e. doesn’t share instance between different identical expressions) but creates singletons for all expressions which don’t capture values.

You may read this answer for more details. There, I not only gave a more detailed description but also testing code to observe the current behavior.


This is covered by The Java® Language Specification, chapter “15.27.4. Run-time Evaluation of Lambda Expressions

Summarized:

These rules are meant to offer flexibility to implementations of the Java programming language, in that:

  • A new object need not be allocated on every evaluation.

  • Objects produced by different lambda expressions need not belong to different classes (if the bodies are identical, for example).

  • Every object produced by evaluation need not belong to the same class (captured local variables might be inlined, for example).

  • If an "existing instance" is available, it need not have been created at a previous lambda evaluation (it might have been allocated during the enclosing class's initialization, for example).

Sign up to request clarification or add additional context in comments.

2 Comments

can you please explain this sentence in your answer " if a lambda expression does not capture values" I am bit confused
@H.S similar to inner classes. Accessing local variables of the surrounding context will capture their value and use that value when the lambda expression’s body is evaluated. Accessing instance fields of the surrounding object requires capturing the value of the this reference, to be able to read the field when the lambda expression’s body is evaluated. You may follow the link given in the answer (this one) for practical examples.
29

When an instance representing the lambda is created sensitively depends on the exact contents of your lambda's body. Namely, the key factor is what the lambda captures from the lexical environment. If it doesn't capture any state which is variable from creation to creation, then an instance will not be created each time the for-each loop is entered. Instead a synthetic method will be generated at compile time and the lambda use site will just receive a singleton object that delegates to that method.

Further note that this aspect is implementation-dependent and you can expect future refinements and advancements on HotSpot towards greater efficiency. There are general plans to e.g. make a lightweight object without a full corresponding class, which has just enough information to forward to a single method.

Here is a good, accessible in-depth article on the topic:

http://www.infoq.com/articles/Java-8-Lambdas-A-Peek-Under-the-Hood

Comments

1

You are passing a new instance to the forEach method. Every time you do that you create a new object but not one for every loop iteration. Iteration is done inside forEach method using the same 'callback' object instance until it is done with the loop.

So the memory used by the loop does not depend on the size of the collection.

Isn't this equivalent to the 'old syntax' snippet?

Yes. It has slight differences at a very low level but I don't think you should care about them. Lamba expressions use the invokedynamic feature instead of anonymous classes.

6 Comments

Do you have any documentation specifying this? It's quite the interesting optimization.
Thanks, but what if I have a collection of collections of collections, for example when doing a depth-first search on a tree datastructure?
@A.Rama Sorry, I don't see the optimization. It is the same with or without lambdas and with or without forEach loop.
It's not really the same, but still at most one object per nesting level will be needed at any one time, which is negligible. Each new iteration of an inner loop will create a new object, most probably capturing the current item from the outer loop. This creates some GC pressure, but still nothing to really worry about.
@aalku: "Every time you do that you create a new object": Not according to to this answer by Holger and this comment by Brian Goetz.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.