3 JDK并发包

JDK内部提供了大量实用的API和框架。本章主要介绍这些JDK内部功能，主要分为3大部分：

首先，介绍有关同步控制的工具，之前介绍的synchronized就是一种同步控制手段，将介绍更加丰富的多线程控制方法。

其次，将详细介绍JDK对线程池的支持，使用线程池，将很大程度提高线程调度的性能。

第三，介绍JDK的一些并发容器。这些容器专为并行访问所设计，绝对是高效、安全、稳定的实用工具。

多线程团队协作：同步控制

之前提到的synchronized是最简单的同步控制的方法。本节中，首先介绍synchronized、Object.wait()、Object.notify()方法的替代品（或者说增强版）——重入锁

重入锁（ReentrantLock）：synchronized的功能扩展

jdk6.0之前，重入锁的性能远远好于synchronized，但是之后，两者差距并不大。

下面是一段重入锁使用案例：

public class ReenterLock implements Runnable{
   public static ReentrantLock lock=new ReentrantLock();
   public static int i=0;
   @Override
   public void run() {
      for(int j=0;j<10000000;j++){
         lock.lock();	//1
         try{
            i++;
         }finally{
            lock.unlock();	//2
         }
      }
   }
   public static void main(String[] args) throws InterruptedException {
      ReenterLock tl=new ReenterLock();
      Thread t1=new Thread(tl);
      Thread t2=new Thread(tl);
      t1.start();t2.start();
      t1.join();t2.join();
      System.out.println(i);
   }
}

1处加锁，2处释放锁。

重入锁是可以让线程反复进入的，这里的反复仅仅局限于一个线程。可以写成下面的形式：

lock.lock();
lock.lock();
try{
   i++;
}finally{
   lock.unlock();
   lock.unlock();
}

这种情况下，一个线程连续两次获得同一把锁，这是允许的！同时，释放也必须释放两次，释放次数多了，抛出异常，次数少了，相当于线程还持有当前锁，其他线程无法进入临界区。

重入锁除了灵活，还提供了中断处理的能力：

中断响应

对于synchronized来说，如果一个线程在等待锁，那么结果只有两种情况，要么它获得这把锁继续执行，要么它保持等待。而重入锁提供了另一种可能，那就是线程可以被中断。也就是在等待锁的过程中，程序可以根据需要取消对锁的请求。有些时候，这么做很有必要。如果一个线程正在等待锁，那么它依然可以收到一个通知，被告知无需再等待，可以停止工作了。这种情况对于处理死锁是有一定帮助的。

下面代码产生了一个死锁，但得益于锁中断，我们可以轻松解决这个死锁：

public class IntLock implements Runnable {
    //重入锁ReentrantLock
    public static ReentrantLock lock1 = new ReentrantLock();
    public static ReentrantLock lock2 = new ReentrantLock();
    int lock;
    public IntLock(int lock) {
        this.lock = lock;
    }
    @Override
    public void run() {
        // TODO Auto-generated method stub
        try {
            if (lock == 1) {
                lock1.lockInterruptibly();	//1
                Thread.sleep(500);
                lock2.lockInterruptibly();
                System.out.println("lock1 is working....");
            } else {
                lock2.lockInterruptibly();
                Thread.sleep(500);
                lock1.lockInterruptibly();
                System.out.println("lock2 is working....");
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (lock1.isHeldByCurrentThread()) {
                lock1.unlock();    //释放锁
            }
            if (lock2.isHeldByCurrentThread()) {
                lock2.unlock();
            }
            System.out.println(Thread.currentThread().getId() + "：线程退出");
        }

    }
    public static void main(String[] args) throws InterruptedException {
        IntLock r1 = new IntLock(1);
        IntLock r2 = new IntLock(2);
        Thread t1 = new Thread(r1);
        Thread t2 = new Thread(r2);
        t1.start();
        t2.start();
        Thread.sleep(1000);
        t2.interrupt();	//2
    }
}

线程t1和t2启动后，t1先占用lock1，再占用lock2；t2先占用lock2，再请求lock1。这很容易照成t1、t2互相等待，形成死锁。这里，统一使用1处的lockInterruptibly()方法，这是一个可以对中断进行相应的锁申请动作，即在等待锁的过程中，可以响应中断。

在2处，t2线程被中断，放弃对lock1的锁申请，同时释放已获得的lock2。这时t1就能顺利执行完剩余程序

锁申请等待限时

除了外部通知之外，避免死锁还有另外一种方法，就是限时等待。我们可以使用tryLock()方法进行一次限时的等待。

public class TimeLock implements Runnable {
   public static ReentrantLock lock = new ReentrantLock();
   @Override
   public void run() {
      try {
         if (lock.tryLock(5, TimeUnit.SECONDS)) {	//2
            Thread.sleep(6000);		//1
         } else {
            System.out.println("get lock failed");
         }
      } catch (InterruptedException e) {
         e.printStackTrace();
      } finally {
         if(lock.isHeldByCurrentThread())
            lock.unlock();
      }
   }
   public static void main(String[] args) {
      TimeLock tl = new TimeLock();
      Thread t1 = new Thread(tl);
      Thread t2 = new Thread(tl);
      t1.start();
      t2.start();
   }
}

在这里2处，tryLock()方法接收两个参数，一个表示等待时长，另外一个表示计时单位。没个进入临界区的线程需要占用6秒的锁（1处），而t2由于等待5秒没有等到想要的锁（2处），便返回false。若等待时间改为比5秒大，将返回true，并获得锁。

公平锁

在大多数情况下，锁的申请是非公平的。系统知识随机挑选一个，不保证其公平性。公平的锁，会按照时间的先后顺序，保证先到者先得，后到者后得。公平锁的一大特点是：不会产生饥饿现象。我们使用synchronized关键字得到的就是非公平锁，而重入锁可以对公平性设置。它有一个构造函数：

