Java多线程编程的常见陷阱

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

开发中常见的一种错误做法是在构造函数中启动线程，示例如下：

public class A {  
   public A() {  
      this.x = 1;  
      this.y = 2;  
      this.thread = new MyThread();  
      this.thread.start();  
   }    
}

潜在问题：
如果存在类 B 继承自类 A，依据 Java 类初始化的顺序，A 的构造函数会在 B 的构造函数调用前执行。这意味着 thread 线程将在 B 被完全初始化之前启动。当 thread 运行时，如果使用了类 A 中的某些变量，可能获取到的不是预期中的值，因为 B 的构造函数中可能会给这些变量赋予新的值。此时将有两个线程在使用这些变量，而这些变量却没有同步保护。

解决方案：

将类 A 设置为 final，禁止被继承。
提供单独的 start 方法用来启动线程，而不是放在构造函数中。

2. 不完全的同步

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

class A {  
  int x;  
  public int getX() {  
     return x;  
  }  
  public synchronized void setX(int x) {  
     this.x = x;  
  }  
}

x 的 setter 方法有同步，然而 getter 方法却没有，那么就无法保证其他线程通过 getX 得到的 x 是最新的值。

技术细节：
事实上，这里的 setX 的同步对于 int 类型是没有必要的，因为对 int 的写入是原子的，这一点 JVM 规范已经保证，多个同步没有任何意义。当然，如果这里不是 int，而是 double 或者 long，那么 getX 和 setX 都将需要同步。因为 double 和 long 都是 64 位，写入和读取都是分成两个 32 位来进行（这一点取决于 JVM 的实现，有的 JVM 实现可能保证对 long 和 double 的 read、write 是原子的），没有保证原子性。

类似上面这样的代码，其实都可以通过声明变量为 volatile 来解决。

3. 锁对象引用变更导致同步失效

这也是并发编程中常见的错误，类似下面的代码：

synchronized(array[0]) {  
   ......  
   array[0] = new A();  
   ......  
}

同步块使用 array[0] 作为锁，然而在同步块中却改变了 array[0] 指向的引用。分析下这个场景：第一个线程获取了 array[0] 的锁，第二个线程因为无法获取 array[0] 而等待。在改变了 array[0] 的引用后，第三个线程获取了新的 array[0] 的锁。第一和第三两个线程持有的锁是不一样的，同步互斥的目的就完全没有达到。

解决方案：
通常是将锁声明为 final 变量，或者引入业务无关的锁对象，保证在同步块内不会被修改引用。

4. wait() 未在循环中调用

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

synchronized(lock) {  
   if (isEmpty()) { // 修正了原文的语法错误
     lock.wait();     
   }
}

潜在问题：
对条件的判断是使用 if，这会造成什么问题呢？在判断条件之前可能调用 notify 或者 notifyAll，那么条件已经满足，不会等待，这没什么问题。在条件没有满足，调用了 wait() 方法，释放 lock 锁并进入等待休眠状态。

如果线程是在正常情况下，也就是条件被改变之后被唤醒，那么没有任何问题，条件满足继续执行下面的逻辑操作。问题在于线程可能被意外甚至恶意唤醒。由于没有再次进行条件判断，在条件没有被满足的情况下，线程执行了后续的操作。意外唤醒的情况，可能是调用了 notifyAll，可能是有人恶意唤醒，也可能是很少情况下的自动苏醒（称为“伪唤醒”）。

因此，为了防止这种条件没有满足就执行后续操作的情况，需要在被唤醒后再次判断条件。如果条件不满足，继续进入等待状态；条件满足，才进行后续操作。

synchronized(lock) {  
   while (isEmpty()) {  
     lock.wait();     
   }
}

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

5. 同步范围过小或过大

同步的范围过小，可能完全没有达到同步的目的；同步的范围过大，可能会影响性能。

同步范围过小

一个常见例子是误认为两个同步的方法一起调用也是将同步的，需要记住的是 Atomic + Atomic != Atomic。

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

这是一个很典型的错误。map 是线程安全的，containsKey 和 put 方法也是线程安全的，然而两个线程安全的方法被组合调用就不一定是线程安全的了。因为在 containsKey 和 put 之间，可能有其他线程抢先 put 进了 a，那么就可能覆盖了其他线程设置的值，导致值的丢失。

