Java高并发编程学习（三）java.util.concurrent包

深藏阁楼爱情的钟 2023-07-07 08:56 9阅读 0赞

### 简介 ###

我们已经学习了形成Java并发程序设计基础的底层构建块，**但对于实际编程来说，应该尽可能远离底层结构。使用由并发处理的专业人士实现的较高层次的结构要方便得多、要安全得多**。例如，对于许多线程问题，可以通过使用一个或多个队列以优雅且安全的方式将其形式化。生产者线程向队列插人元素，消费者线程则取出它们。使用队列，可以安全地从一个线程向另 一个线程传递数据。**从Java 5开始，引入了一个高级的处理并发的java.util.concurrent包，它提供了大量更高级的并发功能，能大大简化多线程程序的编写**。

### ReentrantLock ###

Java语言直接提供了synchronized关键字用于加锁，但这种锁一是很重，二是获取时必须一直等待，没有额外的尝试机制。java.util.concurrent.locks包提供的ReentrantLock用于替代synchronized加锁，我们来看一下传统的synchronized代码：

public class Counter {
        private int count;
        public void add(int n) {
            synchronized(this) {
                count += n;
            }
        }
    }

用ReentrantLock替代：

public class Counter {
        private final Lock lock = new ReentrantLock();
        private int count;
    
        public void add(int n) {
            lock.lock();
            try {
                count += n;
            } finally {
                lock.unlock();
            }
        }
    }

因为synchronized是Java语言层面提供的语法，所以我们不需要考虑异常，而ReentrantLock是Java代码实现的锁，我们就必须先获取锁，然后在finally中正确释放锁。**把解锁操作括在 finally 子句之内是至关重要的。如果在临界区的代码抛出异常， 锁必须被释放。否则， 其他线程将永远阻塞**。和synchronized不同的是，ReentrantLock可以尝试获取锁：

if (lock.tryLock(1, TimeUnit.SECONDS)) {
        try {
            ...
        } finally {
            lock.unlock();
        }
    }

上述代码在尝试获取锁的时候，最多等待1秒。如果1秒后仍未获取到锁，tryLock()返回false，程序就可以做一些额外处理，而不是无限等待下去。所以，使用ReentrantLock比直接使用synchronized更安全，线程在tryLock()失败的时候不会导致死锁。

### Condition ###

Condition对象来实现wait和notify的功能，把前面用synchronized实现的功能通过ReentrantLock和Condition来实现：

class TaskQueue {
        private final Lock lock = new ReentrantLock();
        private final Condition condition = lock.newCondition();// 由lock对象返回Condition对象
        private Queue<String> queue = new LinkedList<>();
    
        public void addTask(String s) {
            lock.lock();
            try {
                queue.add(s);
                condition.signalAll();
            } finally {
                lock.unlock();
            }
        }
    
        public String getTask() {
            lock.lock();
            try {
                while (queue.isEmpty()) {
                    condition.await();
                }
                return queue.remove();
            } finally {
                lock.unlock();
            }
        }
    }

可见，使用Condition时，引用的Condition对象必须从Lock实例的newCondition()返回，这样才能获得一个绑定了Lock实例的Condition实例。**Condition提供的await()、signal()、signalAll()原理和synchronized锁对象的wait()、notify()、notifyAll()是一致的，并且其行为也是一样的**：

*  await()会释放当前锁，进入等待状态；
 *  signal()会唤醒某个等待线程；
 *  signalAll()会唤醒所有等待线程；
 *  唤醒线程从await()返回后需要重新获得锁。

**注意使用signalAll()和notifyAll()一样，要比signal()和wait()安全，因为signal()和wait()是随机解除等待集中某一个线程的阻塞状，这比解除所有线程的阻塞更加有效，但也存在危险。如果随机选择的线程发现自己仍然不能运行， 那么它再次被阻塞。如果没有其他线程再次调用signal, 那么系统就死锁了，死锁是没有办法解除的，除非结束程序**。那么应该何时调用 signalAll 呢？ 经验上讲， 在对象的状态有利于等待线程的方向改变时调用 signalAll。此外，和tryLock()类似，await()可以在等待指定时间后，如果还没有被其他线程通过signal()或signalAll()唤醒，可以自己醒来：

if (condition.await(1, TimeUnit.SECOND)) {
        // 被其他线程唤醒
    } else {
        // 指定时间内没有被其他线程唤醒
    }

