《实战高并发程序设计》读书笔记-隐蔽的并发问题

た入场券 2021-09-18 07:40 294阅读 0赞

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

## 无提示错误 ##

平均值

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和v2的均值。乍看之下，没有什么问题。目测v1和v2的当前值，估计两者的平均值大约在12亿左右。但如果你执行代码，却会得到以下输出：

v1=1073741827
    v2=1431655768
    ave=-894784850

v1+v2的结果就已经导致了int的溢出。

## 并发下的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 ＜ 1000000; 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
        at java.util.ArrayList.add(ArrayList.java:441)
        at geym.conc.ch2.notsafe.ArrayListMultiThread$AddThread.run
    (ArrayListMultiThread.java:12)
        at java.lang.Thread.run(Thread.java:724)
    1000015

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

1793758

显然，这是由于多线程访问冲突，使得保存容器大小的变量被多线程不正常的访问，同时两个线程也同时对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());
        }
    }

上述代码使用t1和t2两个线程同时对HashMap进行put()操作。如果一切正常，我们期望得到的map.size()就是100000。但实际上，你可能会得到以下三种情况（注意，这里使用JDK 7进行试验）： 
  第一，程序正常结束，并且结果也是符合预期的。HashMap的大小为100000。 
  第二，程序正常结束，但结果不符合预期，而是一个小于100000的数字，比如98868。 
  第三，程序永远无法结束。

这里重点说一下第三种情况：

打开任务管理器，你们会发现，这段代码占用了极高的CPU，最有可能的表示是占用了两个CPU核，并使得这两个核的CPU使用率达到100%。这非常类似死循环的情况。  
  使用jstack工具显示程序的线程信息，如下所示。其中jps可以显示当前系统中所有的Java进程。而jstack可以打印给定Java进程的内部线程及其堆栈。

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

"Thread-1" prio=6 tid=0x00bb2800 nid=0x16e0 runnable [0x04baf000]
       java.lang.Thread.State: RUNNABLE
            at java.util.HashMap.put(HashMap.java:498)
            at geym.conc.ch2.notsafe.HashMapMultiThread$AddThread.run
    (HashMapMultiThread.java:26)
            at java.lang.Thread.run(Thread.java:724)
    
    "Thread-0" prio=6 tid=0x00bb0000 nid=0x1668 runnable [0x04d7f000]
       java.lang.Thread.State: RUNNABLE
            at java.util.HashMap.put(HashMap.java:498)
            at geym.conc.ch2.notsafe.HashMapMultiThread$AddThread.run
    (HashMapMultiThread.java:26)
            at java.lang.Thread.run(Thread.java:724)
    "main" prio=6 tid=0x00c0cc00 nid=0x16ec in Object.wait() [0x0102f000]
       java.lang.Thread.State: WAITING (on object monitor)
            at java.lang.Object.wait(Native Method)
            - waiting on ＜0x24930280＞ (a java.lang.Thread)
            at java.lang.Thread.join(Thread.java:1260)
            - locked ＜0x24930280＞ (a java.lang.Thread)
            at java.lang.Thread.join(Thread.java:1334)
            at geym.conc.ch2.notsafe.HashMapMultiThread.main(HashMapMultiThread. java:36)

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

498 for (Entry＜K,V＞ e = table[i]; e != null; e = e.next) {
    499     Object k;
    500     if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
    501         V oldValue = e.value;
    502         e.value = value;
    503         e.recordAccess(this);
    504         return oldValue;
    505     }
    506 }

可以看到，当前这两个线程正在遍历HashMap的内部数据。当前所处循环乍看之下是一个迭代遍历，就如同遍历一个链表一样。但在此时此刻，由于多线程的冲突，这个链表的结构已经遭到了破坏，链表成环了！当链表成环时，上述的迭代就等同于一个死循环，比如两个节点的next节点指向对方。

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

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

01 public class BadLockOnInteger implements Runnable{
    02     public static Integer i=0;
    03     static BadLockOnInteger instance=new BadLockOnInteger();
    04     @Override
    05     public void run() {
    06         for(int j=0;j＜10000000;j++){
    07             synchronized(i){
    08                 i++;
    09             }
    10         }
    11     }
    12
    13     public static void main(String[] args) throws InterruptedException {
    14         Thread t1=new Thread(instance);
    15         Thread t2=new Thread(instance);
    16         t1.start();t2.start();
    17         t1.join();t2.join();
    18         System.out.println(i);
    19     }
    20 }

上述代码很容易得到一个远小于20000000的数字，作者的这个例子举得确实精彩，他的锁对象居然选择了Integer，这个线程不安全的例子，如果知识储备不到位，很难解释，来看一下作者的解释：

要解释这个问题，得从Integer说起。在Java中，Integer属于不变对象。也就是对象一旦被创建，就不可能被修改。也就是说，如果你有一个Integer代表1，那么它就永远表示1，你不可能修改Integer的值，使它为2。那如果你需要2怎么办呢？也很简单，新建一个Integer，并让它表示2即可。  
  如果我们使用javap反编译这段代码的run()方法，我们可以看到：

0:   iconst_0
    1:   istore_1
    2:   goto    36
    5:   getstatic       #20; //Field i:Ljava/lang/Integer;
    8:   dup
    9:   astore_2
    10:  monitorenter
    11:  getstatic       #20; //Field i:Ljava/lang/Integer;
    14:  invokevirtual   #32; //Method java/lang/Integer.intValue:()I
    17:  iconst_1
    18:  iadd
    19:  invokestatic    #14; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
    22:  putstatic       #20; //Field i:Ljava/lang/Integer;
    25:  aload_2
    26:  monitorexit

在第19～22行（对字节码来说，这是偏移量，这里简称为行），实际上使用了Integer.valueOf()方法新建了一个新的Integer在第19～22行（对字节码来说，这是偏移量，这里简称为行），实际上使用了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对象（因为i对象一直在变），因此，两个线程每次加锁可能都加在了不同的对象实例上，从而导致对临界区代码控制出现问题。