String类中的线程安全性

Question

Is it thread safe to build strings from local variables using the String class like in the methods below? Suppose that the methods below are called from several threads.

public static string WriteResult(int value, string name)
{
    return string.Format("Result: value={0} name={1}", value, name);
}

public static string WriteResult2(int value, string name)
{
    return "Result: value=" + value + " name=" + name;
}

Or do I need to use StringBuilder to ensure thread safety?

Answer 1

That's absolutely fine. There is no shared state in either piece of code other than the string literals. As strings are immutable, it's fine for strings to be shared freely between threads, and both string.Format and string.Concat (implicitly called in the second piece of code) are thread-safe.

Even if one of the parameters were mutable and even if the method mutated the parameters, eg

public static void AddResult(int value, List<string> results)
{
    results.Add("Value " + value);
}

... then the method itself would still be thread-safe, so long as multiple threads didn't refer to the same List<string> . If multiple threads did refer to the same List<string> then it would be unsafe even if it just read from the list, as another thread could be mutating it.

Answer 2

Both int and string as parameters in this method are effectively immutable and cannot be changed by outside code.

So there is no need to care about thread-safety with either Format method or String.Concat in this case.

---

But let us assume that we have some class MyObject that is mutable and can be changed from outside:

public class MyClass
{
    public Int32 value1 { get; set; }
    public String value2 { get; set;}
} 

public static string WriteResult2(MyObject obj)
{
    return "Result: value=" + obj.value1 + " name=" + obj.value2 ;
}

In this case whether with first approach or second you can return inconsistent value (it both value1 and value2 are changed after one value is already put to output.)

As @JonSkeet pointed it is not actually the method itself that is unsafe, but the class itself is unsafe to be shared in such manner between different threads.

To handle this situation you will have to either create special thread-safe instance method:

public class MyClass
{
    private Object lockObj = new Object();
    public Int32 value1
    {
        get
        {
            lock (this.lockObj) { ... });
        }
        set
        {
            lock (this.lockObj) { ... });
        }
    }
    public String value2
    {
        get
        {
            lock (this.lockObj) { ... });
        }
        set
        {
            lock (this.lockObj) { ... });
        }
    }

    public string WriteResult2()
    {
        lock (this.lockObj)
        {
             return "Result: value=" + this.value1 + " name=" + this.value2 ;
        }
    }
} 

Or use some additional locking over such instances in methods that use it. The first in-class approach is obviously less error-prone, but may reduce performance and create a lot of boiler-plate code. Ideally, in concurrent programming the less you need to care about shared mutable state and its consistency the better .

Answer 3

Both methods are thread-safe, because it does not matter what you do inside WriteResult . As long as it does not use mutable static state, and its parameters cannot be changed from the outside, your static method is thread-safe.

It is easy to verify that the methods do not use static state. It is also easy to verify that method's parameters cannot be changed from outside:

• value cannot be changed, because it is of primitive type, and it is passed by value
• name cannot be changed, because string objects are immutable.