与局部变量不同，静态变量不会自动进行线程限制。

如果程序中有静态变量，则必须提出一个论点，即只有一个线程会使用它们，并且必须清楚地记录这一事实。更好的是，您应该完全消除静态变量。

这是一个例子：

// This class has a race condition in it.
public class PinballSimulator {private static PinballSimulator simulator = null;// invariant: there should never be more than one PinballSimulator//            object createdprivate PinballSimulator() {System.out.println("created a PinballSimulator object");}// factory method that returns the sole PinballSimulator object,// creating it if it doesn't existpublic static PinballSimulator getInstance() {if (simulator == null) {simulator = new PinballSimulator();}return simulator;}
}

此类在getInstance()方法中存在竞争–两个线程可以同时调用它并最终创建PinballSimulator对象的两个副本，而这是我们不想要的。

要使用线程限制方法解决此问题，您可以指定仅允许调用某个线程（也许是“弹球模拟线程”）PinballSimulator.getInstance()。这里的风险是Java不能帮助您保证这一点。

通常，静态变量具有很高的并发风险。他们可能躲在似乎没有副作用或突变的无害功能后面。考虑以下示例：

// is this method threadsafe?
/*** @param x integer to test for primeness; requires x > 1* @return true if x is prime with high probability*/
public static boolean isPrime(int x) {if (cache.containsKey(x)) return cache.get(x);boolean answer = BigInteger.valueOf(x).isProbablePrime(100);cache.put(x, answer);return answer;
}private static Map<Integer,Boolean> cache = new HashMap<>();

此功能存储先前调用的答案，以防再次请求。这项技术称为“记忆化”，它是对诸如精确素数测试之类的缓慢功能的明智优化。但是现在isPrime从多个线程调用该方法并不安全，其客户端甚至可能没有意识到。原因是所有对的调用都共享HashMap静态变量引用的内容，并且不是线程安全的。如果有多个线程通过调用同时更改地图，则地图可能会以与上次读取中银行帐户损坏相同的方式损坏。如果您很幸运，损坏可能会导致哈希图中的异常，例如a或cacheisPrime()HashMapcache.put()Null­Pointer­ExceptionIndex­OutOfBounds­Exception。但是，正如我们在银行帐户示例中看到的那样，它也可能会悄悄地给出错误的答案。

因此，为了确信不可变数据类型是没有锁的线程安全的，我们需要对不可变性进行更严格的定义：

• 没有变异器方法
• 所有字段均为私有且为最终字段
• 没有代表性的曝光
• 代表中没有可变对象的任何突变-甚至没有善意的突变

如果遵循这些规则，那么您可以确信您的不可变类型也将是线程安全的。

Java中的集合接口- ，，List -有没有线程的基本实现。你已经习惯使用，即这些的实现，以及不能安全地从多个线程使用。SetMapArrayListHashMapHashSet

幸运的是，就像Collections API提供了使包装不可变的包装器方法一样，它提供了另一套包装器方法来使收藏夹具有线程安全性，同时仍然是可变的。

这些包装器有效地使集合的每种方法都相对于其他方法具有原子性。一个原子操作发生的事却一下子-它不与其他行动的交错其内部运作，并没有一个行动的效果对其它线程可见，直到整个动作完成，所以它永远不会看起来部分完成。

现在，我们看到了一种解决isPrime()方法，该方法可以解决我们在阅读本文之前的方法：

private static Map<Integer,Boolean> cache =Collections.synchronizedMap(new HashMap<>());

这里有几点。

不要绕过包装纸。确保丢弃对底层非线程安全集合的引用，并仅通过同步包装器对其进行访问。由于新代码HashMap只会传递给synchronizedMap()其他地方，而不会存储在其他任何地方，因此上述代码行会自动发生这种情况。（我们在不可修改的包装器上也看到了同样的警告：底层集合仍然是可变的，引用它的代码可以规避不变性。）