那么我们学了 Lock/Condition 和 synchronized 关键字两种方式，那么到底选用谁好呢？答案是：**在可选的情况下，最好既不使用 Lock/Condition 也不使用 synchronized 关键字。在许多情况下你可以使 用java.util.concurrent 包中的一种机制，它会为你处理所有的加锁**。自己编写并发锁的时候可能会有各种各样的问题，所以建议尽量选择已经编写好的工具包！

### ReadWriteLock ###

有时线程锁保护的有点过头了，其实，只有修改数据才必须获取锁，获取数据可以允许多个线程同时调用，实际上我们想要的是：**允许多个线程同时读，但只要有一个线程在写，其他线程就必须等待**：  
![在这里插入图片描述][20200222182725412.png]  
使用ReadWriteLock可以解决这个问题，它保证：

*  只允许一个线程写入（其他线程既不能写入也不能读取）；
 *  没有写入时，多个线程允许同时读（提高性能）。

用ReadWriteLock实现这个功能十分容易。我们需要创建一个ReadWriteLock实例，然后分别获取读锁和写锁：把读写操作分别用读锁和写锁来加锁，在读取时，多个线程可以同时获得读锁，这样就大大提高了并发读的执行效率。

public class Counter {
        private final ReadWriteLock rwlock = new ReentrantReadWriteLock();
        private final Lock rlock = rwlock.readLock();
        private final Lock wlock = rwlock.writeLock();
        private int[] counts = new int[10];
    
        public void inc(int index) {
            wlock.lock(); // 加写锁
            try {
                counts[index] += 1;
            } finally {
                wlock.unlock(); // 释放写锁
            }
        }
    
        public int[] get() {
            rlock.lock(); // 加读锁
            try {
                return Arrays.copyOf(counts, counts.length);
            } finally {
                rlock.unlock(); // 释放读锁
            }
        }
    }

**使用ReadWriteLock时，适用条件是同一个数据，有大量线程读取，但仅有少数线程修改**。

### StampedLock ###

深入分析ReadWriteLock，会发现它有个潜在的问题：如果有线程正在读，写线程需要等待读线程释放锁后才能获取写锁，即读的过程中不允许写，这是一种悲观锁。要进一步提升并发执行效率，Java 8引入了新的读写锁：StampedLock  
**StampedLock和ReadWriteLock相比，改进之处在于：读的过程中也允许获取写锁后写入！这样一来，我们读的数据就可能不一致，所以，需要一点额外的代码来判断读的过程中是否有写入，这种读锁是一种乐观锁**。  
乐观锁的意思就是乐观地估计读的过程中大概率不会有写入，因此被称为乐观锁。反过来，悲观锁则是读的过程中拒绝有写入，也就是写入必须等待。显然乐观锁的并发效率更高，但一旦有小概率的写入导致读取的数据不一致，需要能检测出来，再读一遍就行。

public class Point {
        private final StampedLock stampedLock = new StampedLock();
    
        private double x;
        private double y;
    
        public void move(double deltaX, double deltaY) {
            long stamp = stampedLock.writeLock(); // 获取写锁
            try {
                x += deltaX;
                y += deltaY;
            } finally {
                stampedLock.unlockWrite(stamp); // 释放写锁
            }
        }
    
        public double distanceFromOrigin() {
            long stamp = stampedLock.tryOptimisticRead(); // 获得一个乐观读锁
            // 注意下面两行代码不是原子操作
            // 假设x,y = (100,200)
            double currentX = x;
            // 此处已读取到x=100，但x,y可能被写线程修改为(300,400)
            double currentY = y;
            // 此处已读取到y，如果没有写入，读取是正确的(100,200)
            // 如果有写入，读取是错误的(100,400)
            if (!stampedLock.validate(stamp)) { // 检查乐观读锁后是否有其他写锁发生
                stamp = stampedLock.readLock(); // 获取一个悲观读锁
                try {
                    currentX = x;
                    currentY = y;
                } finally {
                    stampedLock.unlockRead(stamp); // 释放悲观读锁
                }
            }
            return Math.sqrt(currentX * currentX + currentY * currentY);
        }
    }

