注意，这个解决方法依赖于线程 2 对其所需的独占资源的固执占有和线程 1 愿意“屈服”作出让步，让线程 2 总是优先执行。同时注意，线程 1 在锁定 resourceA 后，由于争夺不到 resourceB，作出了让步，把已占有的 resourceA 释放掉后，就必须等线程 2 使用完 resourceA 重新锁定 resourceA 再重做工作。
正因为线程 2 总是优先，所以，如果线程 2 占用 resourceA 或 resourceB 的频率非常高（比如外面再嵌套一个类似 while(true) 的循环 ），那么就可能导致线程 1 一直无法获得所需要的资源，这种现象叫线程饥饿，是由高优先级线程吞噬低优先级线程 CPU 执行时间的原因造成的。线程饥饿除了这种的原因，还有可能是线程在等待一个本身也处于永久等待完成的任务。
我们可以继续开个脑洞，上面示例中，如果线程 2 也愿意让步，会出现什么情况呢？
活锁的发生和避免我们把上面示例改造一下，使线程 2 也愿意让步：
public void Thread1DoWork() { bool mustDoWork = true; Thread.Sleep(100); while (mustDoWork) { lock (resourceA) { Console.WriteLine("T1 重做"); Thread.Sleep(1000); if (Monitor.TryEnter(resourceB, 0)) { output += "T1#"; mustDoWork = false; Monitor.Exit(resourceB); } } if (mustDoWork) Thread.Yield(); } } public void Thread2DoWork() { bool mustDoWork = true; Thread.Sleep(100); while (mustDoWork) { lock (resourceB) { Console.WriteLine("T2 重做"); Thread.Sleep(1100); if (Monitor.TryEnter(resourceA, 0)) { output += "T2#"; mustDoWork = false; Monitor.Exit(resourceB); } } if (mustDoWork) Thread.Yield(); } }注意，为了使我要演示的效果更明显，我把两个线程的 Thread.Sleep 时间拉开了一点点。运行后的效果如下：
通过观察运行效果，我们发现线程 1 和线程 2 一直在相互让步，然后不断重新开始。两个线程都无法进入 Monitor.TryEnter 代码块，虽然都在运行，但却没有真正地干活。
我们把这种线程一直处于运行状态但其任务却一直无法进展的现象称为活锁。活锁和死锁的区别在于，处于活锁的线程是运行状态，而处于死锁的线程表现为等待；活锁有可能自行解开，死锁则不能。
要避免活锁，就要合理预估各线程对独占资源的占用时间，并合理安排任务调用时间间隔，要格外小心。现实中，这种业务场景很少见。示例中这种复杂的资源占用逻辑，很容易把人搞蒙，而且极不容易维护。推荐的做法是使用信号量机制代替锁，这是另外一个话题，后面单独写文章讲。
总结我们应该避免多线程同时读写共享数据，避免的方式，最简单的就是加锁，把共享数据作为独占资源来进行排它使用。
多个线程在一次任务中需要对多个独占资源加锁时，就可能因相互循环等待而出现死锁。要避免死锁，就至少得有一个线程作出让步。即，在发现自己需要的资源得不到满足时，就要主动释放已占有的资源，以让别的线程可以顺利执行完成。
大部分情况安排一个线程让步便可避免死锁，但在复杂业务中可能会有多个线程互相让步的情况造成活锁。为了避免活锁，需要合理安排线程任务调用的时间间隔，而这会使得业务代码变得非常复杂。更好的做法是放弃使用锁，而换成使用信号量机制来实现对资源的独占访问。