JavaEE & Callable接口(NO.6线程创建方法) & JUC的常见组件 & 与线程安全有关类和集合类

1. JUC的常见组件

JUC ==> java.util.concurrent

1.1 Callable接口的用法

使用这个接口，可以说是第六种线程的创建方式~

与前五种方式不一样的是

重写run方法，是没有返回值的

而我们很多时候，是希望任务要有返回值的~

有一个具体的结果产出~

例如：我们需要用一个线程去算 1 + 2 + 3 + ······ + 1000，前五种线程创建方式的话应该将此结果赋值给捕获到的变量才行~

而Callable方式去创建的线程，就可以通过一些方式去获得这个结果~

1.1.1 Callable的构建

底层原理我不讲，但是会讲使用方法~

大概就是通过call是可以重写run方法，也改变了“一些东西”，那么通过“这些东西”，可以起到具有返回值的作用

1.1.2 FutureTask对象包装Callable对象

而Callable对象是不能直接传给Thread构造方法的，“Callable” ===> 仅仅只能“可召唤的”

我们需要给他包上一个普通类，“FutureTask” ===> “未来的任务”

构造一个FutureTask对象，完善任务信息~

1.1.3 依照“未来的任务”去构造和启动线程

将这个任务传给Thread的构造方法就OK了~

而Thread对象只是负责描述和启动线程

而返回值得通过“futureTask小票”去兑换~

1.1.4 根据线程引用获得返回值

通过FutureTask对象内部的get方法去兑换返回值

如果线程尚未结束，get则想join一样，会阻塞等待，直到线程结束~

1.1.5 测试

结果正常~

1.1.6 知识点补充

Callable是一个函数式接口

那么就可以写成下列形式 ===> 一行代码

Thread thread = new Thread(new FutureTask<Integer>(() -> {
    int sum = 0;
    for (int i = 1; i <= 1000; i++) {
        sum += i;
    }
    return sum;
}));
thread.start();

但是由于FutureTask对象是匿名的，就相当于没有小票了

那么就不符合我们要获得返回值的需求

这样就只能执行小票，而不能用小票获取返回值

1.1.7 一个简单的例子

正常写法

用匿名的方法则是：

1.2 ReentrantLock可重入锁

synchronized是关键字，是基于代码块的方式来控制加锁解锁的~

而ReentrantLock则是提供了类似C++，lock和unlock的独立的方法去控制加锁解锁

当然，Java是优化了这种操作，才引入synchronized的，但是一些特定场景下，我们可能需要lock与unlock去控制锁~

Java这么优化是因为怕程序员忘记unlock，或者因为return而错过unlock

ReentrantLock是一个重要的补充！

synchronized只能加锁和解锁，加锁的时候发现锁被占用，就得阻塞等待

而ReentrantLock 还提供了个 tryLock方法

加锁成功返回true

加锁失败不会阻塞而是返回false

加锁失败后，拿这个false干什么呢？

不会阻塞等待，让程序员灵活地自己决定接下来做什么

也可以自旋，也可以挂起等待······

synchronized 是非公平锁 ---- 概率相等但是不遵循先来后到~

ReentrantLock 提供了公平锁和非公平锁两种工作模式

构造方法传入 true ==> 开启公平锁，false ==> 开启非公平锁

synchronized 搭配wait 和 notify 进行等待和唤醒

如果多个线程wait对应同一个锁对象，notify是随机唤醒一个的

ReentrantLock 则是搭配Condition这个类，这个类也能起到等待和唤醒的作用，但是功能更加强大，可以细节的去唤醒一个线程~

这个是解决了个不可控因素，起到补充作用~

没有代码演示~

1.3 原子类 AtomicXXX

正如上一篇文章所讲，AtomicXXX类

用CAS原子操作去实现，性能要比锁实现++操作高效得多~

传送门：JavaEE & 多线程进阶问题 & CAS操作

1.4 线程池 ExecutorService、Executors

在前面的文章中已经提到了~

传送门：JavaEE & 线程案例 & 线程池

顺便提一嘴：

一些公司有一些编程规范，要求不能使用Executors去构造线程池，得用ThreadPoolExecutor去构造

只能说明这家公司对这个线程池有独特的要求，要靠自己去传参定制~

客观要求主观喜好

你以后开公司也可以规范：“打工人们，你们只能用Executors去构造线程池！”

1.5 信号量 Semaphore

1.5.1 背景小例子

这里的信号牌就相当于这里的Semaphore

如果信号牌显示剩余为0，我就无法进入停车场，只能阻塞等待~

1.5.2 Semaphore本质

Semaphore本质其实就是个特殊的计数器，描述“可用资源”个数

P操作，申请资源，计数器-1 ===> accquire方法

V操作，释放资源，计数器+1 ===> release方法

PV操作~

P，V对应的是荷兰语~

所谓的“锁”本质上就是个计数器为1的信号量 Semaphore对象

取值要么是0，要么是1，===> 二元信号量

P == 加锁