 public ReentrantLock(boolean fair)		//为true时是公平锁

实现公平锁要维护一个有序队列，因此实现公平锁的成本较高，性能相对低下，因此，默认情况下，锁时非公平的。

public class FairLock implements Runnable{
    //创建公平锁
    private static ReentrantLock lock=new ReentrantLock(true);	//1
    public void run() {
        while(true){
            lock.lock();
            try{
                System.out.println(Thread.currentThread().getName()+"获得锁");
            }finally{
                lock.unlock();
            }
        }
    }
    public static void main(String[] args) {
        FairLock lft=new FairLock();
        Thread th1=new Thread(lft);
        Thread th2=new Thread(lft);
        th1.start();
        th2.start();
    }
}/**
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
Thread-0获得锁
Thread-1获得锁
*/

你运行上面的程序，会看到结果很有规律。

如果不使用公平锁，根据系统的调度，一个线程会倾向于再次获取已经持有的锁，这种分配方式是高效的。但是无公平性可言，将上面1中的true改成false即可。

对ReentrantLock的几个重要方法整理如下：

• lock()：获得锁，如果锁已经被占用，则等待。
• lockInterruptibly()：获得锁，但优先响应中断。
• tryLock()：尝试获得锁，如果成功，返回true，失败返回false。不等待，立即返回。
• tryLock(long time, TimeUnit unit)：在给定时间内尝试获得锁。
• unlock()：释放锁。

重入锁的实现

就重入锁的实现来看，它主要集中在java层面。主要包含三个要素：

• 第一，是原子状态。原子状态使用CAS操作来存储当前锁的状态，判断锁是否已经被别的线程持有。
• 第二，是等待队列。
• 第三，是阻塞语句park()和unpark()，用来挂起和恢复线程。没有得到锁的线程将会被挂起。有关park()和unpark()的详细介绍，可以参考线程阻塞工具类：LockSupport。

重入锁的好搭档：Condition条件

Condition的作用和wait()和notify()方法的作用是大致相同的。不同的是wait()和notify()方法是和synchronized关键字合作使用的，而Condition是与重入锁合作的。通过Lock接口（重入锁实现了该接口）的newCondition()方法可以生成一个与当前重入锁绑定的Condition实例。

Condition接口提供的基本方法：

• await()：使当前线程等待，同时释放当前锁，当其他线程使用signal()或者signalAll()方法时，线程会重新获得锁并继续执行。当线程中断时，也能跳出等待，和Object.wait()非常相似。
• awaitUninterruptibly()：与await()基本相同，但是不会响应等待过程中的中断。
• signal()：唤醒一个等待中的线程，signalAll()会唤醒所有等待中的线程。

下面是Condition的演示：

public class ReenterLockCondition implements Runnable {
    public static ReentrantLock lock = new ReentrantLock();
    public static Condition condition = lock.newCondition();

    @Override
    public void run() {
        try {
            lock.lock();
            System.out.println("Thread is start...");
            condition.await();
            System.out.println("Thread is going on");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        ReenterLockCondition tl = new ReenterLockCondition();
        Thread t1 = new Thread(tl);
        t1.start();
        Thread.sleep(2000);
        //通知线程t1继续执行
        lock.lock();   //1
        condition.signal();
        lock.unlock();
    }
}

和Object.wait()和notify()方法一样，当线程使用Condition.await()时，要求线程持有相关的重入锁，在Condition.await()调用后，这个线程会释放这把锁。同理，在Condition.signal()方法调用时，也要求线程先获得相关的锁。在siganl()方法调用后，系统会从当前Condition对象的等待队列中，唤醒一个线程，一旦线程被唤醒，它会重新尝试获得与之绑定的重入锁，一旦成功获得，就可以继续执行了。因此，一般调用完condition.signal()后，都需要释放重入锁。

允许多个线程同时访问：信号量（Semaphore）

广义上讲，信号量是对锁的扩展。无论是内部锁synchronized还是重入锁ReentrantLock，一次都只允许一个线程访问一个资源，而信号量可以指定多个线程，同时访问某个资源。

主要提供了两个构造函数：

public Semaphore(int permits)
public Semaphore(int permits, boolean fair)		//第二个参数可以指定是否公平

在构造信号量对象时，必须要指定信号量的准入数，即同时能申请多少个许可。信号量的主要逻辑方法有：

public void acquire()
public void acquireUninterruptibly()
public boolean tryAcquire()
public boolean tryAcquire(long, TimeUnit unit)
public void release()

• acquire()：尝试获得一个准入的许可。若无法获得，则线程会等待，直到有线程释放一个许可或当前线程被中断。
• acquireUninterruptibly()：和acquire()方法类似，但是不响应中断。
• tryAcquire()：尝试获得一个许可，立即返回结果
• release()：释放一个许可。

public class SemapDemo implements Runnable{
    final Semaphore semp = new Semaphore(5);	//3
    @Override
    public void run() {
        try {
            semp.acquire();	//1
            //模拟耗时操作
            Thread.sleep(2000);
            System.out.println(Thread.currentThread().getId()+":done!");	//2
          	semp.release();		//4
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        ExecutorService exec = Executors.newFixedThreadPool(20);
        final SemapDemo demo=new SemapDemo();
        for(int i=0;i<20;i++){
            exec.submit(demo);
        }
    }
}

上述代码中，1处到2处为临界区管理代码，程序会限制这段代码的线程数。在第3处，申明了一个包含5个许可的信号量。这意味着1~2处只能同时有5个线程进入。线程在使用完acquire()，在离开时，务必使用release()释放信号量。这和释放锁是一个道理。

读写锁：ReadWriteLock

ReadWriteLock是JDK5中提供的读写分离锁。读写分离锁可以有效地减少锁竞争，以提升系统性能。用锁分离的机制来提升性能很容易理解，如果使用重入锁或内部锁，理论上所有读—读、读—写、写—写都是串行操作。而读写锁，允许多个线程同时读。

比如A1、A2、A3进行写操作，B1、B2、B3进行读操作。读写锁允许B1、B2、B3之间并行。但是，考虑数据完整性，写写操作和读写操作间依然是需要相互等待和持有锁的。总结如下：

• 读-读不互斥：可并行；

• 读-写互斥；

• 写-写互斥；

  public class ReadWriteLockDemo {
     private static Lock lock = new ReentrantLock();
     private static ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
     private static Lock readLock = readWriteLock.readLock();
     private static Lock writeLock = readWriteLock.writeLock();
     private int value;
  
     public Object handleRead(Lock lock) throws InterruptedException {
        try {
           lock.lock(); // 模拟读操作
           Thread.sleep(1000); // 读操作的耗时越多，读写锁的优势越明显
           System.out.println(Thread.currentThread().getName()+" read end!");
           return value;
        } finally {
           lock.unlock();
        }
     }
  
     public void handleWrite(Lock lock, int index) throws InterruptedException {
        try {
           lock.lock(); // 模拟写操作
           Thread.sleep(1000);
           System.out.println(Thread.currentThread().getName()+"  wrait end!");
           value = index;
        } finally {
           lock.unlock();
           System.out.println(value);
        }
     }
  
