Why string is immutable in c#?

Question

Why string is immutable in c#? any Why StringBuilder is mutable? Please let me know internal working of it.

Munesh Sharma · Answer

Instances of immutable types are inherently thread-safe since no thread can modify it the risk of a thread modifying it in a way that interfers with another is removed (the reference itself is a different matter). Similarly the fact that aliasing can't produce changes (if x and y both refer to the same object a change to x entails a change to y) allows for considerable compiler optimisations. Memory-saving optimisations are also possible. Interning and atomising being the most obvious examples though we can do other versions of the same principle. I once produced a memroy saving of about half a GB by comparing immutable objects and replacing references to duplicates so that they all pointed to the same instance (time-consuming but a minute's extra start-up to save a massive amount of memory was a performance win in the case in question). With mutable objects that can't be done. No side-effects can come from passing an immutable type as a method to a parameter unless it is out or ref (since that changes the reference not the object). A programmer therefore knows that if string x = abc at the start of a method and that doesn't change in the body of the method then x == abc at the end of the method. Conceptually the semantics are more like value types; in particular equality is based on state rather than identity. This means that abc == ab + c . While this doesn't require immutability the fact that a reference to such a string will always equal abc throughout its lifetime (which does require immutability) makes uses as keys where maintaining equality to previous values is vital much easier to ensure correctness of (strings are indeed commonly used as keys). Conceptually it can make more sense to be immutable. If we add a month onto Christmas we haven't changed Christmas we have produced a new date in late January. It makes sense therefore that Christmas.AddMonths(1) produces a new DateTime rather than changing a mutable one. (Another example if I as a mutable object change my name what has changed is which name I am using Jon remains immutable and other Jons will be unaffected. Copying is fast and simple to create a clone just return this . Since the copy can't be changed anyway pretending something is its own copy is safe. [Edit I'd forgotten this one]. Internal state can be safely shared between objects. For example if you were implementing list which was backed by an array a start index and a count then the most expensive part of creating a sub-range would be copying the objects. However if it was immutable then the sub-range object could reference the same array with only the start index and count having to change with a very considerable change to construction time.