I know that when declaring object instances in c++ like so:
Object object
the Object constructor is called and memory is provided for that object, however i find that when you do this in java the object instance doesn't have a value until:
object = new Object()
is written. I want to know specifically when memory is provided for the object. I thought that both construction and the new keyword allocated memory so Object object = new Object() seems redundant. I read on oracle's site that declaration "reserves" memory and new "allocates" memory, I would like to know what is the difference between the two.
You need to differentiate between the space required for the variable and the space required for the object. Bear in mind that the value of the variable is just a reference - very much like a pointer in C++. So if you have:
Object x = null;
then the variable x itself takes up enough space for a reference (usually 4 or 8 bytes). Now if you have:
x = new Object();
that creates an object - the value of x is now a reference to the newly created object. x itself takes up the same amount of space as before, but there's also the space required for the object itself (basically the fields, a reference for the type of the object, and data for synchronization and house-keeping).
When you do something like
Object object = new Object()
in Java, object is a reference to the actual instance on the managed heap. Compared to C++, that's roughly doing
Object* object=new Object()
So when you do
Object object;
in Java, a place is created for the 'reference' to a instance.
Similar to
Object* object;
in C++.
Object foo=null;
in meaning of C++ creates reference foo to the object of class Object. So, it consumes memory for reference only.
Object realFoo=new Object();
creates such reference and also real object with whatever is with this object. So, it is memory for the reference and object itself.
In Java there is no memory reservation - only memory allocation.
declaration reserves memory: parameters and variables inside a method will have memory reserved for them in the stackframe.
allocates memory: at runtime, when executing "new", memory will be allocated for the new Object on the heap
It's important to understand that in Java, Object object is simply a reference to an Object called object. If you're familiar with C++, you can think of this reference as a pointer (though it's not quite the same).
On a 64-bit machine, the object reference is 8 bytes. When you actually instantiate an Object using the new keyword and assign it to the reference, this is where memory is allocated for your Object.
Related
I've been practicing component based design pattern and I was wondering if when you initialize an variable without reference meaning initialized as null, Java go ahead and attribute a space in memory that has the size of the variable even though it is set to null so that eventually when you need to reinitialize it with a new instance of a class it just copies the fields of the new instance?
A variable whose type is a reference type occupies the same amount of space whether it contains null or a reference to an object.
However, the variable only holds the reference ... not the object itself.
... when you need to reinitialize it with a new instance of a class it just copies the fields of the new instance?
Erm ... no. When you later "initialize" the variable, you are assigning a reference to the variable. You are not copying the fields of the object.
For example:
SomeType s = null; // the declaration sets aside space for one
// reference, and the initialization assigns
// `null` to it.
s = new SomeType(...) // the 'new' expression creates the object and
// which allocates the space, etcetera
// the assignment merely assigns the reference
// for that object to 's'.
What if "s" is an array of "Sometype" instead still initialized to null, will it be legit to assume that only space for one reference will be saved until you create a new valid reference for an array of the relevant type?
An array type is also a reference type. So, yes, the answer is the same. A declaration SomeType[] s would reserve space for one reference.
I was wondering if when you initialize an variable without reference meaning initialized as null, Java go ahead and attribute a space in memory that has the size of the variable even though it is set to null
Yes memory is allocated for the variable, but this is only a tiny address space bit of memory and nothing else. No memory is allocated for the eventual object.
so that eventually when you need to reinitialize it with a new instance of a class it just copies the fields of the new instance?
When you create an instance of anything, then memory is allocated on the heap for the object, and this happens whether or not the object is assigned to a variable, to no variables, or to 50 variables, and any variable that refers to the object has its address space pointing at the object's location on the heap (perhaps -- I don't think that the actual mechanics, the hows, are fully specified)
Have a look at oracle documentation page regarding objectcreation
Point originOne;
If you declare originOne like this, its value will be undetermined until an object is actually created and assigned to it. Simply declaring a reference variable does not create an object.
For that, you need to use the new operator, as described in the next section. You must assign an object to originOne before you use it in your code.
Instantiating a Class
The new operator instantiates a class by allocating memory for a new object and returning a reference to that memory. The new operator also invokes the object constructor.
Note: The phrase "instantiating a class" means the same thing as "creating an object." When you create an object, you are creating an "instance" of a class, therefore "instantiating" a class.
The new operator returns a reference to the object it created. This reference is usually assigned to a variable of the appropriate type, like:
Point originOne = new Point(23, 94);
I hope above picture clarifies your queries.
The size of reference will be 4 bytes or 8 bytes. Have a look at this SE question:
How big is an object reference in Java and precisely what information does it contain?
In Java, when we only declare a variable of a class type, only a reference is created (memory is not allocated for the object). Is to hold the reference t somewhere space will be created on heap ? or if i'm wrong then what happens exactly in memory when we just declare variable ?
Test t;
In Java, when we only declare a variable of a class type, only a reference is created (memory is not allocated for the object).
This is correct.
Is to hold the reference t somewhere space will be created on heap?
The answer depends on the context in which the declaration appears. If the said declaration is part of an object (i.e. t is a field) then the space for the reference would be allocated from the heap, along with the space for the rest of the object containing the field. Otherwise, the space for the reference would be allocated in JVM's stack frame.
When you declare a variable:
Test t;
space is made for the reference (a fixed amount, doesn't depend on the number of members in the class). When you instantiate a variable, using the new keyword:
t = new Test();
then space for the variable is made on the heap, and t references that space. This has to be large enough to hold all the members of a Test.
While reading on Thread Safety I came across this issue.
If I'm correct method local Primitives and object references lives inside a stack and actual objects pointed by the references inside the stack lives in the heap.
But when it comes to method local non primitive object initialization, wouldn't that cause a concurrency issue ? I mean if the method locals non primitives lives in the heap and only the pointers lives in the stacks, isn't it the same as of instance variables ?
Can someone please help me to understand this....
PS
Think of two threads with each having two stacks of their own and one heap. What I understood is that the two threads keep their method local primitive variables inside their stacks. I have no issue with that.
But what if we have a method with non primitive method local variables ? Then if the object for that variable is stored inside the heap, both the threads will have the access to the same object, won't they ? So if that's the case there would be Sync problems.
That is what I'm asking.
Thanks
But what if we have a method with non primitive method local variables
? Then if the object for that variable is stored inside the heap, both
the threads will have the access to the same object, won't they ? So
if that's the case there would be Sync problems.
I wonder why you will think the two references will refer to the same object.
The creation of the object referred is explicitly done by new (or other similar method, but idea is the same)
Therefore, unlike in C++, if you are declaring this in Java
Foo foo;
there is no Foo object instantiated. foo is just a pointer pointing to nothing.
This will create you a Foo object instance in heap.
Foo foo = new Foo();
If two thread is running this piece of code, thread 1 will have a Foo reference in stack, and ask to allocate a new Foo object in heap, and then assign the address of that Foo obj to the reference foo. Thread 2 is doing the same. Note that Thread 2 is also asking to allocate a new Foo object, it will be a different object from what Thread 1 is allocated.
That's the basic (and much simplified) idea.
Both threads could have access to the same object if they both have a reference to the object. If you have a method like the following:
public String concat(String a, String b) {
StringBuilder builder = new StringBuilder();
builder.append(a);
builder.append(b);
return builder.toString();
}
The StringBuilder object is indeed in the heap, but only one thread has a reference to this object. No other thread can have a reference to this StringBuilder. So it's inherently thread-safe.
If, on the contrary, you have the following:
public String concat(String a, String b) {
final StringBuilder builder = new StringBuilder();
new Thread(new Runnable() {
#Override
public void run() {
builder.append("haha!");
}
}).start();
builder.append(a);
builder.append(b);
return builder.toString();
}
Then you have a thread-safety issue, because you shere the locally created object reference with another thread, and StringBuilder is not thread-safe.
But what if we have a method with non primitive method local variables ? Then if the object for that variable is stored inside the heap, both the threads will have the access to the same object, won't they ? So if that's the case there would be Sync problems
You partially answered your own question.That reference value is stored in the stack but the actual object content is stored in heap and when you call new Object() each thread creates different new object that will be stored in the heap and each thread access the object it has created using the reference value stored in its own stack
Local variables are either primitives, references to objects created somewhere else (if you do an assignation), or references to newly created objects (using "new" operator)
For the first case, as you said, there is no issue.
For the last case, as you are locally craeting a new object, a new object will be created at every call, so no concurrency issue because there will be one object in the heap for each call
But for the second case, as the object has been created somewhere else, you have to think about concurrency
Just to toss in my thoughts regarding what may be your point of confusion: the heap is not managed like the stack. It is shared, yes - in that objects created by all threads are in the heap. However as each object is created, it's given a unique location/space in the heap. Two methods on two threads running concurrently and creating an object instance will create distinctly different objects in the shared heap.
They're created in this shared heap so that if method foo returns the object reference, or stores it, or calls another method that indirectly stores it... it won't be destroyed when foo returns and the stack is popped.
The magic of having a garbage collector is that you don't have to keep track of this "stuff" and destroy it yourself at some appropriate point in the future. Keeps your code simple, lets you focus on algorithms (or learning to program). But I digress...
In Java, if I declare,
MyClass obj;
Is obj called a "reference" or an "object". I am not instantiating class here.
obj is a Reference to an instance of MyClass.
Currently, that Reference is NULL because you haven't assigned it to refer to any instance.
Technically MyClass must be a subclass of Object, so it is possible to say that obj is a Reference to an instance of Object as well.
Reference: A variable that points to some object in memory.
It is stored in stack they can be contained in other objects (then they are not really variables, but fields), which puts them on the heap also.
Object: An instance of class that is created dynamically.
It is stored in heap
Example:
MyClassI aObj,aObj1;
aObj=new MyClass2();
At first line aObj and aObj1 are references
At second line aObj referencing to object of MyClass2(New operator creates an object of Myclass2 and its address is assigned to aObj).
To understand even better consider a class Car which has driverName as a member.
Car c1,c2;
c1.driverName="Andrew"
c2.driverName="Gabriel"
System.out.println(c1.driverName);//gives Andrew
System.out.println(c2.driverName);//gives Gabriel
c1=c2;
c2=null;
// gives gabriel because the address of c2 is copied to reference c1.
// the object is not nullified because c2 is just a reference when
// assigning null the address that is stored on c2 in nullified not
// the object it points..
system.out.println(c1.driverName);
In computer science, a reference is a
value that enables a program to
indirectly access a particular data
item, such as a variable or a record,
in the computer's memory or in some
other storage device. The reference is
said to refer to the data item, and
accessing that data is called
dereferencing the reference.
In computer science, an object is any
entity that can be manipulated by the
commands of a programming language,
such as a value, variable, function,
or data structure. (With the later
introduction of object-oriented
programming the same word, "object",
refers to a particular instance of a
class)
so obj is a reference and new MyClass() can be seen as an object
obj is a Reference of type MyClass. The current reference does not point to anything (ie: null).
Sometimes you'll hear people say "Design an method that takes an object as a parameter and..."
If you're new to programming, and especially with Java, such statements can lead to some confusion. These people are using the word "object" to refer to an instance of a class in very general OOP terms, not necessarily Java specific.
When we're talking specifics about Java and the code you have there, it is a reference to an instance of MyClass, which is NULL.
'obj' is a variable. It holds either a reference or null. If it holds a reference, that refers to an object.
In Java, all objects are accessed by reference, and you never have direct access to the object itself.
reference :- is a variable that has a name and can be used to access the contents of an object, A reference can be assigned to another reference passed to a method, or returned from a method. All references are the same size, no matter what their type is Like "Object object ;".
object:- is an entity that's exists in memory allocated by the Java run time environment, An object sits on the heap and does not have a name Like "Object object=new Object();".
so MyClass obj Here is A reference referred to Null.
We can summarize this principle with the following two rules:
The type of the object determines which properties exist within the object in memory.
The type of the reference to the object determines which methods and variables are accessible to the Java program.
The reference is a variable that has a name and can be used to access the contents of an object. A reference can be assigned to another reference, passed to a method, or returned from a method.
All references are the same size, no matter what their type is.
An object sits on the heap and does not have a name. Therefore, you have no way to access an object except through a reference. Objects come in all different shapes and sizes and consume varying amounts of memory. An object cannot be assigned to another object, nor can an object be passed to a method or returned from a method. It is the object that gets garbage collected, not its reference.
Where does the Java JVM store primitive variables, and how is the memory used by primitives freed after use?
I guess it is on the stack?
Simplistic answer: it depends on where the variable is declared, not on its type.
Local variables are stored on the stack. Instance and static variables are stored on the heap.
Don't forget that for reference type variables, the value of a variable is a reference, not the object. (Arrays are reference types too - so if you have an int[], the values will be on the heap.)
Now, this is potentially an overly simplistic answer, because a smart VM may be able to detect if a particular reference type variable refers to an object which can never "escape" the current method. If that's the case, it could potentially inline the whole object on the stack.
But conceptually this model is accurate. So a variable of type int which is declared as an instance variable like this:
class Foo
{
private int value;
...
}
will conceptually live on the heap, as part of the data of any instance of Foo. It will be freed as part of freeing the instance - it's just 4 bytes within the block of data representing a Foo instance; it doesn't need separate deallocation.
Where a variable is stored depends on whether a variable is a local variable or an instance variable.
Local variables are stored on the stack. Instance and static variables are stored on the heap.
Let me explain this with an example. Lets say we have an instance variable animal of some custom class Animal.
Animal animal = new Dog();
Here animal is just a reference and is located on the stack. The actual object is allocated memory on the heap. This reference animal will point to this object memory allocated on the heap. So if you have 3 reference pointing to the same object.
Animal animal1 = new Dog();
Animal animal2 = new Dog();
Animal animal3 = new Dog();
All three reference will be in stack. When I say reference it is just a pointer pointing to the object on the heap. In terms of memory this reference holds the address(not actually there a bit more abstraction here) of the object on the heap. So 4 bytes on 32 bits and 8 bytes on 64 bits. Only when all the three references are dereferenced i.e they are no longer in scope(or rather no longer pointing to the original object) then only garbage collector is free to deallocate the memory allocated to the object on the heap.
There is a slight variation when we store primitive types or String literals.Unless you explicitly create their object using new() operator they are created and stored in permGen area of Heap.
So both references firstString and secondString in
String firstString = "Stack";
String secondString = "Stack";
will point to the same object in the String pool. It would point to different objects when we create them using new().
Class objects, including method code and static fields: heap.
Objects, including instance fields: heap.
Local variables and calls to methods: stack..