String Interning or why you shouldn’t use string in a lock statement.

 

Hi All,

Today I want to talk about a nice and relatively unmentioned feature of the .Net framework – string interning. I will start with a small riddle. What do you think is the output of the following application?

10. class Program
11. {
12.   static void Main(string[] args)
13.   {
14.     Task t0 = new Task(() => { PrintNumber(0); });
15.     Task t1 = new Task(() => { PrintNumber(1); });
16.     t0.Start();
17.     t1.Start();
18.     Task.WaitAll(t0, t1);
19.   }
20.  
21.   public static void PrintNumber(int number)
22.   {
23.     lock ("Monkey")
24.     {
25.       for (int i = 0; i < 10; i++)
26.       {
27.         Console.Out.Write(number);
28.         Thread.Sleep(200);
29.       }
30.     }
31.   }
32. }

If you said a series of 0s and then a series of 1s (or vise versa) then you are right. But why? When we lock the string “Monkey” shouldn’t the compiler create two instances of the this string (one per call)? This string is a local variable of the method.

As you probably know the String class in .Net is immutable which means that once an instance of this class is created it cannot be edited in any way. Any operation that changes the content of the string will always create a new instance of the string, this instance reflects the changes done on the original string. This behavior is not cemented using some sort of a language directive and is more of a “word of mouth”, an agreements if you wish, between the framework and the coders. Nevertheless, this immutability allows the .Net framework to treat the string in a special way. If the compiler can infer the string content at compile time it will not be allocated on the local heap. It will be allocated on the System Appdomain and added to an interning hash table on the System Domain (called the intern pool). Every time a string is created the framework will search the intern pool to check if an instance of this string already exists and if so it will return a reference to that instance. Note that this would happen automatically only to strings which the compiler can infer during compilation but you can force a string to enter the intern pool by using the String.Intern method.

Here is a simple program to list some interesting cases of string interning:

10. static void Main(string[] args)
11.     {
12.       string s1 = "Hello World";
13.       string s2 = "Hello World";
14.       string s3 = s2;
15.       StringBuilder sb1 = new StringBuilder(s1);
16.       string s4 = sb1.ToString();
17.       string s5 = string.Intern(s4);
18.       string s6 = s1.Clone() as string;
19.       
20.  
21.       Console.Out.WriteLine(String.Format("s1 == s2 - {0}", s1 == s2));
22.       Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s2) - {0}", Object.ReferenceEquals(s1, s2)));
23.       Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s3) - {0}", Object.ReferenceEquals(s1, s3)));
24.       Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s4) - {0}", Object.ReferenceEquals(s1, s4)));
25.       Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s5) - {0}", Object.ReferenceEquals(s1, s5)));
26.       Console.Out.WriteLine(String.Format("Object.ReferenceEquals(s1,s6) - {0}", Object.ReferenceEquals(s1, s6)));
27.  
28.       StringBuilder sb2 = new StringBuilder();
29.       for (int i = 0; i < 20000; i++)
30.         sb1.Append("a");
31.  
32.       string[] strings = new string[2];
33.       for (int i = 0; i < 2; i++)
34.       {
35.         strings[i] = String.Intern(sb1.ToString());
36.       }
37.  
38.       
39.       Console.Out.WriteLine(String.Format("(s1,s6) - {0}", Object.ReferenceEquals(strings[0],strings[1])));
40.  
41.     }

And the output is:

s1 == s2 - True
Object.ReferenceEquals(s1,s2) - True
Object.ReferenceEquals(s1,s3) - True
Object.ReferenceEquals(s1,s4) - False
Object.ReferenceEquals(s1,s5) - True
Object.ReferenceEquals(s1,s6) - True
(s1,s6) – True

Couple of thigs to notice:

1. String operations that do not change the string (such as Clone or ToString) will return the same instance.
2. If an interend string is allocated on the System Appdomain it will never be released (Only when the CLR is terminated)
3. StringBuilder will always generate a new instance of a string (the compiler can’t infer what the StringBuilder contains).

I am not sure where interning can actually help (although I heard that there are some use cases in ASP.NET where this behavior is benefitial) but you should be aware that it exist and never use a string in a lock statement. Who knows where this string comes from

This is what MSDN has to say about the lock statement :

lock("myLock") is a problem because any other code in the process using the same string, will share the same lock.

I hope now you understand why.

 

I want to thank Ilya Kosaev for helping me with this blog post.

Thanks for reading,

Boris.