In Java, is there a performance difference between new and local?

In C and C++ I know that there could be a huge difference in performance between instantiating objects on the stack vs. using 'new' to create them on the heap.

Is this the same in Java?

The 'new' operator in Java is very convenient (especially when I don't have to remember freeing/deleting the object开发者_如何转开发s created with 'new'), but does this mean that I can go wild with 'new'?

Erm, there is no other way in java to instantiate an object.

All objects are created with new, and all objects are created on the heap.

in Java, when you say

MyObject foo;

You're simply declaring a variable (reference). It isn't instantiated until you say

foo = new MyObject();

When all references to that object are out of scope, the object becomes elegible for garbage collection. You'll note there's no such thing as delete in java :)

There is no allocation of objects on the stack in Java.

Only local variables (and parameters) can live on the stack and those can only contain references or primitive values, but never objects.

You can't create objects on the stack, you can only have primitives and references on the stack, so the question doesn't apply to Java.

There have been attempts to use escape analysis to optimise objects which are short lived (and possibly put them on the stack instead) however I haven't seen any evidence this improved performance.

Part of the reason there isn't the same performance hit/benifit as there would be in C/C++ is that Java has thread local allocation on the heap and objects are not recycled as agressively. C/C++ has thread local stacks, but you need additional libraires to support multi-thread object allocation. Objects are recycled more aggresively which increases the cost of object allocation.

One of the biggest changes coming from C/C++ world is to find that Java has far less features, but tries to do make the most of them (There is alot of complex optimisation going on in the JVM) On the other hand Java has a rich/baffling array of open sources libraries.

Repeat after me: there is no allocation of objects on the stack in Java

In Java, unlike C++, all objects are allocated on the heap, and the only way out is when they are garbage collected.

In Java, unlike C++, the variable falling out of scope does not mean that the destructor of the object runs; in fact, there is no destructor. So the variable might fall out of scope, but the object remains alive on the heap.

Can I go wild with 'new'?

Yes. First, because it's the only way to instantiate an object. Second, because the JVM is so good it can create up to 2^32 ightweight objects in less than a second.

In Java, there is no way to manually allocate objects on the Stack, though the compiler may decide to allocate objects created with 'new' on the stack, see Java theory and practice: Urban performance legends, revisited.

There's really nothing to compare here: you can't create objects on the stack in Java.

If it's any comfort, however, heap-based allocation in Java is (at least usually) quite fast. Java's garbage collector periodically "cleans up" the heap, so it basically looks a lot like a stack, and allocating from it is a lot like allocating from a stack as well -- in a typical case, you have a pointer to the beginning (or end) of the free memory area, and allocating a chunk of memory simply means adding (or subtracting) the amount from that pointer, and returning the address of the beginning (then, of course, constructing an object (or objects) in that area, etc.)