迭代器仍然不是线程安全的。尽管集合本身（方法调用get()，put()，add()等）现在是线程安全的，从集合创建迭代器仍然没有线程安全的。因此，您不能使用iterator()或for循环语法：

for (String s: lst) { ... } // not threadsafe, even if lst is a synchronized list wrapper

解决此迭代问题的方法是在需要迭代集合时获取它的锁，我们将在以后的阅读中讨论它。

最后，原子操作还不足以防止竞争：使用同步集合的方式仍然会存在竞争条件。考虑以下代码，该代码检查列表是否至少包含一个元素，然后获取该元素：

if ( ! lst.isEmpty()) { String s = lst.get(0); ... }

即使您lst进入一个同步列表，该代码仍然可能具有竞争条件，因为另一个线程可能会删除该isEmpty()调用和该get()调用之间的元素。

甚至该isPrime()方法仍然有潜在的竞争：

if (cache.containsKey(x)) return cache.get(x);
boolean answer = BigInteger.valueOf(x).isProbablePrime(100);
cache.put(x, answer);

同步映射确保了containsKey()，get()和put()现在原子，所以使用它们从多个线程不会损坏地图的Rep不变。但是，这三个操作现在可以以任意方式相互交错，这可能会破坏isPrime高速缓存所需的不变性：如果高速缓存将整数x映射到值f，则当且仅当f为true时，x才是质数。如果缓存使该不变式失败，那么我们可能会返回错误的结果。

因此，我们必须认为，之间的比赛containsKey()，get()和put()不威胁这个不变。

1. containsKey()和之间的竞争get()是无害的，因为我们从不从缓存中删除项目-一旦它包含x的结果，它将继续这样做。
2. containsKey()和之间有一场比赛put()。结果，可能最终两个线程将同时测试同一x的素数，并且两个都将竞相调用put()该答案。但是他们两个都应该put()用相同的答案跟注，因此哪个人赢得比赛无关紧要-结果将是相同的。

即使在使用线程安全数据类型时，也需要对安全性进行这类仔细的辩论，这是导致并发困难的主要原因。

让我们看一些关于如何为数据类型创建线程安全参数的示例。记住我们的四种线程安全方法：限制，不变性，线程安全数据类型和同步。由于我们在本阅读中没有讨论同步，因此我们仅关注前三种方法。

当我们仅针对数据类型进行参数传递时，通常不选择限制，因为您必须知道系统中存在哪些线程以及已授予它们访问哪些对象。如果数据类型创建了自己的线程集，那么您可以谈论关于这些线程的限制。否则，线程从外部进入，进行客户端调用，并且数据类型可能无法保证哪个线程引用了什么。因此，在那种情况下，限制不是有用的论据。通常，我们在更高级别上使用限制，讨论整个系统并争论为什么某些模块或数据类型不需要线程安全，因为它们不会按设计在线程之间共享。

不变性通常是一个有用的论据：

