30

Possible Duplicate:
difference between string object and string literal

Let's say I have two statements. 

String one = "abc";
String two = new String("abc");

Which one is a stack memory and which is stored in heap?

What is the difference between these both?

How many objects are created and how is the reference in memory?

What is the best practice?

trincot
  • 317,000
  • 35
  • 244
  • 286
Some Java Guy
  • 4,992
  • 19
  • 71
  • 108
  • It depends on where you are declaring them. – ironwood Apr 03 '12 at 10:50
  • This question was discussed before ... refer to the given link http://stackoverflow.com/questions/3297867/difference-between-string-object-and-string-literal – AurA Apr 03 '12 at 10:53
  • It is impossible in general to know whether *any* object is stored on the stack. See http://stackoverflow.com/questions/2787611/why-does-java-uses-heap-for-memory-allocation – Raedwald Jul 11 '14 at 10:18

4 Answers4

29

All objects are stored on the heap (including the values of their fields).1

Local variables (including arguments) always contain primitive values or references and are stored on the stack.1

So, for your two lines:

String one = "abc";
String two = new String("abc");

You'll have two objects on the heap (two String objects containing "abc") and two references, one for each object, on the stack (provided one and two are local variables).

(Actually, to be precise, when it comes to interned strings such as string literals, they are stored in the so called string pool.)

How many objects are created and how is the reference in memory?

It is interesting that you ask, because Strings are special in the Java language.

One thing is guaranteed however: Whenever you use new you will indeed get a new reference. This means that two will not refer to the same object as one which means that you'll have two objects on the heap after those two lines of code.

1) Formally speaking the Java Language Specification does not specify how or where values are stored in memory. This (or variations of it) is however how it is usually done in practice.

aioobe
  • 413,195
  • 112
  • 811
  • 826
  • 8
    Good answer. But in reality it's not that simple anymore. The JVM might do escape analysis and decide to allocate objects directly on the stack, which means cleaning them up when the method ends is free. But that's an advanced optimization that you don't normally need to know about. – Jesper Apr 03 '12 at 11:07
  • When you say "including their attributes", is attributes another term for class member fields? – jmrah Nov 08 '19 at 15:15
  • Yes. Answer updated. – aioobe Nov 08 '19 at 17:02
9

The first one is called as a String Literal and created at the time of compilation of the program and the 2nd one is string object and is created at the runtime.

As you used new keyword in 2nd case so it is allocated in heap.

In the first case the objects are created with the mechanism called interning. When you try to create another string literal representing the same sequence of characters, then instead of creating a new object compiler will refer to the previous string created and stored in the string pool

Chandra Sekhar
  • 18,914
  • 16
  • 84
  • 125
  • new String("abc") will create string object in heap, b'coz new keywork create objects in heap. While String str = "abc" will create String literal in String pool, String pool is present in PeremGen space. – Akash5288 Sep 01 '15 at 15:06
5

Only instances of primitive types (int, long, ...) are saved on stack. All instances of reference types (String, Integer, Long, YourTypeHere, ...) are saved in heap.

UPDATE As pointed out in comments, references to instances of reference types (that is, non-primitive types -- Object and its' descendants) can be saved on stack. These are your local variables.

This is not "a best practice", it's the way JVM works and you can't change it.

Victor Sorokin
  • 11,878
  • 2
  • 35
  • 51
  • 4
    No, references are not kept in the heap. Objects are. – aioobe Apr 03 '12 at 10:50
  • @aioobe fixed wording to use "instances of ... type", to clarify this. – Victor Sorokin Apr 03 '12 at 10:52
  • 2
    Victor, your answer is still misleading. The value of a variable of a reference type (`a` in `String a`) can very well be stored on the stack. The *object* it refers to however, is stored on the heap. – aioobe Apr 03 '12 at 11:20
  • 3
    second that. Primitive values can be allocated on the heap if they are fields of a class, because they will be stored along with the object they belong to. What is created with the keyword 'new' goes to the heap. Stack values only exist within the scope of the method they are created in. – dgt Nov 29 '12 at 21:58
3

In your case 2 String objects are created. Generally, all objects are created on the heap. However since String one is a string literal, this will be stored in the string pool (in PermGen). You can also use the intern() method to add a string to the string pool and get a reference to it.

If the declarations you posted are in a method then the references will be stored on the stack, but not the objects themselves.

As for, best practice i think it would be: String one="abc"

This is for 2 reasons:

  1. The code is cleaner
  2. Interned strings can be compared with == which is faster than equals. But you'll need to intern() any non-literal string before you can compare it.

EDIT: You might be interested in checking out this link: Escape Analysis in Java SE 7. It presents some HotSpot related optimizations which affect object allocation.

Filip
  • 1,451
  • 1
  • 11
  • 19