Strings Are Immutable Objects
In Java, each character in a string is a 16-bit Unicode character.
In Java, strings are objects. Just like other objects, you can create an instance of a String with the new keyword, as follows:
String s = new String();
This line of code creates a new object of class String, and assigns it to the reference variable s. So far, String objects seem just like other objects. Now, let's give the String a value:
s = "abc";
The String class has many constructors, so you can use a more efficient shortcut. Please see String API.
String s = new String("abc");
And just because you'll use strings all the time, you can even say this:
String s = "abc";
There are some subtle differences between these options that we'll discuss later, but what they have in common is that they all create a new String object, with a value of "abc", and assign it to a reference variable s. Now let's say that you want a second reference to the String object referred to by s:
String s2 = s; // refer s2 to the same String as s
So far so good. String objects seem to be behaving just like other objects, so what's all the fuss about?…Immutability!
Once you have assigned a String a value, that value can never change - it's immutable.
The good news is that while the String object is immutable, its reference variable is not, so to continue with our previous example:
s = s.concat("def"); // the concat() method 'appends'
// a literal to the end
The VM took the value of String s (which was "abc"), and tacked "def" onto the end, giving us the value "abcdef". Since Strings are immutable, the VM couldn't stuff this new value into the old String referenced by s, so it created a new String object, gave it the value "abcdef", and made s refer to it. At this point in our example, we have two String objects: the first one we created, with the value "abc", and the second one with the value "abcdef". Technically there are now three String objects, because the literal argument to concat, "def", is itself a new String object. But we have references only to "abc" (referenced by s2) and "abcdef" (referenced by s).
Important Facts About Strings and Memory
To make Java more memory efficient, the JVM sets aside a special area of memory called the "String constant pool." When the compiler encounters a String literal, it checks the pool to see if an identical String already exists. If a match is found, the reference to the new literal is directed to the existing String, and no new String literal object is created. (The existing String simply has an additional reference.) Now we can start to see why making String objects immutable is such a good idea. If several reference variables refer to the same String without even knowing it, it would be very bad if any of them could change the String's value.
You might say, "Well that's all well and good, but what if someone overrides the String class functionality; couldn't that cause problems in the pool?" That's one of the main reasons that the String class is marked final. Nobody can override the behaviors of any of the String methods, so you can rest assured that the String objects you are counting on to be immutable will, in fact, be immutable.
Now let's assume that no other String objects exist in the pool:
String s = "abc"; // creates one String object and one
// reference variable
In this simple case, "abc" will go in the pool and s will refer to it.
String s = new String("abc"); // creates two objects,
// and one reference variable
In this case, because we used the new keyword, Java will create a new String object in normal (non-pool) memory, and s will refer to it. In addition, the literal "abc" will be placed in the pool.
The StringBuffer and StringBuilder Classes
The java.lang.StringBuffer and java.lang.StringBuilder classes should be used when you have to make a lot of modifications to strings of characters. String objects are immutable however objects of type StringBuffer and StringBuilder can be modified over and over again without leaving behind a great effluence of discarded String objects.
StringBuffer vs. StringBuilder
The StringBuilder class was added in Java 5. It has exactly the same API as the StringBuffer class, except StringBuilder is not thread safe. In other words, its methods are not synchronized hence StringBuilder is faster than StringBuffer.