     public static void main(String[] args) {
        // TODO Auto-generated method stub
        final ReadWriteLockDemo demo = new ReadWriteLockDemo();
        Runnable readRunnable = () -> {
           // TODO Auto-generated method stub
           try {
              demo.handleRead(readLock);
              // demo.handleRead(lock);
           } catch (InterruptedException e) {
              // TODO Auto-generated catch block
              e.printStackTrace();
           }
        };
        Runnable writeRunnable = () -> {
           // TODO Auto-generated method stub
           try {
              demo.handleWrite(writeLock, new Random().nextInt());
              // demo.handleWrite(lock, new Random().nextInt());
           } catch (InterruptedException e) {
              // TODO Auto-generated catch block
              e.printStackTrace();
           }
  
        };
        for (int i = 0; i < 18; i++) {
           new Thread(readRunnable).start();	//1
        }
        for (int i = 18; i < 20; i++) {
           new Thread(writeRunnable).start();	//2
        }
     }
  }
  

上面代码中，读和写的线程使用耗时的操作来模拟，在1处开启同时读的线程，可以从结果看出读的速度可以是并行的，而2处则不行。

倒计时锁：CountDownLatch

这个工具称为倒计数器：通常用来控制线程等待，它可以让某一个线程等待直到倒计时结束，再开始执行。

使用场景：比如火箭就很适合使用CountDownLatch。火箭发射前，往往要进行各项设备、仪器检查，只有检查完毕后，引擎才能点火。

CountDownLatch的构造函数接收一个整数，即当前这个计数器的计数个数：

public CountDownLatch(int count)

演示：

public class CountDownLatchDemo implements Runnable {
    static final CountDownLatch end = new CountDownLatch(10);	//1
    static final CountDownLatchDemo demo = new CountDownLatchDemo();	

    @Override
    public void run() {
        try {
            //模拟检查任务
            Thread.sleep(new Random().nextInt(10) * 1000);
            System.out.println("check complete");
            end.countDown();	//2
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        ExecutorService exec = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 10; i++) {
            exec.submit(demo);
        }
        //等待检查
        end.await();	//3
        //发射火箭
        System.out.println("Fire!");
        exec.shutdown();
    }
}

在1处，生成一个CountDownLatch，计数数量为10，表示需要10个线程完成任务，等待在CountDownLatch上的线程才能继续执行。2处表示一个线程已完成，计数器减一。在3处，要求主线程等待10个线程全部完成任务后，主线程才继续执行。

主线程在CountDownLatch上等待，当所有检查任务全部完成后，主线程方能继续执行。

循环栅栏：CyclicBarrier

循环栅栏（CyclicBarrier）和倒计时锁（CountDownLatch）非常类似：只是循环栅栏的计数器可以反复使用。比如假设我们将计数器设置为10，那么凑齐第一批10个线程后，计数器就会归零，然后接着凑齐下一批10个线程，这就是循环栅栏的内在含义。

使用场景：比如司令下达命令，要10个士兵去完成一项任务，士兵要先集合报道完，接着去执行任务。当10个士兵把手头任务都执行完成了，司令才能对象宣布，任务完成！

这里有两步：1，士兵集合报道；2，士兵把任务完成。当这两步先后完成，司令才认为任务完成。

构造函数：比CountDownLatch稍微强大一些。CyclicBarrier可以接收一个参数作为barrierAction（系统当计数器一次计数完成后，系统会执行的动作）：

public class CyclicBarrierDemo {
    public static class Soldier implements Runnable {
        private String soldier;
        private final CyclicBarrier cyclic;

        Soldier(CyclicBarrier cyclic, String soldierName) {
            this.cyclic = cyclic;
            this.soldier = soldierName;
        }

        public void run() {
            try {
              	//士兵报道
                System.out.println(soldier + " 报道");
                //等待所有士兵到齐
                cyclic.await();		//2
                doWork();
                //等待所有士兵完成任务
                cyclic.await();		//3
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (BrokenBarrierException e) {
                e.printStackTrace();
            }
        }

        void doWork() {
            try {
                Thread.sleep(Math.abs(new Random().nextInt() % 10000));
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println(soldier + ":任务完成");
        }
    }

    public static class BarrierRun implements Runnable {
        boolean flag;
        int N;

        public BarrierRun(boolean flag, int N) {
            this.flag = flag;
            this.N = N;
        }

        public void run() {
            if (flag) {
                System.out.println("司令:[士兵" + N + "个,任务完成!]");
            } else {
                System.out.println("司令:[士兵" + N + "集合完毕]");
                flag = true;
            }
        }
    }

    public static void main(String args[]) {
        final int N = 10;
        Thread[] allSoldier = new Thread[N];
        boolean flag = false;
        CyclicBarrier cyclic = new CyclicBarrier(N, new BarrierRun(flag, N));	//1
        //设置屏障点,主要是为了执行这个方法
        System.out.println("队伍集合");
        for (int i = 0; i < N; ++i) {
            allSoldier[i] = new Thread(new Soldier(cyclic, "士兵 " + i));
            allSoldier[i].start();	//4
        }
    }
}

在1处，创建了CyclicBarrier实例，并将计数器设置为10，并要求在计数器达到指标时，执行BarrierRun。在2处，每一个士兵线程都会等待，知道所有士兵集合完毕，集合完毕后，意味着CyclicBarrier的一次计数完成，当再一次调用CyclicBarrier()时，会进行下一次计数。在3处，会等待所有士兵完成任务。还可以第三次第四次调用 cyclic.await();

整个工作过程图示：

CyclicBarrier.await可能会抛出两个异常，第一是中断异常，可以响应外部紧急事件。大部分迫使线程等待的方法都可能抛出这个异常。第二是它特有的BrokenBarrierException，这个异常说明当前的CyclicBarrier已经破损了，可能没有办法等待所有线程到齐了。如果继续等待，就白等了。

可以在4处上方插入：

if (i == 5)
    allSoldier[0].interrupt();

这样做，我们可以得到1个中断异常和9个BrokenBarrierException，1个士兵处于中断，其他9个需要等待这个线程，抛出BrokenBarrierException可以避免其他9个线程进行永久的，无谓的等待。

线程阻塞工具类：LockSupport

LockSupport是一个很实用的线程阻塞工具，可以在线程的任何位置让线程阻塞。

和Thread.suspend()相比，它尼补了由于resume()在前生成的导致线程无法继续执行的问题。和Object.wait()相比，它不需要先获得某个对象锁，也不会抛出InterruptedException。

public class LockSupportDemo {
   public static Object u = new Object();
   static ChangeObjectThread t1 = new ChangeObjectThread("t1");
   static ChangeObjectThread t2 = new ChangeObjectThread("t2");

