这就是中文msdn

这是中文的msdn来自ms-help://MS.MSDNQTR.v80.chs/MS.MSDN.v80/MS.VisualStudio.v80.chs/dv_fxadvance/html/e51988e7-7f4b-4646-a06d-1416cee8d557.htm

一般性建议

使用多线程时要考虑以下准则：

• 不要使用 Thread.Abort 终止其他线程。对另一个线程调用 Abort 无异于引发该线程的异常，也不知道该线程已处理到哪个位置。

• 不要使用 Thread.Suspend 和 Thread.Resume 来同步多个线程的活动。不要使用 Mutex、ManualResetEvent、AutoResetEvent 和 Monitor。

• 不要从主程序中控制辅助线程的执行（如使用事件），而应在设计程序时让辅助线程负责等待任务，执行任务，并在完成时通知程序的其他部分。如果辅助线程不阻止，请考虑使用线程池线程。Monitor.PulseAll 在辅助线程阻止的情况下会很有用。

• 一定要确保已进入监视器的线程始终离开该监视器，即使当线程在监视器中时发生异常也是如此。C# 的 lock 语句和 Visual Basic 的 SyncLock 语句可自动提供此行为，它们用一个 finally 块来确保调用 Monitor.Exit。如果无法确保调用 Exit，请考虑将您的设计更改为使用 Mutex。Mutex 在当前拥有它的线程终止后会自动释放。

• 一定要针对那些需要不同资源的任务使用多线程，避免向单个资源指定多个线程。例如，任何涉及 I/O 的任务都会从其拥有其自己的线程这一点得到好处，因为此线程在 I/O 操作期间将阻止，从而允许其他线程执行。用户输入是另一种可从专用线程获益的资源。在单处理器计算机上，涉及大量计算的任务可与用户输入和涉及 I/O 的任务并存，但多个计算量大的任务将相互竞争。

请参见

再看看英文的

General Recommendations

Consider the following guidelines when using multiple threads:

• Don't use Thread.Abort to terminate other threads. Calling Abort on another thread is akin to throwing an exception on that thread, without knowing what point that thread has reached in its processing.

• Don't use Thread.Suspend and Thread.Resume to synchronize the activities of multiple threads. Do use Mutex, ManualResetEvent, AutoResetEvent, and Monitor.

• Don't control the execution of worker threads from your main program (using events, for example). Instead, design your program so that worker threads are responsible for waiting until work is available, executing it, and notifying other parts of your program when finished. If your worker threads do not block, consider using thread pool threads. Monitor.PulseAll is useful in situations where worker threads block.

• Don't use types as lock objects. That is, avoid code such as lock(typeof(X)) in C# or SyncLock(GetType(X)) in Visual Basic, or the use of System.Threading.Monitor.Enter(System.Object) with Type objects. For a given type, there is only one instance of System.Type per application domain. If the type you take a lock on is public, code other than your own can take locks on it, leading to deadlocks. For additional issues, see Reliability Best Practices.

• Use caution when locking on instances, for example lock(this) in C# or SyncLock(Me) in Visual Basic. If other code in your application, external to the type, takes a lock on the object, deadlocks could occur.

• Do ensure that a thread that has entered a monitor always leaves that monitor, even if an exception occurs while the thread is in the monitor. The C# lock statement and the Visual Basic SyncLock statement provide this behavior automatically, employing a finally block to ensure that Monitor.Exit is called. If you cannot ensure that Exit will be called, consider changing your design to use Mutex. A mutex is automatically released when the thread that currently owns it terminates.

• Do use multiple threads for tasks that require different resources, and avoid assigning multiple threads to a single resource. For example, any task involving I/O benefits from having its own thread, because that thread will block during I/O operations and thus allow other threads to execute. User input is another resource that benefits from a dedicated thread. On a single-processor computer, a task that involves intensive computation coexists with user input and with tasks that involve I/O, but multiple computation-intensive tasks contend with each other.

• Consider using methods of the Interlocked class for simple state changes, instead of using the lock statement (SyncLock in Visual Basic). The lock statement is a good general-purpose tool, but the Interlocked class provides better performance for updates that must be atomic. Internally, it executes a single lock prefix if there is no contention. In code reviews, watch for code like that shown in the following examples. In the first example, a state variable is incremented: