Java多线程编程的常见陷阱

1、在构造函数中启动线程

我在很多代码中都看到这样的问题，在构造函数中启动一个线程，类似这样：

1.  public class A{  
2.  public A(){  
3.  this.x=1;  
4.  this.y=2;  
5.  this.thread=new MyThread();  
6.  this.thread.start();  
7.  }  

9.  }    

这个会引起什么问题呢？如果有个类 B 继承了类 A，依据 java 类初始化的顺序，A 的构造函数一定会在 B 的构造函数调用前被调用，那么 thread 线程也将在 B 被完全初始化之前启动，当 thread 运行时使用到了类 A 中的某些变量，那么就可能使用的不是你预期中的值，因为在 B 的构造函数中你可能赋给这些变量新的值。也就是说此时将有两个线程在使用这些变量，而这些变量却没有同步。

解决这个问题有两个办法：将 A 设置为 final，不可继承；或者提供单独的 start 方法用来启动线程，而不是放在构造函数中。

2、不完全的同步

都知道对一个变量同步的有效方式是用 synchronized 保护起来，synchronized 可能是对象锁，也可能是类锁，看你是类方法还是实例方法。但是，当你将某个变量在 A 方法中同步，那么在变量出现的其他地方，你也需要同步，除非你允许弱可见性甚至产生错误值。类似这样的代码：

1.  class A{  
2.  int x;  
3.  public int getX(){  
4.  return x;  
5.  }  
6.  public synchronized void setX(int x)  
7.  {  
8.  this.x=x;  
9.  }  
10.  }     