V == 解锁

加了锁后，其他线程阻塞等待~

所以，信号量 Semaphore是更广义的锁~

不光是管理非0即1的资源

也可以管理多个资源~

1.6 CountDownLatch

CountDownLatch ==> 倒数弹簧锁

指的是多个线程运行的倒数一名线程结束，锁才能解除~

是特别针对特有的场景组件！

例如，我们在下载一个很大很大的文件的时候，并不会只让一个线程去下载，因为一个线程的速度有限，而你的带宽又足够大，一个线程就有点浪费了~

所以一般是要分为几个线程去下载这个任务的

比如下图的下载任务1 2 3 4

显然，下载完毕应该是所有的线程，都把对应的资源下载好才算下载完毕~

不然这个大文件就是不完整的~

使用方式：

static int count = 0;
static Object object = new Object();
public static void main(String[] args) throws InterruptedException {
    CountDownLatch countDownLatch = new CountDownLatch(10); // 代表有十个线程参加下载任务~
    for (int i = 0; i < 10; i++) {
        Thread thread = new Thread(() -> {
            for (int j = 0; j < 10_0000; j++) {
                synchronized (object) {
                    count++;
                }
            }
            countDownLatch.countDown();//线程安全的~
        });
        thread.start();
    }
    countDownLatch.await();//涉及阻塞都会抛出这个，被中断异常
    System.out.println(count);
}

在此对象所在的线程里，创建十个线程

然后构造CountDownLatch对象，---- 传入竞赛的线程数

注意：一个线程结束，要调用countDownLatch.countDown方法，“宣布此选手下场”

这也是绑定线程和countDownLatch的方式，并且线程安全！

并且countDownLatch会暗中去计算还差几个人没下场

然后调用countDownLatch.await()方法

注意：在await方法调用前，必须有十个线程参赛，否则就无法退出阻塞！

一旦countDownLatch计算得到全部下场了，就接触原线程的阻塞状态~

如果参赛选手不够，main线程就会一直等第10个人下场，那当然等不到呀~

2. JUC里的线程安全有关集合类

Java中有很多现成的类是线程不安全的

例如：ArrayList 、 LinkedList 、 HashMap 、Queue 、 Deque 、 PriorityQueue ······

DataSource只是读了数据源，是后续的一些操作去修改数据库，所以这也是线程安全的

在多线程环境下，我们要使用这些类，但是又害怕线程不安全，咋办？

使用锁直接手动保证 — 对于修改操作加锁

使用标准库提供的线程安全的集合类

2.1 线程安全的表

2.1.1 线程安全的顺序表 — Vector

Vector的关键方法都是带有synchronized的

这个集合类是上古时期的，实际上并不建议使用（标准库说的）

2.1.2 Collections.synchronizedList 套壳方法

这个是用了Collections工具类里的 “锁表方法”

用这个方法给现有的表进行 “套锁壳”

即将表的根据方法都套上锁~

套完后以返回值形式输出

可见，List的子孙都能传入

2.1.3 CopyOnWriteArrayList “顺序表写时拷贝”

这种只有顺序表有~

这个是不通过加锁实现的线程安全

而是通过 — 多个线程修改不同变量~

顾名思义：修改的时候 就 拷贝一份

大概就是这样的操作，具体怎么实现太复杂了

这种方式适用于读多写少的情景下，拷贝开销也大~

一个例子：

一个显示屏 — 显卡处理60张图片一秒

为了更加流畅，我们会用类似这种方式的方法去完成

因为加锁就涉及阻塞等待，体验不好！

2.1.4 应用测试

用原汁原味的ArrayList：

public static void main(String[] args) throws InterruptedException {
        List<Integer> arrayList = new ArrayList<>();
        arrayList.add(1);
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                arrayList.add(1);
            }
        });
        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                arrayList.add(1);
            }
        });
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
        System.out.println(arrayList.size());
    }

结果：

手动加锁：

因为非原子性，导致有些无效插入

因为含扩容机制，导致未扩容完毕却被插入到未申请的位置！

public static void main(String[] args) throws InterruptedException {
        Vector<Integer> vector = new Vector<>();
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) {
                vector.add(1);
            }
        });
        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) {
                vector.add(1);
            }
        });
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
        System.out.println(vector.size());
    }

其他两种一样~

2.1.5 多语句线程不安全

对于上述问题能够保证方法是线程安全的，

但是不能保证你写的代码完全安全~

所以多个方法嵌套调用，还是会有线程不安全的可能

这个时候就需要手动加锁~

public static void main(String[] args) throws InterruptedException {
        Vector<Integer> vector = new Vector<>();
        vector.add(0);
        Thread thread1 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                vector.set(0, vector.get(0) + 1);
            }
        });
        Thread thread2 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                vector.set(0, vector.get(0) + 1);
            }
        });
        thread1.start();
        thread2.start();
        thread1.join();
        thread2.join();
        System.out.println(vector);
    }

必须手动套锁这些操作：

其他方式也一样：

