您并不总是希望丢弃竞态条件。如果你有一个可以被多个线程读写的标志，并且这个标志被一个线程设置为“done”，这样当标志被设置为“done”时，其他线程就会停止处理，你不希望这个“竞争条件”被消除。事实上，这可以被称为良性竞态条件。

然而，使用检测竞态条件的工具，它将被视为有害的竞态条件。

更多关于比赛情况的详细信息，请访问http://msdn.microsoft.com/en-us/magazine/cc546569.aspx。

Race conditions occur in multi-threaded applications or multi-process systems. A race condition, at its most basic, is anything that makes the assumption that two things not in the same thread or process will happen in a particular order, without taking steps to ensure that they do. This happens commonly when two threads are passing messages by setting and checking member variables of a class both can access. There's almost always a race condition when one thread calls sleep to give another thread time to finish a task (unless that sleep is in a loop, with some checking mechanism).

防止竞争条件的工具依赖于语言和操作系统，但一些常见的工具是互斥锁、临界区和信号。互斥锁在你想确保你是唯一一个在做某事的时候很有用。当你想确保别人已经完成某件事时，信号是很好的。最小化共享资源还有助于防止意外行为

Detecting race conditions can be difficult, but there are a couple signs. Code which relies heavily on sleeps is prone to race conditions, so first check for calls to sleep in the affected code. Adding particularly long sleeps can also be used for debugging to try and force a particular order of events. This can be useful for reproducing the behavior, seeing if you can make it disappear by changing the timing of things, and for testing solutions put in place. The sleeps should be removed after debugging.

但是，如果某个问题只在某些机器上断断续续地发生，则是存在竞争条件的标志性标志。常见的错误是崩溃和死锁。使用日志记录，您应该能够找到受影响的区域并从那里返回。

我做了一个视频来解释这个。

从本质上讲，它是当你有一个跨多个线程共享的状态，在一个给定状态的第一次执行完成之前，另一个执行开始，一个给定操作的新线程的初始状态是错误的，因为前一次执行还没有完成。

由于第二次执行的初始状态是错误的，因此计算结果也是错误的。因为最终第二次执行会用错误的结果更新最终状态。

你可以在这里查看。 https://youtu.be/RWRicNoWKOY

竞态条件是一种bug，只会在特定的时间条件下发生。

例子: 假设您有两个线程，A和B。

在线程A中:

if( object.a != 0 )
    object.avg = total / object.a

线程B:

object.a = 0

如果线程A在检查完对象后被抢占。a不为空，B将执行a = 0，当线程a将获得处理器时，它将执行“除零”。

这个错误只发生在if语句之后的线程A被抢占时，这是非常罕见的，但它是有可能发生的。

当访问共享资源的多线程(或其他并行)代码可能以导致意外结果的方式访问共享资源时，就存在“竞争条件”。

举个例子:

for ( int i = 0; i < 10000000; i++ )
{
   x = x + 1; 
}

如果你有5个线程同时执行这段代码，x的值最终不会是50,000,000。事实上，它会随着每一次运行而变化。

这是因为，为了让每个线程增加x的值，它们必须做以下事情:(显然是简化的)

Retrieve the value of x
Add 1 to this value
Store this value to x

任何线程都可以在任何时间处于此进程的任何步骤，并且当涉及共享资源时，它们可以相互踩。在读取x和写回x之间的时间内，x的状态可以由另一个线程改变。

假设一个线程获取了x的值，但还没有存储它。另一个线程也可以检索相同的x值(因为还没有线程更改它)，然后它们都将在x中存储相同的值(x+1) !

例子:

Thread 1: reads x, value is 7
Thread 1: add 1 to x, value is now 8
Thread 2: reads x, value is 7
Thread 1: stores 8 in x
Thread 2: adds 1 to x, value is now 8
Thread 2: stores 8 in x

竞争条件可以通过在代码访问共享资源之前使用某种锁定机制来避免:

for ( int i = 0; i < 10000000; i++ )
{
   //lock x
   x = x + 1; 
   //unlock x
}

这里，答案每次都是50,000,000。

有关锁的更多信息，请搜索:互斥量，信号量，临界区，共享资源。

如果你使用“原子”类，你可以防止竞争条件。原因是线程没有分开操作get和set，示例如下:

AtomicInteger ai = new AtomicInteger(2);
ai.getAndAdd(5);

因此，你将有7在链接“ai”。 虽然你做了两个操作，但这两个操作都确认了同一个线程，没有其他线程会干涉这，这意味着没有竞争条件!