   public static class ChangeObjectThread extends Thread {
      public ChangeObjectThread(String name){
         super.setName(name);
      }
      @Override
      public void run() {
         synchronized (u) {
            System.out.println("in "+getName());
            LockSupport.park(this);		//1
         }
      }
   }
   public static void main(String[] args) throws InterruptedException {
      t1.start();
      Thread.sleep(1000);
      t2.start();
      LockSupport.unpark(t1);		//2
      LockSupport.unpark(t2);		//3
      t1.join();
      t2.join();
   }
}

我们将原来的suspend和resume方法用park()和unpark()代替，在1处，我们挂起了当前线程，在2处，我们分别继续执行t1和t2，从结果可以看出，它不会因为unpark在park执行前而导致线程永久挂起。

为什么LockSupport不会导致线程永久挂起？

因为LockSupport使用了类似信号量的机制（不同的是不能累加），它为每个线程准备了一个许可。

• 若许可可用—>park()会立即返回，将许可变为不可用—>线程阻塞；
• 调用unpark()—>使许可变为可用

这个特点使得：即使unpark()操作发生在park()之前，它也可以使下一次park()操作立即返回。这就是不会导致线程永久挂起的原因。

同时，处于park()挂起状态的线程不会像suspend()那样给出令人费解的Runnable状态，它会非常明确的给出一个WAITING状态，甚至会标注是park()引起的。这让问题很容易分析。

LockSupport除了阻塞功能外，还支持中断响应。但是和其他接收中断的函数不一样，它不抛出中断异常，而是默默返回，但可以从Thread.interrupted()等方法获得中断标记。

public class LockSupportIntDemo {
  public static Object u = new Object();
  static ChangeObjectThread t1 = new ChangeObjectThread("t1");
  static ChangeObjectThread t2 = new ChangeObjectThread("t2");

  public static class ChangeObjectThread extends Thread {
      public ChangeObjectThread(String name) {
          super.setName(name);
      }

      public void run() {
          synchronized (u) {
              System.out.println("in " + getName());
              LockSupport.park();
              if (Thread.interrupted()) {
                  System.out.println(getName() + " 被中断了!");
              }
          }
          System.out.println(getName() + " 执行结束");
      }
  }

  public static void main(String[] args) throws InterruptedException {
      t1.start();
      Thread.sleep(100);
      t2.start();
      t1.interrupt();
      LockSupport.unpark(t2);
  }
}

线程复用：线程池

多线程在多核的处理下有助于性能，但如果不加控制的使用线程，反而会对系统性能产生不利影响。

为什么会造成不利影响？

1. 线程创建和关闭需要花费时间，少数不要紧，系统级别的（线程很多的）就很耗时了。
2. 线程本身需要占用内存。有抛出out of memory的危险

在实际生产环境中，线程的数量必须得到控制。

什么是线程池

联想一下数据库连接池，就知道线程池是啥了。

在线程池中，总有那么几个活跃的线程。当需要时，就从池中取出空闲线程，当完成工作后，再还回去，方便其他人使用。

JDK对线程池的支持

JDK提供了一套Executor框架，用来对线程池的支持。它的核心成员如下：

上面是jdk并发包的核心类。其中ThreadPoolExecutor表示一个线程池。Excecutor扮演线程池工厂的角色，通过它可以取得一个拥有特定功能的线程池。

Executors提供了各种类型的线程池：

线程池类型	作用
newFixedThreadPool()	返回固定线程数量的线程池。线程池中线程数量保持不变。有新任务时，有空闲线程，则执行。若没有则暂存一个任务队列，等到有空闲线程，再执行
newSingleThreadExecutor()	返回只有一个线程的线程池。若有多余任务提交线程池，则存入任务队列，待线程空闲，按先入先出的顺序执行任务队列中的任务。
newCachedThreadPool()	返回一个可根据实际情况调整线程数量的线程池。若有空闲线程可用，则用空闲线程。若没有，创建新的线程处理任务。所有线程完成任务后，将返回线程池进行复用。
newSingleThreadScheduledExecutor()	返回一个ScheduleExecutorService对象，线程池大小为1。它会在给定时间执行某任务。如在固定延时之后，或周期性执行某个任务
newScheduledThreadPool()	返回ScheduleExecutorService对象，但可以指定线程池数量

1、固定大小的线程池

以newFixedThreadPool()为例，简单展示线程池的使用：

public class ThreadPoolDemo {
   public static class MyTask implements Runnable {
      @Override
      public void run() {
         System.out.println(System.currentTimeMillis() + ":Thread ID:"
               + Thread.currentThread().getId());
         try {
            Thread.sleep(1000);
         } catch (InterruptedException e) {
            e.printStackTrace();
         }
      }
   }

