老曹：从构造函数看线程安全-构造函数线程安全

线程是编程中常用而且强大的手段，在使用过程中，我们经常面对的就是线程安全问题了。对于Java中常见的数据结构而言，一般的，ArrayList是非线程安全的，Vector是线程安全的;HashMap是非线程安全的，HashTable是线程安全的;StringBuilder是非线程安全的，StringBuffer是线程安全的。

[[188681]]

然而，判断代码是否线程安全，不能够想当然，例如Java 中的构造函数是否是线程安全的呢?

自己从***感觉来看，构造函数应该是线程安全的，如果一个对象没有初始化完成，怎么可能存在竞争呢? 甚至在Java 的语言规范中也谈到，没有必要将constructor 置为synchronized，因为它在构建过程中是锁定的，其他线程是不可能调用还没有实例化好的对象的。

[[188682]]

但是，当我读过了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. 这个 List 从每个HasID 对象中得到一个ID。test() 方法创建了两个并行的CompletableFutures 来运行MakeObjects suppliers, 然后就每个结果使用Guava库的Sets.intersection() 来找出两个List中有多少个共有的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 
*/

这样通过工厂方法来实现加锁就可以安全了。

[[188683]]

这样的结果对于老码农来说，并不意外，因为线程安全取决于那三竞争条件的成立：

两个处理共享变量
至少一个处理会对变量进行修改
一个处理未完成前另一个处理会介入进来

示例程序中主要是用锁来实现的，这一点上，erlang实际上具有着先天的优势。纸上得来终觉浅，终于开始在自己的虚拟机上开始安装Java 8 了，否则示例程序都跑不通了。对完成线程安全而言————

规避一，没有共享内存，就不存在竞态条件了，例如利用独立进程和actor模型。

规避二，比如C++中的const，scala中的val，Java中的immutable

规避三, 不介入，使用协调模式的线程如coroutine等，也可以使用表示不便介入的标识——锁、mutex、semaphore，实际上是使用中的状态令牌。

***，简单粗暴地说， share nothing 基本上可以从根本上解决线程安全吧。

【本文来自51CTO专栏作者“老曹”的原创文章，作者微信公众号：喔家ArchiSelf,id:wrieless-com】

戳这里，看该作者更多好文