1

Let's say we have an instance reference variable assigned to an object.

public class Player {
     private Object object = new Object();
}

whenever I create a new Player instance.

Player player = new Player();

As far as I have learned, might be wrong I'm pretty new to this. The heap allocates memory for the instance primitive variables and stores these in the objects.

If it does the same for the instance reference variable which is assigned to an object, doesn't this instantly create a new instance or does this only occur when calling the reference variable?

Dave
  • 23
  • 6
  • In java the objects are stored in heap and the pointer(address of the location) is assigned to a location in the stack. – jobinrjohnson Jul 07 '17 at 12:55
  • Java allocates memory for an instance once it see the "new" key word, and the reference is updated with the container object. More information https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html – sanoj mathew Jul 07 '17 at 13:00
  • duplicate of https://stackoverflow.com/questions/8588152/, https://stackoverflow.com/questions/6396440/, https://stackoverflow.com/questions/19402207. In short, depends on the JVM and whether escape analysis allows allocation on the stack. – Njol Jul 07 '17 at 13:00
  • i'll have read on that @sanojmathew thanks! I'm not talking about local variables Njol, just unsure of whether the objects are created upon creating a new instance of the class(the assigned instance reference belongs to) – Dave Jul 07 '17 at 13:05
  • @JobinJohnson: No, that's an oversimplification. In particular, the `object` field (as it's part of an object) is on the heap, not on the stack. – Jon Skeet Jul 07 '17 at 13:24

1 Answers1

0

If I'm understanding your question correctly, instantiating a new Player instance (on the heap) also instantiates a new Object (on the heap), and the Player instance holds a reference to the Object instance. Java doesn't do "lazy" instantiation.

Steve11235
  • 2,849
  • 1
  • 17
  • 18
  • So basically, this would take up unnecessary memory and it would be better to just create an Object whenever it's required? – Dave Jul 07 '17 at 13:27
  • enclosed instances are always created. So, if you don't need the instance don't create it. – Ramandeep Nanda Jul 07 '17 at 13:28
  • Java actually does a form of lazy instantiation. – Lew Bloch Jul 07 '17 at 13:48
  • @Dave, what makes the instantiation "unnecessary"? – Lew Bloch Jul 07 '17 at 13:49
  • @LewBloch Let's say I simply require this `Object` to be instantiated on certain circumstances, it would take up unnecessary memory to have it instantiate whenever a new Player is instantiated, right? – Dave Jul 07 '17 at 14:17
  • You can implement lazy instantiation yourself. Just declare the "object" field and leave it null. When you go to use the field, you will have to check if it still null and instantiate it if not. One way to do this is to access "object" through getObject() and put that logic inside. Caution: If you are in a threaded environment, you will have add synchronization around the instantiation of "object". – Steve11235 Jul 07 '17 at 14:30
  • "this `Object`" is too vague and general. The answer is "it depends". If `Player` has an attribute, typically the attribute's lifetime matches the `Player` instance's. Why else is it a field in the type? Why do you have `Object` if you don't need it? Why instantiate `Player` if you don't need its fields? If you have those answers then yes, leave the field at its default value (`null` for references) until the state changes. But if you make attributes `final` and eagerly initialized, and design `Player` on purpose for that, then life is a lot easier. Mismatched lifetimes require careful work. – Lew Bloch Jul 07 '17 at 15:37
  • So again, the trick is to answer the question, "What makes the instantiation 'unnecessary'?" You can't keep using the word "unnecessary" without understanding _precisely_ what it means. What makes a field "unnecessary", and why is it there if it is? What makes memory "unnecessary"? Using the term so loosely amounts to circular reasoning. – Lew Bloch Jul 07 '17 at 15:39