1.2　并发应用程序中可能出现的问题

1.2　并发应用程序中可能出现的问题

编写并发应用程序并不是一件容易的工作。如果不能正确使用同步机制，应用程序中的任务就会出现各种问题。本节将介绍一些此类问题。

1.2.1　数据竞争

如果有两个或者多个任务在临界段之外对一个共享变量进行写入操作，也就是说没有使用任何同步机制，那么应用程序可能存在数据竞争（也叫作竞争条件）。

在这些情况下，应用程序的最终结果可能取决于任务的执行顺序。请看下面的例子。

package com.packt.java.concurrency;
public class Account {
  private float balance;
  public void modify (float difference) {
    float value=this.balance;
    this.balance=value+difference;
  }
}

假设有两个不同的任务执行了同一个Account对象中的modify()方法。由于任务中语句的执行顺序不同，最终结果也会有所不同。假设初始余额为1000，而且两个任务都调用了modify()方法并采用1000作为参数。最终的结果应该是3000，但是如果两个任务都在同一时间执行了第一条语句，然后又在同一时间执行了第二条语句，那么最终的结果将是2000。正如你看到的，modify()方法不是原子的，而Account类也不是线程安全的。

1.2.2　死锁

当两个（或多个）任务正在等待必须由另一线程释放的某个共享资源，而该线程又正在等待必须由前述任务之一释放的另一共享资源时，并发应用程序就出现了死锁。当系统中同时出现如下四种条件时，就会导致这种情形。我们将其称为Coffman条件。

互斥：死锁中涉及的资源必须是不可共享的。一次只有一个任务可以使用该资源。
占有并等待条件：一个任务在占有某一互斥的资源时又请求另一互斥的资源。当它在等待时，不会释放任何资源。
不可剥夺：资源只能被那些持有它们的任务释放。
循环等待：任务1正等待任务2所占有的资源，而任务2又正在等待任务3所占有的资源，以此类推，最终任务n又在等待由任务1所占有的资源，这样就出现了循环等待。

有一些机制可以用来避免死锁。

忽略它们：这是最常用的机制。你可以假设自己的系统绝不会出现死锁，而如果发生死锁，结果就是你可以停止应用程序并且重新执行它。
检测：系统中有一项专门分析系统状态的任务，可以检测是否发生了死锁。如果它检测到了死锁，可以采取一些措施来修复该问题，例如，结束某个任务或者强制释放某一资源。
预防：如果你想防止系统出现死锁，就必须预防Coffman条件中的一条或多条出现。
规避：如果你可以在某一任务执行之前得到该任务所使用资源的相关信息，那么死锁是可以规避的。当一个任务要开始执行时，你可以对系统中空闲的资源和任务所需的资源进行分析，这样就可以判断任务是否能够开始执行。

1.2.3　活锁

如果系统中有两个任务，它们总是因对方的行为而改变自己的状态，那么就出现了活锁。最终结果是它们陷入了状态变更的循环而无法继续向下执行。

例如，有两个任务：任务1和任务2，它们都需要用到两个资源：资源1和资源2。假设任务1对资源1加了一个锁，而任务2对资源2加了一个锁。当它们无法访问所需的资源时，就会释放自己的资源并且重新开始循环。这种情况可以无限地持续下去，所以这两个任务都不会结束自己的执行过程。

1.2.4　资源不足

当某个任务在系统中无法获取维持其继续执行所需的资源时，就会出现资源不足。当有多个任务在等待某一资源且该资源被释放时，系统需要选择下一个可以使用该资源的任务。如果你的系统中没有设计良好的算法，那么系统中有些线程很可能要为获取该资源而等待很长时间。

要解决这一问题就要确保公平原则。所有等待某一资源的任务必须在某一给定时间之内占有该资源。可选方案之一就是实现一个算法，在选择下一个将占有某一资源的任务时，对任务已等待该资源的时间因素加以考虑。然而，实现锁的公平需要增加额外的开销，这可能会降低程序的吞吐量。

1.2.5　优先权反转

当一个低优先权的任务持有了一个高优先级任务所需的资源时，就会发生优先权反转。这样的话，低优先权的任务就会在高优先权的任务之前执行。

1.2 并发应用程序中可能出现的问题