mskitten

又惘又怠

[JCIP笔记](五)JDK并发包

这一节来讲一讲java.util.concurrent这个包里的一些重要的线程安全有关类。

synchronized容器

synchronized容器就是把自己的内部状态封装起来,通过把每一个public方法设置成同步来控制对共享变量的访问的容器。主要包括Vector, Hashtable,以及Collections.synchronizedxxx()方法提供的wrapper。

synchronized容器的问题-client locking

首先,synchronzied容器虽然是线程安全的,但是要访问容器内部数据的线程只能先拿到容器的内置锁才能访问,实际上相当于串行访问,CPU利用率和效率都不高。
另外还有一个值得注意的地方,就是用户代码使用synchronized容器时,如果需要做一些复合操作,比如put-if-absent,仍然要显式加锁(称为client locking),否则会产生race condition。
比如以下操作:

1 public Object getLast(Vector list){
2   int last = list.size() - 1; //1
3   return list.get(last); //2
4 }
5 public void removeLast(Vector list){
6   int last = list.size() - 1; //3
7   list.remove(last); //4
8 }

以上两个方法都对Vector进行了复合操作,在不加锁的情况下可能产生这样一种场景:线程A调用getLast(),同时线程B调用removeLast()。线程A进行step 1拿到last同时线程B也拿到同样的last;此时由于线程调度上的原因,线程B先执行了step 4删除了最后一个节点,而线程A在此之后才执行step 2, 由于最后一个节点已被删除,线程A这里会报ArrayIndexOutOfBoundsException,而这个错误并不是用户希望看到的。


  

所以如果要按照类似的方法使用synchronized容器的话还是需要自己加锁。由于这些容器内部的线程安全策略是使用自己的内置锁,所以用户代码加锁的时候需要用到的是容器本身。

 1 public Object getLast(Vector list){
 2   synchronized(list){
 3     int last = list.size() - 1; //1
 4     return list.get(last); //2
 5   }
 6 }
 7 public void removeLast(Vector list){
 8   synchronized(list){
 9     int last = list.size() - 1; //3
10     list.remove(last); //4
11   }
12 }

除了这些用户自定义的复合操作之外,其实iteration也算复合操作,所以也应该加锁。此处应注意两点:

  1.  容器自带的Iterator本身不支持并发修改,所以它提供了一个所谓的fail-fast的并发修改报错机制,即容器自身维护一个modCount域,Iterator在创建时记录这个modCount的值,如果在用户遍历容器的过程中modCount值发生了改变,则说明有另一个线程对容器做出了修改,那么Iterator马上会抛出ConcurrentModificationException。

    这个机制严格意义上并不能够100%地探测到并发修改,因为modCount这个域并不是volatile的,在判断    

    if(modCount == expectedModCount)

   时也并未加锁。作者描述这个机制是在考虑性能的情况下所做的一个best-effort的努力。总之,不应该对这个机制做过多的依赖。

       2.  有一些容器自带的方法看起来很无辜,但内部会用到iterator,所以用户用到这些无辜方法的时候还是要加锁。比如我们常用的toString, for-each语法,hashCode, equals, containsAll, removeAll, retainAll, 以其他容器为参数的构造器,等等。而这些方法有时候也是被隐式调用的,很难检查到,比如:

    1 //...add some elements to the set
    2 System.out.println("DEBUG: added ten elements to " + set);

    这里打印时set.toString()方法被隐式调用了。

client locking的问题

由于client code尝试使用容器内部的线程安全机制,所以容易导致starvation和deadlock,这是因为任意代码都可以使用容器的内置锁,散落在各处的线程安全机制使得程序很难维护和debug。如果要解决这个问题,可以把容器克隆到线程内部进行使用,但每次使用的时候都要重新克隆,要考虑克隆本身带来的代价。

Concurrent容器

相比于synchronized容器,Concurrent容器可以提供更高的并发性。
如果需要并发的Map,相比于synchronized Map,可以优先考虑ConcurrentHashMap;同理,相比于synchronized List/Set,可以优先考虑CopyOnWriteArrayList/Set;相比于synchronized SortedMap/Set,可以优先考虑ConcurrentSkipMap/Set。

ConcurrentHashMap

+ 使用了比Hashtable更细粒度的lock striping线程安全策略,支持多个(有限个)线程同时读写。
+ 提供的Iterator是weakly consistent的,容许并发修改。
- size/isEmpty等方法只提供估算值。
- 由于使用的锁对象是private的,不支持client-side locking。(但是提供put-if-absent等复合操作)