/** MyString is an immutable data type representing a string of characters. */
public class MyString {private final char[] a;// Thread safety argument://    This class is threadsafe because it's immutable://    - a is final//    - a points to a mutable char array, but that array is encapsulated//      in this object, not shared with any other object or exposed to a//      client

/** MyString is an immutable data type representing a string of characters. */
public class MyString {private final char[] a;private final int start;private final int len;// Rep invariant://    0 <= start <= a.length//    0 <= len <= a.length-start// Abstraction function://    represents the string of characters a[start],...,a[start+length-1]// Thread safety argument://    This class is threadsafe because it's immutable://    - a, start, and len are final//    - a points to a mutable char array, which may be shared with other//      MyString objects, but they never mutate it//    - the array is never exposed to a client

请注意，由于此MyStringrep是为在多个MyString对象之间共享数组而设计的，因此我们必须确保共享不会威胁其线程安全。只要它不威胁MyString的不变性，我们就可以确信它不会威胁线程的安全性。

我们还必须避免代表接触。Rep公开对于任何数据类型都是有害的，因为它威胁到数据类型的rep不变式。线程安全也很致命。

这是一些关于线程安全的错误参数：

/** MyStringBuffer is a threadsafe mutable string of characters. */
public class MyStringBuffer {private String text;// Rep invariant://   none// Abstraction function://   represents the sequence text[0],...,text[text.length()-1]// Thread safety argument://   text is an immutable (and hence threadsafe) String,//   so this object is also threadsafe

为什么这种论点行不通？字符串确实是不可变的并且是线程安全的。但是指向该字符串（特别是text变量）的代表不是不可变的。 text是不是最终的变数，而事实上它不可能是最终在这个数据类型，因为我们需要的数据类型来支持插入和删除操作。因此，text变量本身的读取和写入不是线程安全的。这个说法是错误的。

这是另一个破裂的论点：

public class Graph {private final Set<Node> nodes =Collections.synchronizedSet(new HashSet<>());private final Map<Node,Set<Node>> edges =Collections.synchronizedMap(new HashMap<>());// Rep invariant://    for all x, y such that y is a member of edges.get(x),//        x, y are both members of nodes// Abstraction function://    represents a directed graph whose nodes are the set of nodes//        and whose edges are the set (x,y) such that//                         y is a member of edges.get(x)// Thread safety argument://    - nodes and edges are final, so those variables are immutable//      and threadsafe//    - nodes and edges point to threadsafe set and map data types

这是一种图形数据类型，将其节点存储在集合中，并将其边缘存储在地图中。（快速测验：是Graph可变的还是不可变的数据类型？final关键字与它的可变性有什么关系？）Graph依赖于其他线程安全的数据类型来帮助其实现rep –特别是我们上面所讨论的线程安全Set和Map包装器。这阻止了某些竞争条件，但不是全部，因为图形的rep不变量包括节点集和边缘贴图之间的关系。出现在边缘贴图中的所有节点也必须出现在节点集中。所以可能有这样的代码：

public void addEdge(Node from, Node to) {if ( ! edges.containsKey(from)) {edges.put(from, Collections.synchronizedSet(new HashSet<>()));}edges.get(from).add(to);nodes.add(from);nodes.add(to);
}

该代码中包含竞争条件。有一个关键时刻，就是在edges映射发生变异后，但在nodes集合发生变异之前，就违反了rep不变式。图上的另一个操作可能会在此时交织，发现rep不变式已损坏，并返回错误的结果。即使线程安全的set和map数据类型保证其自身add()和put()方法是原子的且互不干扰，它们也不能将该保证扩展到两个数据结构之间的交互。因此，rep不变式在Graph种族条件下并不安全。当rep不变式取决于rep中对象之间的关系时，仅使用不可变和线程安全可变数据类型是不够的。

我们将不得不通过同步来解决此问题，我们将在以后的阅读中看到如何解决。

再次查看上述练习的代码。我们可能还会担心clear并insert可能交错，以使客户看到clear违反其后置条件。

假设两个线程共享MyStringBuffer sb表示"z"。他们运行clear和insert在如右图所示兼任。

线程A的声明将失败，但不是因为clear违反了它的后置条件。的确，当所有代码clear都已运行完毕时，后置条件就满足了。

真正的问题是线程A尚未预期到clear()和之间的可能的交织assert。对于任何可同时调用原子变异体的线程安全可变类型，某些变异必须作为最后一个应用来“获胜”。线程A观察到的结果与下面的执行相同，在这里执行器完全不交织：

我们对线程安全数据类型的要求是，当客户端同时调用其原子操作时，结果与这些调用的某些顺序保持一致。在这种情况下，清除并插入意味着-clear跟随-insert或-insert跟随- clear。此属性称为可序列化：对于同时执行的任何一组操作，结果（客户端可观察的值和状态）必须是由这些操作的某些顺序给出的结果。