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 ==> 开启非公平锁
- ReentrantLock 提供了公平锁和非公平锁两种工作模式
- 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.countDown方法，“宣布此选手下场”
-
然后调用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
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());
}
测试结果：
文章到此结束！谢谢观看 可以叫我 小马，
我可能写的不好或者有错误，但是一起加油鸭🦆！
多线程的讲解完结撒花✿✿ヽ(°▽°)ノ✿
但这是结束也是开始，多线程是JavaEE编程的重要手段！
敬请期待后续内容！
313
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