x 的 setter 方法有同步，然而 getter 方法却没有，那么就无法保证其他线程通过 getX 得到的 x 是 * 的值。事实上，这里的 setX 的同步是没有必要的，因为对 int 的写入是原子的，这一点 JVM 规范已经保证，多个同步没有任何意义；当然，如果这里不是 int，而是 double 或者 long，那么 getX 和 setX 都将需要同步，因为 double 和 long 都是 64 位，写入和读取都是分成两个 32 位来进行 (这一点取决于 jvm 的实现，有的 jvm 实现可能保证对 long 和 double 的 read、write 是原子的），没有保证原子性。类似上面这样的代码，其实都可以通过声明变量为 volatile 来解决。

3、在使用某个对象当锁时，改变了对象的引用，导致同步失效。

这也是很常见的错误，类似下面的代码：

1.  synchronized(array[0])  
2.  {  
3.  ......  
4.  array[0]=new A();  
5.  ......  
6.  }    

同步块使用 array[0] 作为锁，然而在同步块中却改变了 array[0] 指向的引用。分析下这个场景，* 个线程获取了 array[0] 的锁，第二个线程因为无法获取 array[0] 而等待，在改变了 array[0] 的引用后，第三个线程获取了新的 array[0] 的锁，* 和第三两个线程持有的锁是不一样的，同步互斥的目的就完全没有达到了。这样代码的修改，通常是将锁声明为 final 变量或者引入业务无关的锁对象，保证在同步块内不会被修改引用。

4、没有在循环中调用 wait()。

wait 和 notify 用于实现条件变量，你可能知道需要在同步块中调用 wait 和 notify，为了保证条件的改变能做到原子性和可见性。常常看见很多代码做到了同步，却没有在循环中调用 wait，而是使用 if 甚至没有条件判断：

1.  synchronized(lock)  
2.  {  
3.  if(isEmpty()  
4.  lock.wait();  

6.  }  

对条件的判断是使用 if，这会造成什么问题呢？在判断条件之前可能调用 notify 或者 notifyAll，那么条件已经满足，不会等待，这没什么问题。在条件没有满足，调用了 wait() 方法，释放 lock 锁并进入等待休眠状态。如果线程是在正常情况下，也就是条件被改变之后被唤醒，那么没有任何问题，条件满足继续执行下面的逻辑操作。问题在于线程可能被意外甚至恶意唤醒，由于没有再次进行条件判断，在条件没有被满足的情况下，线程执行了后续的操作。意外唤醒的情况，可能是调用了 notifyAll，可能是有人恶意唤醒，也可能是很少情况下的自动苏醒（称为 “伪唤醒”)。因此为了防止这种条件没有满足就执行后续操作的情况，需要在被唤醒后再次判断条件，如果条件不满足，继续进入等待状态，条件满足，才进行后续操作。

1.  synchronized(lock)  
2.  {  
3.  while(isEmpty()  
4.  lock.wait();  

6.  }     

没有进行条件判断就调用 wait 的情况更严重，因为在等待之前可能 notify 已经被调用，那么在调用了 wait 之后进入等待休眠状态后就无法保证线程苏醒过来。

5、同步的范围过小或者过大。

同步的范围过小，可能完全没有达到同步的目的；同步的范围过大，可能会影响性能。同步范围过小的一个常见例子是误认为两个同步的方法一起调用也是将同步的，需要记住的是 Atomic+Atomic!=Atomic。

1.  Map map=Collections.synchronizedMap(new HashMap());  
2.  if(!map.containsKey("a")){  
3.  map.put("a", value);  
4.  }    

这是一个很典型的错误，map 是线程安全的，containskey 和 put 方法也是线程安全的，然而两个线程安全的方法被组合调用就不一定是线程安全的了。因为在 containsKey 和 put 之间，可能有其他线程抢先 put 进了 a，那么就可能覆盖了其他线程设置的值，导致值的丢失。解决这一问题的方法就是扩大同步范围，因为对象锁是可重入的，因此在线程安全方法之上再同步相同的锁对象不会有问题。

1.  Map map = Collections.synchronizedMap(new HashMap());  
2.  synchronized (map) {  
3.  if (!map.containsKey("a")) {  
4.  map.put("a", value);  
5.  }  
6.  }    

注意，加大锁的范围，也要保证使用的是同一个锁，不然很可能造成死锁。Collections.synchronizedMap(new HashMap()) 使用的锁是 map 本身，因此没有问题。当然，上面的情况现在更推荐使用 ConcurrentHashMap，它有 putIfAbsent 方法来达到同样的目的并且满足线程安全性。

同步范围过大的例子也很多，比如在同步块中 new 大对象，或者调用费时的 IO 操作（操作数据库，webservice 等）。不得不调用费时操作的时候，一定要指定超时时间，例如通过 URLConnection 去 invoke 某个 URL 时就要设置 connect timeout 和 read timeout，防止锁被独占不释放。同步范围过大的情况下，要在保证线程安全的前提下，将不必要同步的操作从同步块中移出。

6、正确使用 volatile

在 jdk5 修正了 volatile 的语义后，volatile 作为一种轻量级的同步策略就得到了大量的使用。volatile 的严格定义参考 jvm spec，这里只从 volatile 能做什么，和不能用来做什么出发做个探讨。

volatile 可以用来做什么？

1）状态标志，模拟控制机制。常见用途如控制线程是否停止：

1.  private volatile boolean stopped;  
2.  public void close(){  
3.  stopped=true;  
4.  }  

6.  public void run(){  

8.  while(!stopped){  
9.  //do something  
10.  }  

12.  } 

前提是 do something 中不会有阻塞调用之类。volatile 保证 stopped 变量的可见性，run 方法中读取 stopped 变量总是 main memory 中的 * 值。

2）安全发布，如修复 DLC 问题。

1.  private volatile IoBufferAllocator instance;  
2.  public IoBufferAllocator getInsntace(){  
3.  if(instance==null){  
4.  synchronized (IoBufferAllocator.class) {  
5.  if(instance==null)  
6.  instance=new IoBufferAllocator();  
7.  }  
8.  }  
9.  return instance;  
10.  } 

3）开销较低的读写锁

1.  public class CheesyCounter {  
2.  private volatile int value;  

4.  public int getValue() { return value; }  

6.  public synchronized int increment() {  
7.  return value++;  
8.  }  
9.  }  

synchronized 保证更新的原子性，volatile 保证线程间的可见性。

volatile 不能用于做什么？

1）不能用于做计数器

1.  public class CheesyCounter {  
2.  private volatile int value;  

4.  public int getValue() { return value; }  

6.  public int increment() {  
7.  return value++;  
8.  }  
9.  } 

因为 value++ 其实是有三个操作组成的：读取、修改、写入，volatile 不能保证这个序列是原子的。对 value 的修改操作依赖于 value 的 * 值。解决这个问题的方法可以将 increment 方法同步，或者使用 AtomicInteger 原子类。

2）与其他变量构成不变式

一个典型的例子是定义一个数据范围，需要保证约束 lower< upper。

1.  public class NumberRange {  
2.  private volatile int lower, upper;  

4.  public int getLower() { return lower; }  
5.  public int getUpper() { return upper; }  

7.  public void setLower(int value) {   
8.  if (value > upper)   
9.  throw new IllegalArgumentException();  
10.  lower = value;  
11.  }  

13.  public void setUpper(int value) {   
14.  if (value < lower)   
15.  throw new IllegalArgumentException();  
16.  upper = value;  
17.  }  
18.  }  

尽管讲 lower 和 upper 声明为 volatile，但是 setLower 和 setUpper 并不是线程安全方法。假设初始状态为 (0,5)，同时调用 setLower(4) 和 setUpper(3)，两个线程交叉进行，* 结果可能是(4,3)，违反了约束条件。修改这个问题的办法就是将 setLower 和 setUpper 同步：

1.  public class NumberRange {  
2.  private volatile int lower, upper;  

4.  public int getLower() { return lower; }  
5.  public int getUpper() { return upper; }  

7.  public synchronized void setLower(int value) {   
8.  if (value > upper)   
9.  throw new IllegalArgumentException();  
10.  lower = value;  
11.  }  

13.  public synchronized void setUpper(int value) {   
14.  if (value < lower)   
15.  throw new IllegalArgumentException();  
16.  upper = value;  
17.  }  
18.  } 

---

作者：killme2008

来源链接：

https://developer.51cto.com/art/200906/129435.htm