线程是编程中常用而且强大的手段，在使用过程中，我们经常面对的就是线程安全问题了。对于Java中常见的数据结构而言，一般的，ArrayList是非线程安全的，Vector是线程安全的；HashMap是非线程安全的，HashTable是线程安全的；StringBuilder是非线程安全的，StringBuffer是线程安全的。
然而，判断代码是否线程安全，不能够想当然，例如Java 中的构造函数是否是线程安全的呢？
自以为是
自己从第一感觉来看，构造函数应该是线程安全的，如果一个对象没有初始化完成，怎么可能存在竞争呢？ 甚至在Java 的语言规范中也谈到，没有必要将constructor 置为synchronized，因为它在构建过程中是锁定的，其他线程是不可能调用还没有实例化好的对象的。
但是，当我读过了Bruce Eckel 的博客文章，才知道构造函数并不是线程安全的，本文中的示例代码和解释全部来自Bruce Eckel 的那篇文章。
演示的过程从 定义一个接口开始：
// HasID.java
public interface HasID {
int getID();
}
有各种方法可以实现这个接口，先看看静态变量方式的实现：
// StaticIDField.java
public class StaticIDField implements HasID {
private static int counter = 0;
private int id = counter++;
public int getID() { return id; }
}
这是一个简单而无害的类，再构造一个用于并行调用的测试类：
// IDChecker.java
import java.util.*;
import java.util.function.*;
import java.util.stream.*;
import java.util.concurrent.*;
import com.google.common.collect.Sets;
public class IDChecker {
public static int SIZE = 100000;
static class MakeObjects
implements Supplier<List<Integer>> {
private Supplier<HasID> gen;
public MakeObjects(Supplier<HasID> gen) {
this.gen = gen;
}
@Override
public List<Integer> get() {
return
Stream.generate(gen)
.limit(SIZE)
.map(HasID::getID)
.collect(Collectors.toList());
}
}
public static void test(Supplier<HasID> gen) {
CompletableFuture<List<Integer>>
groupA = CompletableFuture
.supplyAsync(new MakeObjects(gen)),
groupB = CompletableFuture
.supplyAsync(new MakeObjects(gen));
groupA.thenAcceptBoth(groupB, (a, b) -> {
System.out.println(
Sets.intersection(
Sets.newHashSet(a),
Sets.newHashSet(b)).size());
}).join();
}
}
其中 MakeObjects 是一个 Supplier 通过get（）方法产生一个 List<Integer>. 这个 List 从 每个HasID 对象中得到一个ID。test() 方法创建了两个并行的CompletableFutures 来运行MakeObjects suppliers, 然后就每个结果使用Guava库的Sets.intersection() 来找出两个List<Integer>中有多少个共有的ID。现在，测试一下多个并发任务调用这个StaticIDField类的结果：
// TestStaticIDField.java
public class TestStaticIDField {
public static void main(String[] args) {
IDChecker.test(StaticIDField::new);
}
}
/* Output:
47643
*/
有大量的重复值，显然 static int 不是线程安全的，需要用AtomicInteger 尝试一下：
// GuardedIDField.java
import java.util.concurrent.atomic.*;
public class GuardedIDField implements HasID {
private static AtomicInteger counter =
new AtomicInteger();
private int id = counter.getAndAdd(1);
public int getID() { return id; }
public static void main(String[] args) {
IDChecker.test(GuardedIDField::new);
}
}
/* Output:
0
*/
通过构造函数的参数来共享状态同样是对线程安全敏感的：
// SharedConstructorArgument.java
import java.util.concurrent.atomic.*;
interface SharedArg {
int get();
}
class Unsafe implements SharedArg {
private int i = 0;
public int get() { return i++; }
}
class Safe implements SharedArg {
private static AtomicInteger counter =
new AtomicInteger();
public int get() {
return counter.getAndAdd(1);
}
}
class SharedUser implements HasID {
private final int id;
public SharedUser(SharedArg sa) {
id = sa.get();
}
@Override
public int getID() { return id; }
}
public class SharedConstructorArgument {
public static void main(String[] args) {
Unsafe unsafe = new Unsafe();
IDChecker.test(() -> new SharedUser(unsafe));
Safe safe = new Safe();
IDChecker.test(() -> new SharedUser(safe));
}
}
/* Output:
47747
0
*/
这里，SharedUser的构造函数共享了相同的参数，SharedUser 理所当然的使用了这些参数，构造函数引起了冲突，而自身并不知道失控了。
Java 中并不支持对构造函数synchronized，但实际上可以实现一个synchronized 块的，例如：
// SynchronizedConstructor.java
import java.util.concurrent.atomic.*;
class SyncConstructor implements HasID {
private final int id;
private static Object constructorLock = new Object();
public SyncConstructor(SharedArg sa) {
synchronized(constructorLock) {
id = sa.get();
}
}
@Override
public int getID() { return id; }
}
public class SynchronizedConstructor {
public static void main(String[] args) {
Unsafe unsafe = new Unsafe();
IDChecker.test(() -> new SyncConstructor(unsafe));
}
}
/* Output:
0
*/
这样，就是线程安全的了。另一种方式是避免构造函数的集成，通过一个静态工厂的方法来生成对象：
// SynchronizedFactory.java
import java.util.concurrent.atomic.*;
class SyncFactory implements HasID {
private final int id;
private SyncFactory(SharedArg sa) {
id = sa.get();
}
@Override
public int getID() { return id; }
public static synchronized
SyncFactory factory(SharedArg sa) {
return new SyncFactory(sa);
}
}
public class SynchronizedFactory {
public static void main(String[] args) {
Unsafe unsafe = new Unsafe();
IDChecker.test(() ->
SyncFactory.factory(unsafe));
}
}
/* Output:
0
*/
这样通过工厂方法来实现加锁就可以了。
这样的结果对于老码农来说，并不意外，因为线程安全取决于那三竞争条件的成立：
- 两个处理共享变量
- 至少一个处理会对变量进行修改
- 一个处理未完成前另一个处理会介入进来
示例程序中主要是用锁来实现的，这一点上，erlang实际上具有着先天的优势。纸上得来终觉浅，终于开始在自己的虚拟机上开始安装Java 8 了，否则示例程序都跑不通了。对完成线程安全而言————
规避一，没有共享内存，就不存在竞态条件了，例如利用独立进程和actor模型。
规避二，比如C++中的const，scala中的val，Java中的immutable
规避三, 不介入，使用协调模式的线程如coroutine等，也可以使用表示不便介入的标识——锁、mutex、semaphore，实际上是使用中的状态令牌。
最后，简单粗暴地说， share nothing 基本上可以从根本上解决线程安全吧。
参考阅读：
http://bruceeckel.github.io/
https://www.ibm.com/developerworks/cn/java/j-jtp09263/
http://blog.csdn.net/wireless_com/article/details/44150053
http://blog.csdn.net/wireless_com/article/details/42550241
网友评论