   public static void main(String[] args) {
      MyTask task = new MyTask();
      ExecutorService es = Executors.newFixedThreadPool(5);		//1
      for (int i = 0; i < 10; i++) {
         es.submit(task);	//2
      }
   }
}

在1处，创建了一个固定大小的线程池，内有5个线程。在2处，依次向线程池提交了10个任务。

上面程序，前5个任务和后5个任务的执行时间正好相差1秒。

2、计划任务

newScheduledThreadPool()。它返回一个ScheduledExecutorService对象，可以根据时间需要进行调度，它其实起到了计划任务的作用。它的一些主要方法如下：

public ScheduledFuture<?> schedule(Runnable command, long delay,
          TimeUnit unit);
public ScheduledFuture<?> scheduleAtFixedRate(Runnable command,
          long initialDelay, long period, TimeUnit unit);
public ScheduledFuture<?> scheduleWithFixedDelay(Runnable command,
          long initialDelay, long delay, TimeUnit unit);

scheduleAtFixedRate()和scheduleWithFixedDelay()都会对任务进行周期性调度，不过它们有小小区别：

下面是scheduleAtFixedRate()的例子，任务执行1秒，调用周期2秒。即每2秒，任务会被执行一次。

public class ScheduledExecutorServiceDemo {
   public static void main(String[] args) {
      ScheduledExecutorService ses = Executors.newScheduledThreadPool(10);
      ses.scheduleAtFixedRate(new Runnable() {
         @Override
         public void run() {
            try {
               Thread.sleep(1000);
               System.out.println(System.currentTimeMillis()/1000);
            } catch (InterruptedException e) {
               e.printStackTrace();
            }
         }
      }, 0, 2, TimeUnit.SECONDS);
   }
}

上面的执行结果是每次打印时间间隔为2秒。

那如果任务的执行时间超过调度时间，会发生什么呢？会出现堆叠的情况吗，不会，若出现这种情况，任务的周期将变成8秒，即任务完成那一刻才开始下一次任务的调度。

如果采用scheduleWithFixedDelay()，任务的实际间隔将是10秒。

刨根究底：核心线程池的内部实现

对于核心的几个线程池，其内部都使用了ThreadPoolExecutor实现。这里就不给出它们的实现方式了。

下面是ThreadPoolExecutor最重要的构造函数：

public ThreadPoolExecutor(int corePoolSize,
                          int maximumPoolSize,
                          long keepAliveTime,
                          TimeUnit unit,
                          BlockingQueue<Runnable> workQueue,
                          ThreadFactory threadFactory,
                          RejectedExecutionHandler handler)

参数含义：

• corePoolSize：指定线程池中的线程数量。
• maximumPoolSize：指定了线程池中的最大线程数量。
• keepAliveTime：超过corePoolSize的空闲线程，在多长时间内，会被销毁。
• unit：keepAliveTime的单位。
• workQueue：任务队列，被提交但尚未被执行的任务。
• threadFactory：线程工厂，用来创建线程，用默认的即可。
• handler：拒绝策略。太多任务而处理不及时，如何拒绝任务。

参数workQueue：被提交但未被执行的任务队列，它是一个BlockingQueue接口的对象，仅用于存放Runnable对象。ThreadPoolExecutor的构造函数中可以使用下面几种BlockingQueue：

• 直接提交的队列：该功能由SynchronousQueue提供。SynchronousQueue没有容量，若使用它，提交的任务不会被真实的保存，而总是将任务提交给线程执行。若没有空线程，则创建；若线程数量达到顶峰，则执行拒绝策略。通常，使用SynchronousQueue需要很大的maximumPoolSize值，否则很容易执行拒绝策略。

• 有界的任务队列：可以使用ArrayBlockingQueue实现。它的构造函数必须带一个容量参数，表示最大容量。若实际线程数小于corePoolSize，则优先创建新线程，若大于corePoolSize，则将新任务加入等待队列。若等待队列已满，在总线程数<=maximumPoolSize的前提下，创建新的进行执行任务。若>maximumPoolSize，执行拒绝策略。

  可见，有界队列仅在任务队列装满时，才肯呢过将线程数提升至corePoolSize以上。换句话说，除非系统非常繁忙，否则核心线程数维持在corePoolSize。

• 无界的任务队列：可通过LinkedBlockingQueue实现。与有界队列相比，除非系统资源耗尽，否则无界队列不存在任务入队失败的情况。

  当系统线程数<corePoolSize，创建新线程；

  若>=corePoolSize，不增加新线程，加入等待队列，若任务创建和处理速度差异太大，无界队列会保持快速增长，知道耗尽系统内存。

• 优先任务队列（带有执行优先级的队列）：通过PriorityBlockingQueue实现，可以控制任务的执行前后顺序。高优先级的任务线执行。

回顾一下：

newFixedThreadPool()方法：它的corePoolSize和maximumPoolSize大小一样，因为固定大小的线程池不存在线程数量的动态变化。同时，它使用无界队列存放任务列表，从而在任务提交频繁的情况下有可能耗尽系统资源。

newSingleThreadExecutor()返回单线程线程池，是newFixedThreadPool()的退化，只是简单将线程数设为1。

newCachedThreadPool()方法返回corePoolSize为0，maximumPoolSize无穷大的线程池。刚开始该线程池无线程，它会将提交的线程加入SynchronousQueue，这是一种立即提交的队列，它会迫使线程池增加新的线程执行任务。当任务执行完毕，在60秒内将线程池不用的线程回收（不留任何空闲线程）。因此，当同时有大量任务提交时，任务执行又不快，那么系统便会开启灯亮线程处理，很快就会耗尽系统资源。

超负载了？使用拒绝策略

JDK内置的拒绝策略：

• AbortPolicy策略：该策略会直接抛出异常，阻止系统正常工作。
• CallerRunsPolicy策略：只要线程池未关闭，该策略直接在调用者线程中，运行当前被丢弃的线程。显然，不会真正丢弃任务，但是，任务提交线程的性能可能急剧下降。
• DiscardOledestPolicy策略：该策略将丢弃最老的一个请求，即将要执行的一个任务，并尝试再次提交当前任务。
• DiscardPolicy策略：该策略默默丢弃无法处理的任务，不予任何处理。（若允许丢失，可能是最好的一种方式了）

可以自己扩展RejectedExecutionHandle接口实现自己的拒绝策略，下面代码简单演示了自定义线程池和拒绝策略的使用：

public class RejectThreadPoolDemo {
   public static class MyTask implements Runnable {
      @Override
      public void run() {
         System.out.println(System.currentTimeMillis() + ":Thread ID:"
               + Thread.currentThread().getId());
         try {
            Thread.sleep(100);
         } catch (InterruptedException e) {
            e.printStackTrace();
         }
      }
   }

   public static void main(String[] args) throws InterruptedException {
      MyTask task = new MyTask();
      ExecutorService es = new ThreadPoolExecutor(5, 5,
                0L, TimeUnit.MILLISECONDS,
                new SynchronousQueue<Runnable>(),
                Executors.defaultThreadFactory(),
                new RejectedExecutionHandler(){
               @Override
               public void rejectedExecution(Runnable r,
                     ThreadPoolExecutor executor) {
                  System.out.println(r.toString()+" is discard");
               }
      });		//1
      for (int i = 0; i < Integer.MAX_VALUE; i++) {
         es.submit(task);
         Thread.sleep(10);
      }
   }
}

上述1处自定义了一个线程池。该线程池有5个常驻线程，并且最大线程数量也是5个。这和固定大小的线程池是一样的。但是它却拥有一个只有10个容器的等待队列。在这里，我们自定义了拒绝策略，只是比DiscardPolicy高级一点点，把拒绝的信息打印出来，在实际应用中，我们可以将其记录到日志上。用来分析系统的负载和任务丢失情况。

自定义线程创建：ThreadFactory

线程池的主要作用是为了线程复用，也就是避免了线程的频繁创建。但是，线程池最开始的线程从何而来呢？答案就是ThreadFactory。

ThreadFactory是一个接口，它只有一个方法，用来创建线程：

Thread newThread(Runnable r);

当线程池需要新建线程时，就会调用这个方法。

我们使用自定义线程可以更自由地设置池子中所有线程的状态，甚至可以设置为守护线程：

public class TFThreadPoolDemo {
   public static class MyTask implements Runnable {
      @Override
      public void run() {
         System.out.println(System.currentTimeMillis() + ":Thread ID:"
               + Thread.currentThread().getId());
         try {
            Thread.sleep(100);
         } catch (InterruptedException e) {
            e.printStackTrace();
         }
      }
   }

