Review代码发现有一个方法加了[MethodImpl(MethodImplOptions.Synchronized)] 属性，这个属性的目的，从名字上就可以看出，是要对所有线程进行同步执行。
对方法加上这个属性之后，会把整个方法体加在一个同步块中，比如下面的代码：
[MethodImpl(MethodImplOptions.Synchronized)] public static void syncDemo() { if (count % 10 != 0) { Thread.Sleep(50); count++; } }
其实和下面的代码是一样的（SyncMethodCls是包含这个方法的类）：
public static void lockDemo() { lock (typeof(SyncMethodCls)) { if (count % 10 != 0) { Thread.Sleep(50); count++; } } }
从第二个方法中，可以看到使用[MethodImpl(MethodImplOptions.Synchronized)]这个属性是对整个类型进行加锁的，同步块是整个方法。如果这个类中只有一个静态同步方法还好，如果有两个同步静态方法都使用这个属性进行标注，这两个方法之间就会出现竞态，在一些情况下，你可能并不想让两个不是很相关的方法出现竞态的情况。同一个类型中越多这种静态同步方法，出现的竞争越激励，系统性能也会越差。
上面也说了，使用这个属性之后，是对整个方法进行同步，但是有时候有些条件判断并不需要放在同步块中，比如上面方法中的if 条件，我并不想放到同步块中，因为有时候已经满足条件的线程就不需要再次阻塞了。这种情况在单例中最明显了，首先判断单例的实例是否为空，只有为空的时候，才会去加锁重新生成一个新的实例。
以上方法可以参考单例进行改造，改造后的代码如下：
private static object syncObj = new object(); public static void syncObjDemo() { if (count % 10 !=0) { lock(syncObj) { if (count % 10 != 0) { Thread.Sleep(50); count++; } } } }
改造之后，竞争数量明显减少。
下面附上使用[MethodImpl(MethodImplOptions.Synchronized)]竞争情况：
改造之后的竞争情况：
多线程调用情况如下：
for (int i = 0; i <= 1000; i++) { ThreadPool.QueueUserWorkItem((t) => { // syncMethodCls.syncDemo(); syncMethodCls.syncObjDemo(); }); }
到此，需要好好说说这个[MethodImpl(MethodImplOptions.Synchronized)]了，MSDN上这样解释：“该方法一次性只能在一个线程上执行。 静态方法在类型上锁定，而实例方法在实例上锁定。 只有一个线程可在任意实例函数中执行，且只有一个线程可在任意类的静态函数中执行。” 总结一句话就是：静态方法锁整个类，实例方法锁整个实例。这句话乍一看挺吓人的，但是如果你的类中只有一个同步方法的话，锁整个类和整个实例影响也不大，但是要确保类和实例在其他地方不会再次被锁，否则会造成死锁的。
所以这个属性，还是尽量不要使用了，不光有可能造成性能问题不说，还有可能造成死锁的严重问题。
说到锁整个类，最近看java多线程的部分，java中有个和C#的lock类似的同步关键字synchronized，好多例子都是直接在方法上加这个关键字，实现方法的同步实现。这个关键字实现的方式应该类似MethodImplOptions.Synchronized，静态方法锁类型，实例方法锁实例，而且如果有条件判断可能还会造成不必要的阻塞。而且由于jdk对synchronized的不断优化，在有些时候并不会马上进行加锁，而是会先自旋一会（以通过浪费CPU时间减少阻塞），可能在某些时候造成CPU时间片的浪费。所以使用的时候，也需要注意。