CopyOnWriteArrayList

+ 每次改动时创建和发布新的collection copy。
+ 内部array是effectively immutable的,因此发布后可以不加锁地安全访问。
+ 适用于iteration >> modification的情况,如listeners。

BlockingQueue与生产者-消费者

BlockingQueue的最大好处是它不仅是一个简单的容器,它还能提供flow-control,能让程序在消息过多的情况下仍然保持健壮。

特殊的BlockingQueue: SynchronousQueue

一种很特殊的queue,实际上没有内在的存储,只是用于线程间的交接(rendezvous)。适用于消费者够多的情况,比起BlockingQueue的最大好处是没有交接成本。

 1 Thread producer = new Thread("PRODUCER") {
 2   public void run() {
 3     String event = "MY_EVENT";
 4     try {
 5       queue.put(event); // thread will block here
 6       System.out.printf("[%s] published event : %s %n", Thread.currentThread().getName(), event);
 7     } catch (InterruptedException e) {
 8       e.printStackTrace();
 9     }
10   }
11 };
12 producer.start(); // starting publisher thread
13 
14 
15 Thread consumer = new Thread("CONSUMER") {
16   public void run() {
17     try {
18       String event = queue.take(); // thread will block here
19       System.out.printf("[%s] consumed event : %s %n", Thread.currentThread().getName(), event);
20     } catch (InterruptedException e) {
21       e.printStackTrace();
22     }
23   }
24 };
25 consumer.start(); // starting consumer thread
26 
27 [PRODUCER] published event : MY_EVENT
28 [CONSUMER] consumed event : MY_EVENT

 

Synchronizers

所谓的synchronizer,就是能够根据其内部状态调节线程的control flow的对象。

CountDownLatch

主要方法:
  - countDown
  - await
CountDownLatch有如一个阀门,在其达到最终状态前阀门关闭,线程不可通过。达到最终状态时,阀门打开,所有线程通过。打开后的阀门永远打开,状态不再改变。

适用情景:

  • 等待所依赖的资源全部加载完成后才继续。 
  • 初始化顺序中各个service之间的相互等待。 
  • 等待所有参与的player都准备好才开始游戏。

FutureTask

主要方法:get
task真正结束前get方法会阻塞,直到task执行结束/被取消/抛异常。

Semaphore

主要方法:
  - release
  - acquire

有有限多个permit,acquire时如果permit为0会阻塞,但release可以执行无限多次。

适合:控制可以同时访问某资源的activity数量。可用来实现资源池或将容器设为可以存储有限个元素的容器。

CyclicBarrier

主要方法:await

必须所有线程到达Barrier时,所有线程才能通过。

Latch用来等待事件;Barrier用来等待其它线程。

适用场景:N等N

 1 public class CellularAutomata {
 2     private final Board mainBoard;
 3     private final CyclicBarrier barrier;
 4     private final Worker[] workers;
 5 
 6     public CellularAutomata(Board board) {
 7         this.mainBoard = board;
 8         int count = Runtime.getRuntime().availableProcessors();
 9         this.barrier = new CyclicBarrier(count,
10                 new Runnable() {
11                     public void run() {
12                         mainBoard.commitNewValues();
13                     }});
14         this.workers = new Worker[count];
15         for (int i = 0; i < count; i++)
16             workers[i] = new Worker(mainBoard.getSubBoard(count, i));
17     }
18 
19     private class Worker implements Runnable {
20         private final Board board;
21 
22         public Worker(Board board) { this.board = board; }
23         public void run() {
24             while (!board.hasConverged()) {
25                 for (int x = 0; x < board.getMaxX(); x++)
26                     for (int y = 0; y < board.getMaxY(); y++)
27                         board.setNewValue(x, y, computeValue(x, y));
28                 try {
29                     barrier.await();
30                 } catch (InterruptedException ex) {
31                     return;
32                 } catch (BrokenBarrierException ex) {
33                     return;
34                 }
35             }
36         }
37 
38         private int computeValue(int x, int y) {
39             // Compute the new value that goes in (x,y)
40             return 0;
41         }
42     }
43 
44     public void start() {
45         for (int i = 0; i < workers.length; i++)
46             new Thread(workers[i]).start();
47         mainBoard.waitForConvergence();
48     }
49 }

 

posted @ 2018-04-29 21:30 mskitten 阅读(...) 评论(...) 编辑 收藏