和ReadWriteLock相比，写入的加锁是完全一样的，不同的是读取。注意到首先我们通过tryOptimisticRead()获取一个乐观读锁，并返回版本号。接着进行读取，读取完成后，我们通过validate()去验证版本号，如果在读取过程中没有写入，版本号不变，验证成功，我们就可以放心地继续后续操作。如果在读取过程中有写入，版本号会发生变化，验证将失败。在失败的时候，我们再通过获取悲观读锁再次读取。由于写入的概率不高，程序在绝大部分情况下可以通过乐观读锁获取数据，极少数情况下使用悲观读锁获取数据。  
可见，**StampedLock把读锁细分为乐观读和悲观读，能进一步提升并发效率。但这也是有代价的：一是代码更加复杂，二是StampedLock是不可重入锁，不能在一个线程中反复获取同一个锁**。

### Concurrent集合 ###

针对List、Map、Set、Deque等，java.util.concurrent包提供了对应的并发集合类。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70]  
使用这些并发集合与使用非线程安全的集合类完全相同。我们以ConcurrentHashMap为例：

Map<String, String> map = ConcurrentHashMap<>();
    // 在不同的线程读写:
    map.put("A", "1");
    map.put("B", "2");
    map.get("A", "1");

**因为所有的同步和加锁的逻辑都在集合内部实现，对外部调用者来说，只需要正常按接口引用，其他代码和原来的非线程安全代码完全一样**。java.util.Collections工具类还提供了一个旧的线程安全集合转换器，可以这么用：

Map unsafeMap = new HashMap();
    Map threadSafeMap = Collections.synchronizedMap(unsafeMap);

但是它实际上是用一个包装类包装了非线程安全的Map，然后对所有读写方法都用synchronized加锁，这样获得的线程安全集合的性能比java.util.concurrent集合要低很多，所以不推荐使用。**尽量使用Java标准库提供的并发集合，避免自己编写同步代码**。

### Atomic ###

Java的java.util.concurrent包除了提供底层锁、并发集合外，还提供了一组原子操作的封装类，它们位于java.util.concurrent.atomic包。  
我们以AtomicInteger为例，它提供的主要操作有：

*  增加值并返回新值：int addAndGet(int delta)
 *  加1后返回新值：int incrementAndGet()
 *  获取当前值：int get()
 *  用CAS方式设置：int compareAndSet(int expect, int update)

**Atomic类是通过无锁（lock-free）的方式实现的线程安全（thread-safe）访问。它的主要原理是利用了CAS：Compare and Set**。  
CAS是指，在这个操作中，如果AtomicInteger的当前值是prev，那么就更新为next，返回true。如果AtomicInteger的当前值不是prev，就什么也不干，返回false。通过CAS操作并配合do … while循环，即使其他线程修改了AtomicInteger的值，最终的结果也是正确的。  
我们利用AtomicLong可以编写一个多线程安全的全局唯一ID生成器：

class IdGenerator {
        AtomicLong var = new AtomicLong(0);
    
        public long getNextId() {
            return var.incrementAndGet();
        }
    }

通常情况下，我们并不需要直接用do … while循环调用compareAndSet实现复杂的并发操作，而是用incrementAndGet()这样的封装好的方法，因此，使用起来非常简单。在高度竞争的情况下，还可以使用Java 8提供的LongAdder和LongAccumulator。

### 线程池 ###

Java语言虽然内置了多线程支持，启动一个新线程非常方便，但是，创建线程需要操作系统资源（线程资源，栈空间等），频繁创建和销毁大量线程需要消耗大量时间。**简单地说，线程池内部维护了若干个线程，没有任务的时候，这些线程都处于等待状态。如果有新任务，就分配一个空闲线程执行。如果所有线程都处于忙碌状态，新任务要么放入队列等待，要么增加一个新线程进行处理**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 1]  
Java标准库提供了ExecutorService接口表示线程池

// 创建固定大小的线程池:
    ExecutorService executor = Executors.newFixedThreadPool(3);
    // 提交任务:
    executor.submit(task1);
    executor.submit(task2);
    executor.submit(task3);
    executor.submit(task4);
    executor.submit(task5);

**因为ExecutorService只是接口，Java标准库提供的几个常用实现类有**：

*  FixedThreadPool：线程数固定的线程池；
 *  CachedThreadPool：线程数根据任务动态调整的线程池；
 *  SingleThreadExecutor：仅单线程执行的线程池。

