为什么.Net框架类中的静态方法始终是线程安全的？

Question

I have noticed the following statement in most places of .Net framework documentation.

Question : What is the secret to this? I don't think a static class is always thread-safe. My question relates to standard classes that are available in .Net framework, and not the custom classes created by developers.

Would the method 'GetString' in static class below be thread-safe just because the method is a static method?

public static class MyClass
{
    static int x = 0;

    static MyClass()
    {
        x = 23;
    }

    public static string GetString()
    {
        x++;
        return x.ToString();
    }
}

Answer 1

The framework methods you mention are not thread-safe just from the fact they are static, but because they have been specifically designed to be thread-safe. Thread-safety is often hard to achieve, but it's usually necessary for static methods, since any state they mutate is shared between threads.

The sample method you posted isn't thread-safe, because it mutates state that is shared between threads, without any synchronization mechanism.

Answer 2

The easiest way to use a non-threadsafe instance method without any threading problems is to have that instance only visible to one thread (just don't put a reference to it in a static or anywhere else where a thread other than that which created it is going to access it). Indeed, this happens more than 90% of the time without any special effort to do so.

The second easiest is to associate a lock object with the instance (whether by using it as the lock object, or having a fields for both it and the lock object within the same scope) and making sure all access locks correctly.

With a static method we don't have these option, because there is no such instance and any thread could potentially call either it or another static method that clashes at any time. It may not even be from code by the same author. We also can't guarantee that other code uses the lock object(s) we have in place for use with it.

So for this reason a static method that is not threadsafe is of very limited use; pretty much only applicable to private static methods used in very limited cases, with these limitations providing the guarantee that it is only called by one thread at a time.

Hence with all public static methods one would make sure they are threadsafe (or else be very clear in documenting both that they are not threadsafe, and the justification for such a strange thing to do).

In fact, you'll find that a great many instance methods documented as "not threadsafe" actually are. The reasons they're listed as "not threadsafe" are:

1. If the author hasn't gone to the length of confirming their thread-safety, they'd better not claim what they aren't 100% sure about.
2. Being wrong in this direction is safe; the worse thing that happens is that someone adds their own synchronisation to add thread-safety they didn't need to, which won't actually break anything.
3. Since they haven' documented the method as threadsafe they are free to change to a non-threadsafe approach in a later version.

Answer 3

The specific examples you are referring to are designed to be thread safe. That is they allow concurrent access without deadlocks or race conditions.

This may not be the case in all instances of all classes, as such Microsoft have chosen to explicitly state which methods are thread safe and which are not to avoid any ambiguity.

See the final paragraph - .NET Class Library

All public static members (methods, properties, fields, and events) within the .NET Framework support concurrent access within a multithreaded environment. Therefore, any .NET Framework static member can be simultaneously invoked from two threads without encountering race conditions, deadlocks, or crashes.

For all classes and structures in the .NET Framework, check the Thread Safety section in the API reference documentation to determine whether it is thread safe. If you want to use a class that is not thread-safe in a multithreaded environment, you must wrap an instance of the class with code that supplies the necessary synchronization constructs.