Java - Memory question

[sha11e]

I remember someone telling me that there is the heap, the stack and something else.

methods are stored in ..something.. and variables somewhere - and even if they're not currently storing anything in the memory location - it's still "reserved"?
1. Does that mean it doesn't matter if I do int a = 12; and then a for loop or if I do (for(int a =12; etc?

Like, what about strings? The more data it holds it will grow bigger?
or vectors/lists.
2. Does it grow bigger? And should I do String x = null, or, String x = "" when it doesn't hold anything that I need to read anymore (but I still need that variable for input later)?

3.
What about if I use new Class() ?
Like, if I need input, is
Scanner scn = new Scanner(System.in) and then scn.nextLine()
and
String a = new Scanner(System.in).nextLine()
Does either of these take up more memory than the other?

4.
Of if I have variable declarations inside a method, does it matter if it's inside the method or outside? Memory-wise?

[JamesCherrill]

Variables come in 2 flavours - primitives like int, boolean, float and reference variables that hold a reference (pointer) to an Object. They are all so small that you rarely, if ever, need to worry about their memory. Local variables are allocated/deallocated when they come into scope / leave scope (the closes { } surrounding their declaration). Instance variables are allocated when the instance of the class is created.
Objects are allocated when you execute a "new" statement (and as couple of other special cases), and freed when there remain no variables referring to them. So
Q1: It makes no material difference
Q2 Strings are immutable, you can't make them bigger. All you can do is to change a string reference variable to point to another, longer, string object. Lists have an array somewhere in their private implementation to hold the data - when the array is full they create another bigger one and free up the old one, thus growing bigger in discrete chunks.
Nulling a variable means it no longer refers to the original object so that object may be freed up, if that was the last remaining reference to it.
3. The only difference between those 2 versions is that one has an extra reference variable (scn) which just occupies a few bytes for a short period.

[sha11e]

Variables come in 2 flavours - primitives like int, boolean, float and reference variables that hold a reference (pointer) to an Object. They are all so small that you rarely, if ever, need to worry about their memory. Local variables are allocated/deallocated when they come into scope / leave scope (the closes { } surrounding their declaration). Instance variables are allocated when the instance of the class is created.
Objects are allocated when you execute a "new" statement (and as couple of other special cases), and freed when there remain no variables referring to them. So
Q1: It makes no material difference
Q2 Strings are immutable, you can't make them bigger. All you can do is to change a string reference variable to point to another, longer, string object. Lists have an array somewhere in their private implementation to hold the data - when the array is full they create another bigger one and free up the old one, thus growing bigger in discrete chunks.
Nulling a variable means it no longer refers to the original object so that object may be freed up, if that was the last remaining reference to it.
3. The only difference between those 2 versions is that one has an extra reference variable (scn) which just occupies a few bytes for a short period.

1.
So is what I heard wrong?
About the space for the variables being 'reserved' throughout the whole program?

2.
Should I or should I not declare all my variables directly (under main method declaration) or declare and initiate as I need them?

[DavidKroukamp]

1.
So is what I heard wrong?
About the space for the variables being 'reserved' throughout the whole program?

2.
Should I or should I not declare all my variables directly (under main method declaration) or declare and initiate as I need them?

To be honest in java it doesnt really matter hey,unless you have a huge huge program you shouldnt let it bother you, if anything all you want to worry about in java is speed, which now thanks to new processors is a thing of the past-my opinion though

[sha11e]

I have 2 varibles:
BufferedReader ins = null;
static PrintStream ios = null;

Do neither use up memory at this point?
Because I only want to use one later in program.

[JamesCherrill]

1.
So is what I heard wrong?
About the space for the variables being 'reserved' throughout the whole program?

2.
Should I or should I not declare all my variables directly (under main method declaration) or declare and initiate as I need them?

Only static vars are allocated for the whole program life.
You should keep all your variables as local as possible - declare them only when you need them - that's just good programming.

But cOrRuPtG3n3t!x is right...

[JamesCherrill]

I have 2 varibles:
BufferedReader ins = null;
static PrintStream ios = null;

Do neither use up memory at this point?
Because I only want to use one later in program.

Variables, like I said, use so little memory that it's not an issue.

[DavidKroukamp]

I have 2 varibles:
BufferedReader ins = null;
static PrintStream ios = null;

Do neither use up memory at this point?
Because I only want to use one later in program.

"Static variables serve as "roots" to the GC. As a result, unless you explicitly set them to null, they will live as long as the program lives, and so is everything reachable from them" so on that i would say they both are not using up memory, however as James said the static will never die as its for the entire life of the program.

[sha11e]

"Static variables serve as "roots" to the GC. As a result, unless you explicitly set them to null, they will live as long as the program lives, and so is everything reachable from them" so on that i would say they both are not using up memory, however as James said the static will never die as its for the entire life of the program.

It's either that or create an instance of the class,
wouldn't that take up a lot of space?
If I have 10 variables in it, the object will make 10 more?

[JamesCherrill]

Are you really worrying about 10 variables? Max 80 bytes. How many megabytes does your machine have?

[sha11e]

Are you really worrying about 10 variables? Max 80 bytes. How many megabytes does your machine have?

Not exactly worried about 10 variables, no, was thinking more of bigger programs.
Why waste memory if you dont need to, even if it's not THAT much.

[DavidKroukamp]

Are you really worrying about 10 variables? Max 80 bytes. How many megabytes does your machine have?

I have to agree man, java has a great memory management module, you are playing with variables that unless you have half a meg of ram its really of non importance, worry about getting the code working java will worry about the memory.

[EDIT] the same would go why worry about memory management of variables when you dont need too? but hey whatever floats your boat hope you can save a few kilobytes in memory :)

[JamesCherrill]

What are the actual decisions here? - static vs instance variables, and scope of local variables. All these are determined by the functional requirement of the program - they are not interchangeable so there are no "memory-related" decisions anyway.
Forget the variables, and just ensure that you keep no references to any objects that you have finished with.

[~s.o.s~]

@sha11e: Strive for correctness, readability and performance; in that order. :-)

BufferedReader ins = null;
static PrintStream ios = null;

Do neither use up memory at this point?

They are simply fields of the given object i.e. names. They don't consume memory in the sense that they don't point to "real" reader or PrintStream at this point in time.

static will never die as its for the entire life of the program

This isn't entirely correct. Class unloading is possible which automatically makes these static stuff go away.

[sha11e]

They don't consume memory in the sense that they don't point to "real" reader or PrintStream at this point in time.

So they do consume some memory?

[~s.o.s~]

In the class file on disk and as part of the runtime class/object data, yes.