创建这些线程池的方法都被封装到Executors这个类中。我们以FixedThreadPool为例，看看线程池的执行逻辑：

import java.util.concurrent.*;
    
    public class Main {
        public static void main(String[] args) {
            // 创建一个固定大小的线程池:
            ExecutorService es = Executors.newFixedThreadPool(4);
            for (int i = 0; i < 6; i++) {
                es.submit(new Task("" + i));
            }
            // 关闭线程池:
            es.shutdown();
        }
    }
    
    class Task implements Runnable {
        private final String name;
    
        public Task(String name) {
            this.name = name;
        }
    
        @Override
        public void run() {
            System.out.println("start task " + name);
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
            }
            System.out.println("end task " + name);
        }
    }

线程池在程序结束的时候要关闭。使用shutdown()方法关闭线程池的时候，它会等待正在执行的任务先完成，然后再关闭。shutdownNow()会立刻停止正在执行的任务，awaitTermination()则会等待指定的时间让线程池关闭。如果我们把线程池改为CachedThreadPool，由于这个线程池的实现会根据任务数量动态调整线程池的大小，所以6个任务可一次性全部同时执行。如果我们想把线程池的大小限制在4～10个之间动态调整怎么办？

int min = 4;
    int max = 10;
    ExecutorService es = new ThreadPoolExecutor(min, max,
            60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());

还有一种任务，需要定期反复执行，例如，每秒刷新证券价格。这种任务本身固定，需要反复执行的，可以使用ScheduledThreadPool。放入ScheduledThreadPool的任务可以定期反复执行。创建一个ScheduledThreadPool仍然是通过Executors类：

ScheduledExecutorService ses = Executors.newScheduledThreadPool(4);

我们可以提交一次性任务，它会在指定延迟后只执行一次：

// 1秒后执行一次性任务:
    ses.schedule(new Task("one-time"), 1, TimeUnit.SECONDS);

如果任务以固定的每3秒执行，我们可以这样写：

// 2秒后开始执行定时任务，每3秒执行:
    ses.scheduleAtFixedRate(new Task("fixed-rate"), 2, 3, TimeUnit.SECONDS);

如果任务以固定的3秒为间隔执行，我们可以这样写：

// 3秒后开始执行定时任务，以3秒为间隔执行:
    ses.scheduleWithFixedDelay(new Task("fixed-delay"), 2, 3, TimeUnit.SECONDS);

意FixedRate和FixedDelay的区别。FixedRate是指任务总是以固定时间间隔触发，不管任务执行多长时间：  
![在这里插入图片描述][20200222184409996.png]  
而FixedDelay是指，上一次任务执行完毕后，等待固定的时间间隔，再执行下一次任务：  
![在这里插入图片描述][20200222184427774.png]  
因此，使用ScheduledThreadPool时，我们要根据需要选择执行一次、FixedRate执行还是FixedDelay执行。

### Future ###

Runnable接口有个问题，它的方法没有返回值。如果任务需要一个返回结果，那么只能保存到变量，还要提供额外的方法读取，非常不便。所以，J**ava标准库还提供了一个Callable接口，和Runnable接口比，它多了一个返回值**：

class Task implements Callable<String> {
        public String call() throws Exception {
            return longTimeCalculation(); 
        }
    }

并且Callable接口是一个泛型接口，可以返回指定类型的结果。  
**当我们提交一个Callable任务后，我们会同时获得一个Future对象，然后，我们在主线程某个时刻调用Future对象的get()方法，就可以获得异步执行的结果**。在调用get()时，如果异步任务已经完成，我们就直接获得结果。如果异步任务还没有完成，那么get()会阻塞，直到任务完成后才返回结果。

ExecutorService executor = Executors.newFixedThreadPool(4); 
    // 定义任务:
    Callable<String> task = new Task();
    // 提交任务并获得Future:
    Future<String> future = executor.submit(task);
    // 从Future获取异步执行返回的结果:
    String result = future.get(); // 可能阻塞

一个Future接口表示一个未来可能会返回的结果，它定义的方法有：

*  get()：获取结果（可能会等待）
 *  get(long timeout, TimeUnit unit)：获取结果，但只等待指定的时间；
 *  cancel(boolean mayInterruptIfRunning)：取消当前任务；
 *  isDone()：判断任务是否已完成。