   public static void main(String[] args) throws InterruptedException {
      MyTask task = new MyTask();
      ExecutorService es = new ThreadPoolExecutor(5, 5,
                0L, TimeUnit.MILLISECONDS,
                new SynchronousQueue<Runnable>(),
                new ThreadFactory(){
                   @Override
                   public Thread newThread(Runnable r) {
                      Thread t= new Thread(r);
                      t.setDaemon(true);
                      System.out.println("create "+t);
                      return t;
                   }
            	}
               );
      for (int i = 0; i < 5; i++) {
         es.submit(task);
      }
      Thread.sleep(2000);
   }
}

扩展线程池

虽然JDK已经帮我们实现了这个稳定的高性能线程池。但如果我们需要对线程池进行一些扩展。比如，想监控每个任务执行的开始和结束时间，或者其他一些自定义增强功能，怎么办呢？

ThreadPoolExecutor：它也是一个可以扩展的线程池。它提供了beforeExecute()、afterExecute()和terminated()三个接口对线程池进行控制。

在默认的ThreadPoolExecutor实现中，提供了空的beforeExecute()、afterExecute()实现。在实际引用中，可以对其扩展实现对线程池运行状态的跟踪，输出一些有用的调试信息，用以帮助系统故障诊断。下面演示对线程池的扩展，在这个扩展中，将记录每一个任务的执行日志：

public class ExtThreadPool {
    public static class MyTask implements Runnable {
        public String name;

        public MyTask(String name) {
            this.name = name;
        }

        @Override
        public void run() {
            System.out.println("正在执行" + ":Thread ID:" + Thread.currentThread().getId()
                    + ",Task Name=" + name);
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
    public static void main(String[] args) throws InterruptedException {
        ExecutorService es = new ThreadPoolExecutor(5, 5, 0L, TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<Runnable>()) {
            @Override
            protected void beforeExecute(Thread t, Runnable r) {
                System.out.println("准备执行：" + ((MyTask) r).name);
            }
            @Override
            protected void afterExecute(Runnable r, Throwable t) {
                System.out.println("执行完成：" + ((MyTask) r).name);
            }
            @Override
            protected void terminated() {
                System.out.println("线程池退出");
            }
        };
        for (int i = 0; i < 5; i++) {
            MyTask task = new MyTask("TASK-GEYM-" + i);
            es.execute(task);
            Thread.sleep(10);
        }
        es.shutdown();
    }
}/**
......
正在执行:Thread ID:13,Task Name=TASK-GEYM-2
准备执行：TASK-GEYM-3
正在执行:Thread ID:14,Task Name=TASK-GEYM-3
准备执行：TASK-GEYM-4
正在执行:Thread ID:15,Task Name=TASK-GEYM-4
执行完成：TASK-GEYM-0
执行完成：TASK-GEYM-1
执行完成：TASK-GEYM-2
执行完成：TASK-GEYM-3
执行完成：TASK-GEYM-4
线程池退出
*/

可以看到，所有任务执行前后都捕获到了。这对于应用的调试和诊断是非常有帮助的。

合理的选择：优化线程池线程数量

线程池的大小对系统的性能有一定的影响。过大或过小的线程数量都无法发挥最优的系统性能。但是也不用做得非常精确，只要避免极大和极小两种情况即可。

堆栈去哪里了：挖出线程池中被淹没的异常堆栈

先说明一下要解决的问题！

public class DivTask implements Runnable {
    int a, b;
    public DivTask(int a, int b) {
        this.a = a;
        this.b = b;
    }
    @Override
    public void run() {
        double re = a / b;		//1
        System.out.println(re);
    }
    public static void main(String[] args) {
        ThreadPoolExecutor pools = new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                0L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
        for(int i=0; i<5; i++)
            pools.submit(new DivTask(100, i));
//            pools.execute(new DivTask(100, i));
    }
}/**
100.0
25.0
50.0
33.0
*/

在上面程序中，只有四个输出结果，少了一个，然而没有报错信息。使用submit会出现这样的情况（execute会抛出异常，具体原因后面再看吧）。

再说下解决方案！

对于程序员来说，没有异常堆栈是最头疼的事。我们可以通过两种方法来讨回异常堆栈：

1 是放弃submit()改用execute()，如注释所示；

pools.execute(new DivTask(100, i));

2 是改造submit()：

 Future<?> submit = pools.submit(new DivTask(100, i));
            submit.get();

以上两种都可以得到部分堆栈信息：

Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.ArithmeticException: / by zero
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at geym.ch3.DivTask.main(DivTask.java:21)
Caused by: java.lang.ArithmeticException: / by zero
	at geym.ch3.DivTask.run(DivTask.java:13)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

注意，上面说的是部分！我们只知道异常是在哪里抛出的，也就是代码的1处，但是不确定线程是在哪里提交的，任务的具体提交的位置被淹没了！

3、自己动手，扩展ThreadPoolExecutor线程池（彻底解决的办法）

为了少加班！我们还是自己动手，把堆栈的信息彻底挖出来吧！扩展我们的ThreadPoolExecutor线程池，让它在调度任务之前，先保存一下提交任务线程的堆栈信息。

public class TraceThreadPoolExecutor extends ThreadPoolExecutor {
   public TraceThreadPoolExecutor(int corePoolSize, int maximumPoolSize,
                           long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue) {
      super(corePoolSize,maximumPoolSize,keepAliveTime,unit,workQueue);
   }
   @Override
   public void execute(Runnable task) {
      // TODO Auto-generated method stub
      super.execute(wrap(task, clientTrace(), Thread.currentThread().getName()));    //包装器
   }
   @Override
   public Future<?> submit(Runnable task) {
      // TODO Auto-generated method stub
      return super.submit(wrap(task, clientTrace(), Thread.currentThread().getName()));
   }
   private Exception clientTrace() {
      return new Exception("Client stack trace");
   }
   private Runnable wrap(final Runnable task,final Exception clientStack, String clientThreadName) {	//1
      return new Runnable() {
         @Override
         public void run() {
            try {
               task.run();
            } catch (Exception e) {
               clientStack.printStackTrace();
               try {
                  throw e;
               } catch (Exception e1) {
                  // TODO Auto-generated catch block
                  e1.printStackTrace();
               }
            }
         }
      };
   }
   public static class DivTask implements Runnable {
      int a,b;
      public DivTask(int a,int b) {
         this.a = a;
         this.b = b;
      }
      @Override
      public void run() {
         double re = a/b;
         System.out.println(re);
      }
   }
   public static void main(String[] args) {
      ThreadPoolExecutor pools = new TraceThreadPoolExecutor(0, Integer.MAX_VALUE,
            0L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
      for(int i=0; i<5; i++)
         pools.execute(new DivTask(100, i));
   }
}

在wrap()（1处）方法的第2个参数为一个异常，里面保存着提交任务的线程的堆栈信息。该方法将我们传入的Runnable任务进行一层包装，使之能处理异常信息。当任务发生异常时，这个异常会被打印。

分而治之：Fork/Join框架

fork()用来开启分支线程来处理任务，一般会提交给ForkJoinPool线程池进行处理，以节省系统资源。

Join()用来等待fork()的执行分支执行结束。

使用Fork/Join进行数据处理时的总体结构如图所示：

由于线程池的优化，提交的任务和线程数量不是一对一的关系。通常是一个线程处理多个任务，每个线程都有一个任务队列。当线程A把任务完成，而线程B还在有一堆任务处理时，线程A会帮助B。B从任务队列顶部拿数据，而A则是从任务队列的底部拿数据，这样有利于避免数据竞争。

ForkJoinPool的一个重要的接口，可以提交一个ForkJoinTask，ForkJoinTask支持fork()分解以及join()等待的任务，它有两个重要子类：RecursiveAction（无返回值）和RecursiveTask（返回v类型）。

public <T> ForkJoinTask<T> submit(ForkJoinTask<T> task);

使用：

public class CountTask extends RecursiveTask<Long> {
    private static final int THRESHOLD = 10000;
    private long start;
    private long end;

