第2章 Java并行程序基础（三）

2.8 程序中的幽灵：隐蔽的错误

2.8.1 无提示的错误案例

• 以求两个整数的平均值为例。请看下面代码：

int v1 = 1073741827;
int v2 = 1431655768;
System.out.println("v1 = " + v1);
System.out.println("v2 = " + v2);
int ave = (v1 + v2) / 2;
System.out.println("ave = " + ave);

• 输出如下：

v1 = 1073741827
v2 = 1431655768
ave = -894784850

• 这是一个典型的溢出问题！显然，v1 + v2的结果已经导致了int的溢出。

2.8.2 并发下的ArrayList

• ArrayList是一个线程不安全的容器。如果在多线程中使用ArrayList，可能会导致程序出错。试看下面的代码：

public class ArrayListMultiThread {
    static ArrayList<Integer> al = new ArrayList<Integer>(10);
    public static class AddThread implements Runnable {
        @Override
        public void run() {
            for (int i = 0; i < 10000000; i++) {
                al.add(i);
            }
        }
    }
    
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(new AddThread());
        Thread t2 = new Thread(new AddThread());
        t1.start();
        t2.start();
        t1.join();t2.join();
        System.out.println(al.size());
    }
}

• 如果执行这段代码，可能会得到三种结果。
  • 第一，程序正常结束，ArrayList的最终大小确实2000000。这说明即使并行程序有问题，也未必会每次都表现出来。
  • 第二，程序抛出异常：

Exception in thread "Thread-0" java.lang.ArrayIndexOutOfBoundsException:22

• 这是因为ArrayList在扩容过程中，内部一致性被破坏，但由于没有锁的保护，另外一个线程访问到了不一致的内部状态，导致出现越界问题。
  • 第三，出现了一个非常隐蔽的错误，比如打印如下值作为ArrayList的大小：

1793758

• 显然，这是由于多线程访问冲突，使得保存容器大小的变量被多线程不正常的访问，同时两个线程也同时对ArrayList中的同一位置进行赋值导致的。
• 注意：改进的方法很简单，使用线程安全的Vector代替ArrayList即可。

2.8.3 并发下诡异的HashMap

• HashMap同样不是线程安全的。当你使用多线程访问HashMap时，也可能会遇到意想不到的错误。不过和ArrayList不同，HashMap的问题似乎更加诡异。

public class HashMapMultiThread {
    static Map<String, String> map = new HashMap<String, String>();
    
    public static class AddThread implements Runnable {
        int start = 0;
        public AddThread(int start) {
            this.start = start;
        }
        @Override
        public void run() {
            for (int i = start; i < 100000; i += 2) {
                map.put(Integer.toString(i), Integer.toBinaryString(i));
            }
        }
    }
    
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(new HashMapMultiThread.AddThread(0));
        Thread t2 = new Thread(new HashMapMultiThread.AddThread(1));
        t1.start();
        t2.start();
        t1.join();t2.join();
        System.out.println(map.size());
    }
}

• 可能会得到以下三种情况：
  • 第一，程序正常结束，并且结果也是符合预期的。HashMap的大小为100000。
  • 第二，程序正常结束，但结果不符合预期，而是一个小于100000的数字，比如98868。
  • 第三，程序永远无法结束。
• 对于前两种可能，和ArrayList的情况非常类似。
• 使用jstack工具显示程序的线程信息，如下所示。其中jps可以显示当前系统中所有的Java进程。而jstack可以打印给定Java进程的内部线程及其堆栈。

C:\Users\geym >jps
14240 HashMapMultiThread
1192 Jps
C:\Users\geym >jstack 14240

• 可以看到，主线程main正处于等待状态，并且这个等待是由于join()方法引起的，符合我们的预期。而t1和t2两个线程都处于Runnable状态，并且当前执行语句为HashMap.put()方法。
• 查看put()方法的代码，如下所示：

for (Entry<K, V> e = table[i]; e != null; e = e.next) {
    Object k;
    if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
        V oldValue = e.value;
        e.value = value;
        e.recordAccess(this);
        return oldValue;
    }
}

• 可以看到，当前两个线程正在遍历HashMap的内部数据。当前所处循环乍看之下是一个迭代遍历，就如同遍历一个链表一样。但在此时此刻，由于多线程的冲突，这个链表的结构已经遭到了破坏，链表成环了！当链表成环时，上述的迭代就等同于一个死循环，如图2.9所示，展示了最简单的一种环状结构，Key1和Key2互为对方的next元素。此时，通过next引用遍历，将形成死循环。
  

• 这个死循环的问题，如果一旦发生，着实可以让你郁闷一把。但这个死循环的问题在JDK8中已经不存在了。由于JDK8对HashMap的内部实现了做了大规模的调整，因此规避了这个问题。但即使这样，贸 然在多线程环境下使用HashMap依然会导致内部数据不一致。最简单的解决方案就是使用ConcurrentHashMap代替HashMap。

2.8.4 初学者常见问题：错误的加锁

• 现在，假设我们需要一个计数器，这个计数器会被多个线程同时访问。为了确保数据正确性，我们自然会需要对计数器加锁，因此，就有了以下代码：

public class BadLockOnInteger implements Runnable {
    public static Integer i = 0;
    static BadLockOnInteger instance = new BadLockOnInteger();
    @Override
    public void run() {
        for (int j = 0; j < 10000000; j++) {
            synchronized(i) {
                i++;
            }
        }
    }
    
    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(instance);
        Thread t2 = new Thread(instance);
        t1.start();t2.start();
        t1.join();t2.join();
        System.out.println(i);
    }
}

• 为了保证计数器i的正确性，每次对i自增前，都先获得i的锁，以此保证i是线程安全的。但我们得到一个比20000000小很多的数。

• 要解释这个问题，得从Integer说起，在Java中，Integer属于不变对象。也就是对象一旦被创建，就不可能被修改。也就是说，如果你有一个Integer代表1，那么它就永远表示1，你不可能修改Integer的值，使它为2.

• 使用javap反编译这段代码的run()方法，我们可以看到：
  

• 从结果中看出，实际上使用了Integer.valueOf()方法新建了一个新的Integer对象，并将它赋值给变量i。也就是说，i++在真实执行时变成了：

i = Integer.valueOf(i.intValue() + 1);

• 进一步查看Integer.valueOf()，我们可以看到：

public static Integer valueOf(int i) {
    assert IntegerCache.high >= 127;
    if (i >= IntegerCache.low && i <= IntegerCache.high) {
        return IntegerCache.cache[i + (-IntegerCache.low)];
    }
    return new Integer(i);
}

• Integer.valueOf()实际上是一个工厂方法，它会倾向于返回一个代表指定数值的Integer实例。因此,i++的本质是，创建一个新的Integer对象，并将它的引用赋值给i。
• 由于在多个线程间，并不一定能够看到同一对象（因为i对象一直在变），因此，两个线程每次加锁可能都加在了不同的对象实例上，从而导致对临界区代码控制出现问题。
• 修正这个问题也容易，只要将

sychronized(i) {

• 改为：

synchronized(instance) {