Java并发编程实战读书笔记-Chapter5-1

第4章介绍了构造线程安全类时采用的一些技术，例如将线程安全性委托给现有的线程安全类。委托是创建线程安全类的一个最有效的策略：只需让现有的线程安全类管理所有的状态即可。

Java平台类库包含了丰富的并发基础构建模块，例如线程安全的容器类以及各种用于协调多个相互协作的线程控制流的同步工具类（Synchronizer）。本章将介绍其中一些最有用的并发构建模块，以及在使用这些模块来构造并发应用程序时的一些常用模式。

5.1 同步容器类

同步容器类包括Vector和Hashtable，二者是早期JDK的一部分，这些同步的封装器类是由Collections.synchronizedXxx等工厂方法创建的。这些类实现线程安全的方式是：将它们的状态封装起来，并对每个公有方法都进行同步，使得每次只有一个线程能访问容器的状态。

5.1.1 同步容器类的问题

同步容器类都是线程安全的，但在某些情况下可能需要额外的客户端加锁来保护复合操作。容器上常见的复合操作包括：迭代（反复访问元素，直到遍历完容器中所有元素）、跳转（根据指定顺序找到当前元素的下一个元素）以及条件运算，例如“若没有则添加”（检查在Map中是否存在键值K，如果没有，就加入二元组（K, V））。在同步容器类中，这些复合操作在没有客户端加锁的情况下仍然是线程安全的，但当其他线程并发地修改容器时，它们可能会表现出意料之外的行为。
示例1给出了在Vector中定义的两个方法：getLast和deleteLast，它们都会执行“先检查再运行”操作。每个方法首先都获得数组的大小，然后通过结果来获取或删除最后一个元素。

示例1：

public class VectorV1 {
    private static String getLast(Vector<String> list) {
        final int lastIndex = list.size() - 1;
        try {
            TimeUnit.NANOSECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return list.get(lastIndex);
    }

    private static void deleteLast(Vector<String> list) {
        int lastIndex = list.size() - 1;
        list.remove(lastIndex);
    }

    public static void main(String[] args) {
        final Vector<String> strings = new Vector<String>() {
            {
                add("a");
                add("b");
                add("c");
                add("d");
            }
        };
        new Thread(() -> {
            System.out.println(getLast(strings));
        }).start();

        new Thread(() -> {
            deleteLast(strings);
        }).start();
    }
}

这些方法看似没有任何问题，从某种程度上来看也确实如此——无论多少个线程同时调用它们，也不破坏Vector。但从这些方法的调用者角度来看，情况就不同了。如果线程A在包含10个元素的Vector上调用getLast，同时线程B在同一个Vector上调用deleteLast，这些操作的交替执行如图1所示，实际结果输出如示例2所示。getLast将抛出ArrayIndexOutOfBoundsException异常。在调用size与调用getLast这两个操作之间，Vector变小了，因此在调用size时得到的索引值将不再有效。这种情况很好地遵循了Vector的规范—如果请求一个不存在的元素，那么将抛出一个异常。但这并不是getLast的调用者所希望得到的结果（即使在并发修改的情况下也不希望看到），除非Vector从一开始就是空的。

图1

示例2：在某些情况下示例1会出现ArrayIndexOutOfBoundsException异常

Exception in thread "Thread-0" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 3
	at java.util.Vector.get(Vector.java:753)
	at com.jcip.chapter.ch5.VectorV1.getLast(VectorV1.java:14)
	at com.jcip.chapter.ch5.VectorV1.lambda$main$0(VectorV1.java:32)
	at java.lang.Thread.run(Thread.java:750)

由于同步容器类要遵守同步策略，即支持客户端加锁，因此可能会创建一些新的操作，只要我们知道应该使用哪一个锁，那么这些新操作就与容器的其他操作一样都是原子操作。同步容器类通过其自身的锁来保护它的每个方法。通过获得容器类的锁，我们可以使getLast和deleteLast成为原子操作，并确保Vector的大小在调用size和get之间不会发生变化。

示例3：在使用客户端加锁的Vector上的复合操作

public class VectorV2 {
    private static String getLast(Vector<String> list) {
        synchronized(list) {
            final int lastIndex = list.size() - 1;
            try {
                TimeUnit.NANOSECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return list.get(lastIndex);
        }
    }

    private static void deleteLast(Vector<String> list) {
        synchronized (list) {
            int lastIndex = list.size() - 1;
            list.remove(lastIndex);
        }
    }

    public static void main(String[] args) {
        final Vector<String> strings = new Vector<String>() {
            {
                add("a");
                add("b");
                add("c");
                add("d");
            }
        };
        new Thread(() -> {
            System.out.println(getLast(strings));
        }).start();

        new Thread(() -> {
            deleteLast(strings);
        }).start();
    }
}

在调用size和相应的get之间，Vector的长度可能会发生变化，这种风险在对Vector中的元素进行迭代时仍然会出现

示例4：可能抛出ArrayIndexOutOfBoundsException的迭代操作