2.2 线程安全的队列

Queue ==> BlockingQueue

Deque ==> BlockingDeque

PriorityQueue ==> PriorityBlockingQueue

传送门：

JavaEE & 线程案例 & 定时器 & 线程池 and 工厂模式

JavaEE & 线程案例 & 单例模式 and 阻塞队列

2.3 线程安全的哈希表

HashMap 肯定是线程不安全的

一些操作不保证原子性~

2.3.1 HashTable & ConcurrentHashMap

HashTable很简单粗暴，给关键方法加synchronized，针对整个表加锁

并不是一个好的选择！

ConcurrentHashMap对局部进行加锁

HashTable的全面升级版本~

是一个推荐方案~

2.3.2 HashTable 和 ConcurrentHashMap 的区别

加锁粒度的不同 — 核心区别！

锁范围不同即触发锁冲突概率不同

HashTable是针对整个哈希表加锁，任何增删改查都会触发锁竞争！

而我们知道，并不是每次都需要加锁，如下图所示：

如果是HashTable 则那些没被修改和读取的一样会被锁到

那么我们在修改蓝区域和红区域的时候，就不能并发进行了！！！

而我们知道，多线程修改不同变量是不会有线程安全的！

ConcurrentHashMap则很好的解决这一点，它降低了锁的粒度，让每一个链表都分配一把锁，这样线程修改不同链表，不会触发锁的阻塞等待

实现起来比较简单，因为计算哈希值后获取下标，得到链表头结点是线程安全的

之后获得的头结点针对性的加锁就行了

补充：java1.7之前ConcurrentHashMap用的是分段锁，java1.8之后则是每个链表都有一把锁

分段锁：

不科学：压根没必要多个链表共用锁，还不如彻彻底底的给每个链表一个锁

ConcurrentHashMap更充分的利用了CAS机制 — 一些操作实现无锁编程

有的操作，例如获取 / 更新元素个数，就可以直接使用CAS完成，不必加锁~

CAS出适用于一些特定场景，而锁是更广泛的！

优化扩容机制

哈希表由于负载因子的原因，元素达到一定个数就会触发扩容机制

而一旦表内元素太多太多了，那么每个键值是需要重新放在扩容后的表里的！搬运成本太高了！

指不定哪次的put操作会让你卡上半天~

HashMap以及HashTable都没有解决这个问题

一次性搬运

而ConcurrentHashMap很好解决了这个问题

并不会一次性全部搬运，而是每次只搬运一点点~

也就是说当我们 put 触发扩容的时候，就会创建一个更大的内存空间，并不会把所有元素都搬运过去，也不会删除原表

而是只搬运一小部分

我们现在就拥有两份hash表~

增加元素，只插入到新表中

旧表存在相同的，就得删除~

查询运算，查询两表

删除元素，查询两表删除

并且在每次操作过程中，哈希表都会再运一些过去~

虽然我们使用的时候感知不到，但是这个是一个高频面试题！

补充：Set本身就是个Map，只不过key对应value不重要~

2.4 对比测试

public static void main(String[] args) throws InterruptedException {
    Map<Integer, Integer> map1 = new HashMap<>();
    Map<Integer, Integer> map2 = new Hashtable<>();
    Map<Integer, Integer> map3 = new ConcurrentHashMap<>();
    Thread thread1 = new Thread(() -> {
        for (int i = 0; i < 1000000; i++) {
            map1.put(i % 1000, i);
            map2.put(i % 1000, i);
            map3.put(i % 1000, i);
        }
    });
    Thread thread2 = new Thread(() -> {
        for (int i = 0; i < 1000000; i++) {
            map1.put(i % 1000, i);
            map2.put(i % 1000, i);
            map3.put(i % 1000, i);
        }
    });
    thread1.start();
    thread2.start();
    thread1.join();
    thread2.join();
    System.out.println(map1.size());
    System.out.println(map2.size());
    System.out.println(map3.size());
    System.out.println(map1);
    System.out.println(map2);
    System.out.println(map3);
    //ConcurrentHashMap和HashTable打印方法不同，刚好相反~
}

测试结果：

3.StringBuffer 和 StringBuilder

StringBuffer就是对StringBuilder的一个对关键方法的简单的锁包装

不过不用担心，synchronized是可重入锁，且有偏向锁和锁消除等机制，保证能不加锁就不加~

测试：

public static void main(String[] args) throws InterruptedException {
    StringBuilder stringBuilder = new StringBuilder();
    StringBuffer stringBuffer = new StringBuffer();
    Thread t1 = new Thread(() -> {
        for (int i = 0; i< 5000; i++) {
            stringBuffer.append(1);
            stringBuilder.append(1);
        }
    });
    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 5000; i++) {
            stringBuffer.append(1);
            stringBuilder.append(1);
        }
    });
    t1.start();
    t2.start();
    t1.join();
    t2.join();
    System.out.println(stringBuilder.length());
    System.out.println(stringBuffer.length());
}

测试结果：