解决方案：
解决这一问题的方法就是扩大同步范围。因为对象锁是可重入的，因此在线程安全方法之上再同步相同的锁对象不会有问题。

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

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

同步范围过大

同步范围过大的例子也很多，比如在同步块中 new 大对象，或者调用费时的 IO 操作（操作数据库、WebService 等）。不得不调用费时操作的时候，一定要指定超时时间，例如通过 URLConnection 去 invoke 某个 URL 时就要设置 connect timeout 和 read timeout，防止锁被独占不释放。

同步范围过大的情况下，要在保证线程安全的前提下，将不必要同步的操作从同步块中移出。

volatile 的适用场景

状态标志，模拟控制机制
常见用途如控制线程是否停止：
```
private volatile boolean stopped;  
public void close() {  
    stopped = true;  
}  
 
public void run() {  
    while (!stopped) {  
       // do something  
    }     
} 
```
前提是 do something 中不会有阻塞调用之类。volatile 保证 stopped 变量的可见性，run 方法中读取 stopped 变量总是 main memory 中的最新值。

安全发布，如修复 DLC 问题

private volatile IoBufferAllocator instance;  
public IoBufferAllocator getInstance() { // 修正了原文拼写错误
    if (instance == null) {  // 已经有的话直接跳过，不用排队判断有没有
        synchronized (IoBufferAllocator.class) {  
            if (instance == null)  // 如果没有，2 个线程一起来初始化，阻塞等待，一个已经初始化了，另一个线程就不用了
                instance = new IoBufferAllocator();  
        }  
    }  
    return instance;  
}

开销较低的读写锁

public class CheesyCounter {  
    private volatile int value;  
 
    public int getValue() { return value; }  
 
    public synchronized int increment() {  
        return value++;  
    }  
}

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

volatile 的常见误区

不能用于做计数器
```
public class CheesyCounter {  
    private volatile int value;  
 
    public int getValue() { return value; }  
 
    public int increment() {  
        return value++;  
    }  
} 
```
因为 value++ 其实是有三个操作组成的：读取、修改、写入，volatile 不能保证这个序列是原子的。对 value 的修改操作依赖于 value 的最新值。解决这个问题的方法可以将 increment 方法同步，或者使用 AtomicInteger 原子类。

与其他变量构成不变式
一个典型的例子是定义一个数据范围，需要保证约束 lower < upper。

public class NumberRange {  
    private volatile int lower, upper;  
 
    public int getLower() { return lower; }  
    public int getUpper() { return upper; }  
 
    public void setLower(int value) {   
        if (value > upper)   
            throw new IllegalArgumentException();  
        lower = value;  
    }  
 
    public void setUpper(int value) {   
        if (value < lower)   
            throw new IllegalArgumentException();  
        upper = value;  
    }  
}

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

解决方案：
修改这个问题的办法就是将 setLower 和 setUpper 同步：

public class NumberRange {  
    private volatile int lower, upper;  
 
    public int getLower() { return lower; }  
    public int getUpper() { return upper; }  
 
    public synchronized void setLower(int value) {   
        if (value > upper)   
            throw new IllegalArgumentException();  
        lower = value;  
    }  
 
    public synchronized void setUpper(int value) {   
        if (value < lower)   
            throw new IllegalArgumentException();  
        upper = value;  
    }  
}

补充说明：关于 i++ 的原子性

i++ 这个操作是非原子性的。假设它里面有三个操作：

读取 i 的值。
将 i 增加 1。
写入主存。

这样的话，当线程 1 执行完操作 1 后，切换到线程 2。待线程 2 的 i++ 操作执行完后，线程 1 的缓存行失效。但是因为在线程 1 中，操作 1（读取 i 的值）已经执行过了，无需再去读取 i 的值，所以缓存行是否更新也就无关紧要了。待线程 1 执行完操作 2、3 后，自然会得到错误的答案。

说明：本文基于 Java 内存模型（JMM）的一般原理编写，主要适用于 Java 5 及以上版本。关于 long 和 double 的原子性细节可能因 JVM 实现而异，生产环境中建议统一使用 volatile 或原子类以确保跨平台一致性。

本文地址：https://1diff.fun/archives/java-duo-xian-cheng-bian-cheng-de-chang-jian-xian-jing.html

如果对本文有什么问题或疑问都可以在评论区留言，我看到后会尽量解答。