[第1篇] 使用线程
在之前章节，我们已经讨论过线程在开发多用户应用程序时扮演的重要角色。我们已经使用线程来解决一些重要的问题，比如让多个用户或者客户端在同一时间访问同一个资源。然而，在学习过程中我们忽略了一个问题，现在到了处理这个问题的时候了：如果一个用户改变了资源的状态，同时另外一个用户也想改变同一个资源的状态的话，会发生什么？
[第2篇] .NET 对同步的支持
.NET Framework 提供了很多System.Threading,System.EnterpriseService 和 System.Runtime.Compiler 命名空间中的很多类来帮助程序员开发线程安全代码。
[第3篇] .NET 同步策略
公共语言架构提供了三种策略来同步访问实例和静态方法以及实例属性，这三种策略是：同步上下文、同步代码区域以及手动同步。
[第4篇] Monitor.Enter() 和 Monitor.Exit()
.NET Framework 中的每个对象都提供一个允许自己进入等待状态的机制。与锁的机制类似，这种机制的主要目的是为了实现线程间通信。当一个线程进入到一个对象的关键部分且需要一个特定条件并假设另外一个线程将会在同样的关键区域中创建条件时这种机制才会发生。
[第5篇] Monitor.Wait() 和 Monitor.Pulse()
Wait() 和 Pulse() 机制用于线程间交互。当在一个对象上使用Wait() 方法时，访问这个对象的线程就会一直等待直到被唤醒。Pulse() 和 PulseAll() 方法用来通知等待的线程醒来的。
[第6篇] Monitor.TryEnter()
Monitor 类的TryEnter() 方法在尝试获取一个对象上的显式锁方面和 Enter() 方法类似。然而，它不像Enter()方法那样会阻塞执行。如果线程成功进入关键区域那么TryEnter()方法会返回true。
[第7篇] ReaderWriterLock 类
一个ReaderWriterLock 类定义一个实现单写多读语义的锁。这个类通常用在能被多个线程读取但是仅能被一个线程写入的文件操作时使用。
[第8篇] 手动同步
第三种同步策略关注手动同步技术，.NET Framework 提供了一个经典的技术套件。他们给了程序员使用类似WIN32线程API的底层线程API来创建和管理多线程应用程序的能力。
[第9篇] AutoResetEvent, Mutex & Interlocked
AutoResetEvent类的工作方式与ManualResetEvent类似。它会等超时事件发生或者信号事件发生然后通知正在等待的线程。ManualResetEvent和AutoResetEvent之间最重要差别之一是AutoResetEvent在WaitOne()方法执行完会改变自身状态。
[第10篇] 小心死锁
尽管使用线程同步对线程安全来说是必须的，但是如果没有用好的话就可能导致死锁。因此，理解什么是死锁并知道如何避免死锁是非常重要的。当两个或两个以上的线程等待两个或多于两个锁被释放然后程序中的逻辑导致锁永远都不会被释放时死锁就发生了。
[第11篇] 创建线程安全的包装器(实战篇)
实现自己的线程安全包装器主要基于你可能不想让类库中的每个类都是线程安全的，而使用同步也会带来性能问题的事实。你可能想要为开发人员提供一个是否使用一个同步类的选择。由于开发人员既不想发生死锁也不想发生由于在一个单线程环境中使用线程安全类而导致的性能问题，他们可能更倾向于为类库中相同的类使用内建同步包装器而不是为每个类分别实现一个。
[第12篇] 实现一个数据库连接池(实战篇)
在企业级软件开发过程中，为了改善应用程序的性能需要通常使用对象池来控制对象的实例化。例如，在我们每次需要连接一个数据库时都需要创建一个数据库连接，而数据库连接是非常昂贵的对象。所以，为了节省为每次数据库调用都实例化一个数据库连接的资源，我们可以缓存并重用一些创建好的数据库连接对象并通过节省为每次数据库调用都创建一个数据库连接对象的时间和资源来大幅度提高程序性能。