作者解释为什么DateTime.Now需要线程安全：
Wrapping access to an object around a custom lock works only if all
concurrent threads are aware of — and use — the lock. This may not be
the case if the object is widely scoped. The worst case is with static
members in a public type. For instance,imagine if the static property
on the DateTime struct,DateTime.Now,was not thread-safe,and that
two concurrent calls could result in garbled output or an exception.
The only way to remedy this with external locking might be to lock the
type itself — lock(typeof(DateTime)) — before calling DateTime.Now.
This would work only if all programmers agreed to do this (which is
unlikely). Furthermore,locking a type creates problems of its own.For this reason,static members on the DateTime struct have been
carefully programmed to be thread-safe.
根据MS文档,.NOW是public static DateTime Now {get; },即只读属性.
为什么麻烦线程安全,如果它是只读的？两个并发呼叫应该能够获得当前时间而不会相互干扰？
编辑：很多人,指出问题不是很清楚.
我确实做了一个假设,它应该是安全的,因为：它是只读的,因为它是时间(总是改变).
解决方法
但是,我们来看看所有的静态场景.静态需要固有线程安全,因为如果它们有任何状态,它是有效的全局性的(因此需要线程安全),并且方法/属性的任何调用者将无法将该数据本地化,因此不需要担心线程安全.即呼叫者将无法使其线程安全可靠,因为没有其他代码可能知道该代码如何使其线程安全,因此真的不能线程安全.
例如,假设这个虚构的DateTime.Now已经被执行了(很差),如下所示：
private static long ticks;
public static DateTime Now
{
get
{
ticks = UnsafeMethods.GetSystemTimeAsFileTime()
return new DateTime(ticks);
}
}
…因为ticks很长,它不会在32位模式下是原子的.因此,对共享刻度的分配需要同步.约瑟说你不能这样做：
lock(somelock)
{
var now = DateTime.Now;
}
因为任何其他代码可以自由地做到这一点：
var now = DateTime.Now;
…所以你的锁没有什么可以让它线程安全.