        for (int i = 0; i < vector.size(); i++) {
            doSomething(vector.get(i));
        }

虽然在示例4的迭代操作中可能抛出异常，但并不意味着Vector就不是线程安全的。Vector的状态仍然是有效的，而抛出的异常也与其规范保持一致。然而，像在读取最后一个元素或者迭代等这样的简单操作中抛出异常显然不是人们所期望的。

可以通过在客户端加锁来解决不可靠迭代的问题，但要牺牲一些伸缩性。通过在迭代期间持有Vector的锁，可以防止其他线程在迭代期间修改Vector，如示例5所示。然而，这同样会导致其他线程在迭代期间无法访问它，因此降低了并发性。

示例5：带有客户端加锁的迭代

        synchronized(vector) {
            for(int i = 0；i < vector.size(); i++) {
                doSomething(vector.get(i));
            }
        }

5.1.2 迭代器ConcurrentModificationException

许多容器类也并没有消除复合操作中的问题。无论在直接迭代还是for-each循环语法中，对容器类进行迭代的标准方式都是使用Iterator。然而，如果有其他线程并发地修改容器，那么即使是使用迭代器也无法避免在迭代期间对容器加锁。在设计同步容器类的迭代器时并没有考虑到并发修改的问题，并且它们表现出的行为是“及时失败”（fail-fast）的。这意味着，当它们发现容器在迭代过程中被修改时，就会抛出一个ConcurrentModificationException异常。

示例6：通过Iterator来迭代List

public class WidgetSync {
    private void iteratorList(List<Widget> list) {
        for (Widget widget : list) {
            System.out.println(widget);
            try {
                TimeUnit.MILLISECONDS.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    private void remove(List<Widget> list, Widget widget) {
        list.remove(widget);
    }

    public static void main(String[] args) {
        final WidgetSync widgetSync = new WidgetSync();
        final List<Widget>  widgetList = Collections.synchronizedList(new ArrayList<Widget>());
        final Widget widget1 = new Widget();
        final Widget widget2 = new Widget();
        final Widget widget3 = new Widget();
        final Widget widget4 = new Widget();
        final Widget widget5 = new Widget();

        widgetList.add(widget1);
        widgetList.add(widget2);
        widgetList.add(widget3);
        widgetList.add(widget4);
        widgetList.add(widget5);

        new Thread(() -> {
            widgetSync.iteratorList(widgetList);
        }).start();

        new Thread(() -> {
            widgetSync.remove(widgetList, widget3);
        }).start();
    }
}

输出
Exception in thread "Thread-0" java.util.ConcurrentModificationException
	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:911)
	at java.util.ArrayList$Itr.next(ArrayList.java:861)
	at com.jcip.chapter.ch5.WidgetSync.iteratorList(WidgetSync.java:12)
	at com.jcip.chapter.ch5.WidgetSync.lambda$main$0(WidgetSync.java:42)
	at java.lang.Thread.run(Thread.java:750)

如果不希望在迭代期间对容器加锁，那么一种替代方法就是“克隆”容器，并在副本上进行迭代。由于副本被封闭在线程内，因此其他线程不会在选代期间对其进行修改，这样就避免了抛出
ConcurrentModificationException（在克隆过程中仍然需要对容器加锁）。在克隆容器时存在显著的性能开销。这种方式的好坏取决于多个因素，包括容器的大小，在每个元素上执行的工作，迭代操作相对于容器其他操作的调用频率，以及在响应时间和吞吐量等方面的需求。