    public CountTask(long start, long end) {
        this.start = start;
        this.end = end;
    }

    public Long compute() {
        long sum = 0;
        boolean canCompute = (end - start) < THRESHOLD;
        if (canCompute) {
            //求和总数小于THRESHOLD，直接求和
            for (long i = start; i <= end; i++) {
                sum += i;
            }
        } else {
            //分成100个小任务
            // 比如start=0，end=100，则每一小步计算2个数
            //i=0,lastOne=0+2=2, pos=2+1=3
            //i=1,lastOne=2+2=4, pos=4+1=5
            //...
            //i=100
            long step = (start + end) / 100;    //
            long pos = start;
            for (int i = 0; i < 100; i++) {
                long lastOne = pos + step;
                if (lastOne > end) lastOne = end;
                CountTask subTask = new CountTask(pos, lastOne);
                pos = lastOne + 1;
                subTask.fork();
                sum += subTask.join();
            }
        }
        return sum;
    }

    public static void main(String[] args) {
        ForkJoinPool forkJoinPool = new ForkJoinPool();
        CountTask task = new CountTask(0, 200000L);
        ForkJoinTask<Long> result = forkJoinPool.submit(task);	//1
        try {
            long res = result.get();
            System.out.println("sum=" + res);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
    }
}

在1处，使用forkJoinPool提交了CountTask，CountTask构造一个计算1到200000求和的任务。在compute()方法中，遵循了下面的逻辑：

if (canCompute) {
	//求和总数够小，直接求和
} else {
	//分成若干个小任务
}

在使用ForkJoinPool时需要注意，如果任务的划分层次很深，一直没有返回，可能出现两种情况：

1. 系统内线程数量越积越多，导致性能严重下降。
2. 函数调用层次变得很深，导致栈溢出。

JDK的并发容器

JDK提供了好用的并发容器类，使用也很方便，这里主要讲讲这些工具的具体实现。

并发集合介绍

先简单认识一下并发集合：

• ConcurrentHashMap：高效的并发HashMap。即线程安全的HashMap
• CopyOnWriteArrayList：属于List，和ArrayList是一族的。在读多少写的场合性能非常好，远远好于Vector。
• ConcurrentLinkedQueue：线程安全的LinkedList。
• BlockingQueue：这是一个接口，JDK内部通过链表、数组等方式实现这个接口。表示阻塞队列，非常适合用于作为数据共享的通道。
• ConcurrentSkipListMap：跳表的实现。这是一个Map，使用跳表的数据结构进行快速查找。
• Vector也是线程安全的，另外Collections工具类可以帮助我们将任意集合包装成线程安全的工具类

线程安全的HashMap：ConcurrentHashMap

如果获得一个线程安全的HashMap？

第一种方法是：使用Collections.synchronizedMap()方法来包装HashMap

static Map<String, String> map = Collections.synchronizedMap(new HashMap<String, String>());

Collections.synchronizedMap()会生成一个名为SynchronizedMap的Map。它使用委托，将自己所有Map相关的功能交给传入的HashMap实现，自己则主要负责保证线程安全。

第二种方法是使用ConcurrentHashMap代替HashMap，这种方式更专业，更适合并发场合。

线程安全的List

Vector是线程安全的List，也可以使用Collections.synchronizedList()方法来包装任意List。

高效读写队列：ConcurrentLinkedQueue

ConcurrentLinkedQueue算是高并发中性能最好的队列了。

具体实现：

1、节点

作为一个链表，自然需要定义一个节点：

private static class Node<E>{
	volatile E item;
    volatile Node<E> next;

item用来表示目标元素，比如：放入String，item就是String元素。next表示Node的下一个元素。这样Node就环环相扣，串在一起了。

2、CAS操作

首先，说明一下CAS操作的原理：CAS操作包含三个操作数—— 内存位置的值（V）、预期原值（A）和新值（B）。如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在CAS指令之前返回该位置的值。CAS有效地说明了“我认为位置V应该包含值A；如果包含该值，则将B放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。”

CAS是一种乐观锁。乐观锁在少写的情况下适用，若是多写的情况，会导致CAS算法不断的进行retry，反而降低了系统性能，多写的情况适合适用悲观锁。

casItem()表示设置当前Node的item值。cmp为期望值，第二个参数val为目标值。当当前值等于cmp期望值时，就会将目标值设置为val。第二个方法类似。只是它用来设置next字段。

ConcurrentLinkedQueue内部有两个重要的字段，head和tail，分别表示头部和尾部。tail的更新不是及时的，而是有延迟，每次更新会跳跃两个元素。如下图：

原书中的源码分析我没怎么看懂，有看懂的童鞋欢迎在评论中分享心得

高效读取：不变模式下的CopyOnWriteArrayList

在很多应用场景中，读操作往往会远远大于写操作。所以这种情况下，我们希望读的性能好些，而写的性能差些也无所谓。

我们知道：在读写锁ReadWriteLock中，读读不互斥，而读写，写写是互斥的。

而现在，JDK还提供了另外一个读写工具类，将读取性能发挥到极致CopyOnWriteArrayList，它的读读不阻塞，读写也不会互相阻塞，只有写写需要同步等待。

它是怎么做到读写不阻塞的？

CopyOnWrite在写入操作时，对原有的数据进行复制成一个副本（而不修改原来的数据），将修改的内容写入复制后的副本中。写完后，再用副本替换原来的数据，这样就不会影响读了。

读取的实现：

读取没有任何同步和锁的操作，理由是内部数组array不会发生修改，只会被另外一个array替换。

写人的实现：

public boolean add(E e) {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        Object[] elements = getArray();
        int len = elements.length;
        Object[] newElements = Arrays.copyOf(elements, len + 1);	//1
        newElements[len] = e;//2
        setArray(newElements);//3
        return true;
    } finally {
        lock.unlock();
    }
}

首先，写入操作使用锁，这个锁仅限于控制写-写的情况。重点在1处，进行了内部元素的复制，而生成一个新数组newElements。2处，将新元素增加到数组末尾，然后，将新数组替换老数组，修改就完成了。整个过程不会影响读取，并且读取线程会实时查看到这个修改（array变量是volatile的）

数据共享通道：BlockingQueue

如何实现多个线程间的数据共享呢？比如，线程A希望给线程B发一个消息，用什么方式好呢？

我们希望线程A能够通知到线程B，又希望线程A不知道线程B的存在。这样对于以后线程B的升级或维护，而不用再修改线程A有帮助。为了实现这一点，我们可以使用一个中间件BlockingQueue来实现。它就相当于一个意见箱，用来作为发表意见者与接收意见者沟通的桥梁。

BlockingQueue和之前提到的ConcurrentLinkedQueue和CopyOnWriteArrayList不同，它是一个接口，而不是具体的实现。它的主要实现如下图：

ArrayBlockingQueue：基于数组实现。更适合做有界队列，扩展比较不方便

LinkedBlockingQueue：基于链表。更适合做无界队列，因为其内部元素可动态增加。

BlockingQueue为什么适合作为数据共享的通道呢？原因在于Blocking（阻塞）。

当服务线程（指获取队列中消息并进行处理的线程）处理完队列中所有的消息后，服务线程是如何知道下一条消息的到来的？BlockingQueue会让服务线程在队列为空时，进行等待，当有新的消息进入队列后，自动将线程唤醒。

它是如何工作的？以ArrayBlockingQueue为例说明：

写入数据：

它有一个items，items就是用来存放数据的队列。offer()在列队满时，返回false。我们关注的是put()方法，put()也是将元素压入队列队尾，但队列满了，它会一直等待，直到队列中有空闲位置。

读取数据：

poll()、take()两个方法都能从队列中的头部弹出一个元素。不同的是：如果队列为空poll()方法直接返回null。而take()方法会等待，直到队列内有可用元素。

从上面可以看出，put()、take()方法才是Blocking的关键。为了做好通知和等待两件事，ArrayBlockingQueue定义了三个字段：

take()操作：

当队列为空时，让当前线程等待在notEmpty，新元素入队时，则进行一次notEmpty上的通知。

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        while (count == 0)
            notEmpty.await();	//1
        return dequeue();
    } finally {
        lock.unlock();
    }
}

在1处，要求线程在notEmpty对象中等待。下面是元素入队的一段代码：

/**
 * 在当前put位置插入元素、进给和信号。
 * 只有在持有锁时才调用。
 */
private void enqueue(E x) {
    final Object[] items = this.items;
    items[putIndex] = x;
    if (++putIndex == items.length)
        putIndex = 0;
    count++;
    notEmpty.signal();	//1
}

在1处，当新元素入列后，需要通知等待在notEmpty上的线程，让它们继续工作。

put()操作：

当队列满时，需要让 压入线程 等待：

public void put(E e) throws InterruptedException {
    checkNotNull(e);
    final ReentrantLock lock = this.lock;
    lock.lockInterruptibly();
    try {
        while (count == items.length)
            notFull.await();	//1
        enqueue(e);
    } finally {
        lock.unlock();
    }
}

在1处，队列满时，在notFull对象中等待。

当然，当元素从队列中挪走时，队列中有空位时，自然也要通知等待入队的线程：

private E dequeue() {
    final Object[] items = this.items;
    @SuppressWarnings("unchecked")
    E x = (E) items[takeIndex];
    items[takeIndex] = null;
    if (++takeIndex == items.length)
        takeIndex = 0;
    count--;
    if (itrs != null)
        itrs.elementDequeued();
    notFull.signal();	//1
    return x;
}

我们还会在“5.3 生产者消费者”一节中，看到他们的身影。在那里，我们可以更清楚地看到如何使用BlockingQueue解耦生产者和消费者。

随机数据结构—跳表：SkipList

介绍跳表

除了常用的哈希表外，还有一种有趣的数据结构：跳表。跳表的本质是同时维护了多个链表，并且链表是分层的。跳表的查询性能要比哈希表好。如下图

最低层的链表维护了跳表中所有的元素，每上面一层都是下面一层的子集，一个元素插入哪一层完全随机，运气不好可能得到性能最差的结构。但是实际工作中，它还是表现得很好的。

跳表内所有元素都是排序的。查找时，从顶级链表开始找，一旦发现被查找的元素大于当前链表中的取值，就会转入下一层链表继续查找。比如要查找上面跳表结构中的7。查找过程如下图所示：

跳表显然是一种空间换时间的算法。

使用跳表实现的Map和使用哈希算法实现的Map的另一个不同之处是：跳表实现的Map是会排序的，而哈希实现的Map不排序。若需要一个有序的Map，那就选择跳表。

使用:ConcurrentSkipListMap

实现这一数据结构的类是ConcurrentSkipListMap。简单使用:

Map<Integer, Integer> map = new ConcurrentSkipListMap<>();
for (int i = 0; i<30; i++)
    map.put(i,i);
for (Map.Entry<Integer, Integer> entry: map.entrySet()
     ) {
    System.out.println(entry.getKey());
}

跳表有三个关键的数据结构组成：

• Node<K,V>：（节点，含有key、value、next元素，对Node的所有操作，都使用CAS方法）
• Index<K,V>：（表示索引，它的内部包装了node，同时增加了向下和向右的引用），整个跳表就是根据Index进行全网的组织的。
• HeadIndex：表示链表头部的第一个Index。它继承自Index。

下面是三种数据结构的代码：