s:103

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

给你比个心，渴望留住你 ^ V ^

文章目录

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

1. JUC的常见组件

1.1 Callable接口的用法

1.1.1 Callable的构建

1.1.2 FutureTask对象包装Callable对象

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

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

1.1.5 测试

1.1.6 知识点补充

1.1.7 一个简单的例子

1.2 ReentrantLock可重入锁

1.3 原子类 AtomicXXX

1.4 线程池 ExecutorService、Executors

1.5 信号量 Semaphore

1.5.1 背景小例子

1.5.2 Semaphore本质

1.6 CountDownLatch

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

2.1 线程安全的表

2.1.1 线程安全的顺序表 --- Vector

2.1.2 Collections.synchronizedList 套壳方法

2.1.3 CopyOnWriteArrayList “顺序表写时拷贝”

2.1.4 应用测试

2.1.5 多语句线程不安全

2.2 线程安全的队列

2.3 线程安全的哈希表

2.3.1 HashTable & ConcurrentHashMap

2.3.2 ==HashTable 和 ConcurrentHashMap 的区别==

2.4 对比测试

3.StringBuffer 和 StringBuilder

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());
}