### CompletableFuture ###

使用Future获得异步执行结果时，要么调用阻塞方法get()，要么轮询看isDone()是否为true，这两种方法都不是很好，因为主线程也会被迫等待。**从Java 8开始引入了CompletableFuture，它针对Future做了改进，可以传入回调对象，当异步任务完成或者发生异常时，自动调用回调对象的回调方法**。创建一个CompletableFuture是通过CompletableFuture.supplyAsync()实现的，它需要一个实现了Supplier接口的对象：

public interface Supplier<T> {
        T get();
    }

这里我们用lambda语法简化了一下，直接传入Main::fetchPrice，因为Main.fetchPrice()静态方法的签名符合Supplier接口的定义（除了方法名外）。  
紧接着，CompletableFuture已经被提交给默认的线程池执行了，我们需要定义的是CompletableFuture完成时和异常时需要回调的实例。完成时，CompletableFuture会调用Consumer对象：

public interface Consumer<T> {
        void accept(T t);
    }

异常时，CompletableFuture会调用Function对象：

public interface Function<T, R> {
        R apply(T t);
    }

可见CompletableFuture的优点是：

*  异步任务结束时，会自动回调某个对象的方法；
 *  异步任务出错时，会自动回调某个对象的方法；
 *  主线程设置好回调后，不再关心异步任务的执行。

最后我们注意CompletableFuture的命名规则：

*  xxx()：表示该方法将继续在已有的线程中执行；
 *  xxxAsync()：表示将异步在线程池中执行。

### ForkJoin ###

**Java 7开始引入了一种新的Fork/Join线程池，它可以执行一种特殊的任务：把一个大任务拆成多个小任务并行执行**。这就是Fork/Join任务的原理：判断一个任务是否足够小，如果是，直接计算，否则，就分拆成几个小任务分别计算。这个过程可以反复“裂变”成一系列小任务。

class SumTask extends RecursiveTask<Long> {
        protected Long compute() {
            // “分裂”子任务:
            SumTask subtask1 = new SumTask(...);
            SumTask subtask2 = new SumTask(...);
            // invokeAll会并行运行两个子任务:
            invokeAll(subtask1, subtask2);
            // 获得子任务的结果:
            Long result1 = fork1.join();
            Long result2 = fork2.join();
            // 汇总结果:
            return result1 + result2;
        }
    }

Fork/Join线程池在Java标准库中就有应用。Java标准库提供的java.util.Arrays.parallelSort(array)可以进行并行排序，它的原理就是内部通过Fork/Join对大数组分拆进行并行排序，在多核CPU上就可以大大提高排序的速度。

### ThreadLocal ###

**多线程是Java实现多任务的基础，Thread对象代表一个线程，我们可以在代码中调用Thread.currentThread()获取当前线程**。例如，打印日志时，可以同时打印出当前线程的名字：

public class Main {
        public static void main(String[] args) throws Exception {
            log("start main...");
            new Thread(() -> {
                log("run task...");
            }).start();
            new Thread(() -> {
                log("print...");
            }).start();
            log("end main.");
        }
    
        static void log(String s) {
            System.out.println(Thread.currentThread().getName() + ": " + s);
        }
    }

对于多任务，Java标准库提供的线程池可以方便地执行这些任务，同时复用线程。Web应用程序就是典型的多任务应用，每个用户请求页面时，我们都会创建一个任务，类似：

public void process(User user) {
        checkPermission();
        doWork();
        saveStatus();
        sendResponse();
    }

然后，通过线程池去执行这些任务。  
观察process()方法，它内部需要调用若干其他方法，同时，我们遇到一个问题：如何在一个线程内传递状态？  
process()方法需要传递的状态就是User实例。有的童鞋会想，简单地传入User就可以了：

public void process(User user) {
        checkPermission(user);
        doWork(user);
        saveStatus(user);
        sendResponse(user);
    }

但是往往一个方法又会调用其他很多方法，这样会导致User传递到所有地方：

void doWork(User user) {
        queryStatus(user);
        checkStatus();
        setNewStatus(user);
        log();
    }

这种在一个线程中，横跨若干方法调用，需要传递的对象，我们通常称之为上下文（Context），它是一种状态，可以是用户身份、任务信息等。给每个方法增加一个context参数非常麻烦，而且有些时候，如果调用链有无法修改源码的第三方库，User对象就传不进去了。Java标准库提供了一个特殊的ThreadLocal，它可以在一个线程中传递同一个对象。  
ThreadLocal实例通常总是以静态字段初始化如下：

