In the future, try to post a single thread per question. If one question should spark some debate, the other question could get lost in the shuffle. As for String, it is immutable for performance. If you watch a Java program with a profiler, the class with the most instances by far will be String. Since it is immutable, the compiler can use a number of tricks to optomize its use. For example, every time an identical literal is used:
the compiler will replace the duplicates with a single reference. At runtime, both Strings x and y will point to the same instance of "hey". There's no danger of x changing it's String and invalidating y. Another optimization is that substrings of a String will point to the same data as the original String:
In this example, the instance z points to the same data (though less of it) as instance x. Saves lots of memory over time and we can do it because neither instance can change the underlying data. As for HashMap, the java documentation for java.util.HashMap states the following:
If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:
Map m = Collections.synchronizedMap(new HashMap(...));
Somehow I am not convinced that string is immutable because of performance, because majority of the time we can see string addition happing inside the code , which finally creates 5/6 objects
Engineering decisions are always tradeoffs. In the case of String, Java's designers decided that having the optimizations that Jeremy and I cited above were more important than the performance impact of creating a StringBuffer every time someone wanted to concatenate Strings.