static ThreadLocal<String> threadLocalUser = new ThreadLocal<>();

它的典型使用方式如下：

void processUser(user) {
        try {
            threadLocalUser.set(user);
            step1();
            step2();
        } finally {
            threadLocalUser.remove();
        }
    }

通过设置一个User实例关联到ThreadLocal中，在移除之前，所有方法都可以随时获取到该User实例：

void step1() {
        User u = threadLocalUser.get();
        log();
        printUser();
    }
    
    void log() {
        User u = threadLocalUser.get();
        println(u.name);
    }
    
    void step2() {
        User u = threadLocalUser.get();
        checkUser(u.id);
    }

注意到普通的方法调用一定是同一个线程执行的，所以，step1()、step2()以及log()方法内，threadLocalUser.get()获取的User对象是同一个实例。实际上，可以把ThreadLocal看成一个全局Map<Thread, Object>：每个线程获取ThreadLocal变量时，总是使用Thread自身作为key：

Object threadLocalValue = threadLocalMap.get(Thread.currentThread());

因此，ThreadLocal相当于给每个线程都开辟了一个独立的存储空间，各个线程的ThreadLocal关联的实例互不干扰。  
最后，特别注意ThreadLocal一定要在finally中清除：

try {
        threadLocalUser.set(user);
        ...
    } finally {
        threadLocalUser.remove();
    }

这是因为当前线程执行完相关代码后，很可能会被重新放入线程池中，如果ThreadLocal没有被清除，该线程执行其他代码时，会把上一次的状态带进去。  
为了保证能释放ThreadLocal关联的实例，我们可以通过AutoCloseable接口配合try (resource) \{…\}结构，让编译器自动为我们关闭。例如，一个保存了当前用户名的ThreadLocal可以封装为一个UserContext对象：

public class UserContext implements AutoCloseable {
        static final ThreadLocal<String> ctx = new ThreadLocal<>();
        public UserContext(String user) {
            ctx.set(user);
        }
    
        public static String currentUser() {
            return ctx.get();
        }
    
        @Override
        public void close() {
            ctx.remove();
        }
    }

使用的时候，我们借助try (resource) \{…\}结构，可以这么写：

try (var ctx = new UserContext("Bob")) {
        // 可任意调用UserContext.currentUser():
        String currentUser = UserContext.currentUser();
    } // 在此自动调用UserContext.close()方法释放ThreadLocal关联对象

这样就在UserContext中完全封装了ThreadLocal，外部代码在try (resource) \{…\}内部可以随时调用UserContext.currentUser()获取当前线程绑定的用户名。  
ThreadLocal表示线程的“局部变量”，它确保每个线程的ThreadLocal变量都是各自独立的；  
ThreadLocal适合在一个线程的处理流程中保持上下文（避免了同一参数在所有方法中传递）；  
使用ThreadLocal要用try … finally结构，并在finally中清除。

### 参考资料 ###

**Java核心技术 卷1 基础知识**  
**[https://www.liaoxuefeng.com/wiki/1252599548343744][https_www.liaoxuefeng.com_wiki_1252599548343744]**

### 接下来 ###

#### [Java高并发编程学习（一）多线程基础][Java] ####

#### [Java高并发编程学习（二）线程同步][Java 1] ####

#### [Java高并发编程学习（三）java.util.concurrent包][Java_java.util.concurrent] ####

[20200222182725412.png]: https://img-blog.csdnimg.cn/20200222182725412.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200222183520943.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200222183948892.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIyMTM2NDM5,size_16,color_FFFFFF,t_70
[20200222184409996.png]: https://img-blog.csdnimg.cn/20200222184409996.png
[20200222184427774.png]: https://img-blog.csdnimg.cn/20200222184427774.png
[https_www.liaoxuefeng.com_wiki_1252599548343744]: https://www.liaoxuefeng.com/wiki/1252599548343744
[Java]: https://blog.csdn.net/qq_22136439/article/details/104427003
[Java 1]: https://blog.csdn.net/qq_22136439/article/details/104427259
[Java_java.util.concurrent]: https://blog.csdn.net/qq_22136439/article/details/104444867