1. Callable的用法
之前已经接触过了Runnable接口,即我们可以使用实现Runnable接口的方式创建一个线程,而Callable也是一个interface,我们也可以用Callable来创建一个线程。
- Callable是一个带有泛型的interface
- 实现Callable接口必须重写call方法
- call方法带有返回值,且返回值类型就是泛型类型
- 可以借助FutureTask类接收返回值,更方便的帮助程序员完成计算任务并获取结果
下面我们来举一个案例,要求分别使用实现Runnable
接口和Callable
接口完成计算1+2+3+…1000并在主线程中打印结果的任务,体会区别。
1.1 使用Runnable接口
public class ThreadDemo01 {
private static int result = 0;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 1; i <= 1000; i++) {
result += i;
}
}
});
// 启动线程
t.start();
t.join();
// 打印结果
System.out.println("result: " + result); // 500500
}
}
上述代码实现Runnable接口来启动一个线程,这段代码可以实现累加1-1000的任务,但是不够优雅!因为需要额外借助一个成员变量result来保存结果,当业务量繁多时,如果有多个线程完成各自的计算任务,那么就需要更多的成员变量保存结果,因此现在想想带有返回值的线程也许是有必要的!下面我们来看看如何使用Callable接口完成
1.2 使用Callable接口
public class ThreadDemo02 {
public static void main(String[] args) throws ExecutionException, InterruptedException {
Callable<Integer> callable = new Callable<Integer>() {
@Override
public Integer call() throws Exception {
int result = 0;
for (int i = 1; i <= 1000; i++) {
result += i;
}
return result;
}
};
// 创建FutureTask实例
FutureTask<Integer> futureTask = new FutureTask<>(callable);
// 创建线程并启动
Thread t = new Thread(futureTask);
t.start();
// 阻塞并获取返回结果
int result = futureTask.get();
System.out.println("result: " + result); // 500500
}
}
上述代码中我们使用了实现Callable的方式完成任务,值得一提的是,Callable实现类对象不能直接作为Thread构造方法的参数,我们需要借助一个中间人即 FutureTask 类,该类实现了Runnable接口,因此可以直接作为Thread构造方法的参数。
注:futureTask.get()方法带有阻塞功能,直到子线程完成返回结果才会继续运行
1.3 如何理解FutureTask和Callable
理解Callable:1、Callable与Runnable是相对的,都是描述一个任务,Callable描述带有返回值的任务,Runnable描述不带返回值的任务。2、Callable往往需要搭配FutureTask一起使用,FutureTask用于保存Callable的返回结果,因为Callable中的任务往往在另一个线程执行,具体什么时候执行并不确定
理解FutureTask:FutureTask顾名思义就是未来任务,即Callable中的任务是不确定何时执行完毕的,我们可以形象描述为去杨国福吃麻辣烫时等待叫号,但是什么时候叫号是不确定的,通常点餐完毕后服务员会给一个取号凭证,我们可以凭借这个取号凭证查看自己的麻辣烫有没有做好。
1.4 相关面试题
- 介绍下Callable是什么?
2. 信号量Semaphore
相信大学期间修过操作系统课的小伙伴对semaphore
这个单词并不陌生,这不就是OS的信号量机制可以实现PV操作的么?而JVM对OS提供的semaphore又进行了封装形成了Java标准库中的Semaphore
类
semaphore:信号量,用来表示可用资源的数目,本质上是一个计数器。
我们可以拿停车场的展示牌进行举例,当前留有空闲车位100个时,展示牌上就会显示100,表示可用资源的数目,当有汽车开进停车位时,相当于申请了一个可用资源,此时展示牌数目就会-1(称为信号量的P操作),当有汽车驶出停车位,相当于释放了一个可用资源,此时展示牌数目+1(称为信号量V操作)
Semaphore的信号量PV操作都是原子性的,可以直接在多线程环境中使用。
锁其实本质上就是特殊的信号量,加锁可以看作时信号量为0,解锁可以看作信号量为1,所以也有说法称"锁"其实是一个二元信号量,那么既然"锁机制"能够实现线程安全,信号量也可以用来保证线程安全!
2.1 Semaphore代码案例
Semaphore相关API:
- acquire:相当于P操作,申请一个可用资源
- release:相当于V操作,释放一个可用资源
代码举例:
- 创建Semaphore实例并初始化为4,表示有4个可用资源
- 创建20个线程,每个线程都尝试申请资源,sleep1秒后释放资源,观察程序运行状况
public class SemaphoreExample {
public static void main(String[] args) {
// 初始化信号量为4
Semaphore semaphore = new Semaphore(4);
// 创建20个线程
for (int i = 0; i < 20; i++) {
int id = i;
Thread t = new Thread(() -> {
try {
semaphore.acquire(); // 申请资源
System.out.println("线程" + id + "申请到了资源");
Thread.sleep(1000); // 睡眠1s
semaphore.release(); // 释放资源
System.out.println("线程" + id + "释放资源");
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
});
// 启动线程
t.start();
}
}
}
执行结果:
其中可以发现当前四个线程申请资源后,此时第五个线程尝试申请资源后,信号量变为-1就会阻塞等待,直到其他线程释放资源后才可以继续申请!
3. CountDownLatch的使用
CountDownLatch:可以等待N个任务全部完成。类似于N个人进行跑步比赛,直到最后一个人跃过终点才会宣布比赛结束,公布最后成绩。
3.1 CountDownLatch相关API
CountDownLatch提供API:
- new CountDownLatch(int n):构造方法,初始化n表示有n个任务需要完成
- countDown():任务执行完毕后调用,内部计数器进行自减
- await():阻塞等待所有任务全部完成后继续执行,相当于等待内部计数器为0
3.2 CountDownLatch代码案例
CountDownLatch代码案例:
- 创建10个线程,并初始化CountDownLatch为10
- 每个线程随机休眠1-5秒,模拟比赛结束
- 主线程中使用await阻塞等待全部执行完毕
public class CountDownLatchExample {
public static void main(String[] args) throws InterruptedException {
Random random = new Random();
// 初始化CountDownLatch为10
CountDownLatch latch = new CountDownLatch(10);
// 创建10个线程
for (int i = 0; i < 10; i++) {
int curId = i;
Thread t = new Thread(() -> {
System.out.println("线程" + curId + "开始执行...");
try {
Thread.sleep(random.nextInt(6) * 1000);
System.out.println("线程" + curId + "结束执行...");
latch.countDown(); // 计数器自减
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
});
// 启动线程
t.start();
}
// 阻塞等待全部执行完毕
latch.await();
System.out.println("全部任务执行完毕!");
}
}
执行结果:
此时我们可以看到调用countDownLatch.await()
方法时只有当所有的线程都执行完毕,即调用10次countDown
方法后(即内部计数器为0)时才会停止阻塞!
4. ReentrantLock类
ReentrantLock:位于java.util.concurrent
包下,被称为可重入互斥锁,和synchronized定位类似,都是用来实现互斥效果的可重入锁,保证线程安全。
4.1 ReentrantLock的用法
ReentrantLock相关API:
- lock():尝试加锁,如果加锁失败就阻塞等待
- tryLock(超时时间):尝试加锁,获取不到就阻塞等待一定时间,超时则放弃加锁
- unlock():解锁
注意:由于ReentrantLock需要手动释放锁,因此常常把unlock
方法放在finally
块中
ReentrantLock lock = new ReentrantLock();
-------------- 相关代码 --------------
lock.lock();
try {
// do something...
} finally {
lock.unlock();
}
4.2 ReentrantLock与synchronized的区别(经典面试题)
- synchronized是一个关键字,是JVM内部实现的(大概率使用C++语言实现),而ReentrantLock是一个标准库中提供的类,是在JVM外部实现的(基于Java实现)
- ReentrantLock使用lock和unlock一对方法进行手动加锁、解锁,相较于synchronized更加灵活,但是也容易遗漏释放锁的步骤。
- synchronized是非公平锁,而ReentrantLock默认是非公平锁,但是可以变成公平锁,只需要在构造方法中传入参数为true即可。
- ReentrantLock比synchronized具有更加精准的唤醒机制,synchronized使用Object类的wait/notify进行唤醒,随机唤醒一个等待线程,而ReentrantLock借助类Condition实现等待唤醒,可以精准控制唤醒某一个指定线程。
5. CAS机制
5.1 CAS的基本概念
CAS:全程为compare and swap
字面意思就是比较并且交换,一个CAS涉及以下操作:
我们假设内存中的原数据为V,旧的预期值为A,需要修改的新值为B
- 比较A与V是否相等(比较)
- 如果比较相等则将B写入内存替换V(交换)
- 返回操作是否成功。
CAS伪代码:
public boolean CAS(address, expectValue, swapValue) {
if (&address == expectValue) {
&address = swapValue;
return true;
}
return false;
}
注意:CAS是一个硬件指令,其操作是原子性的,这个伪代码只是辅助理解CAS的工作流程
对CAS原子性的理解:CAS可以看做是乐观锁的一种实现方式,当多个线程同时对某个资源进行CAS操作时,只要一个线程操作成功返回true,其余线程全部返回false,但是不会阻塞。
5.2 CAS的常见应用
5.2.1 实现原子类
标准库中提供了java.util.concurrent.atomic
包,里面的类都是基于CAS的方式实现的,最典型的就是AtomicInteger类,其中的getAndIncrement
方法相当于i++
操作
AtomicInteger atomicInteger = new AtomicInteger(0);
// 相当于i++操作
atomicInteger.getAndIncrement();
下面是AtomicInteger类基于CAS方式的伪代码实现:
class AtomicInteger {
private int value;
public int getAndIncrement() {
int oldValue = value;
while (CAS(value, oldValue, oldvalue + 1) != true) {
oldValue = value;
}
return oldValue;
}
}
5.2.2 实现自旋锁
基于CAS也可以实现更加灵活的锁,获取到更多的控制权
下面是基于CAS的自旋锁伪代码实现:
class SpinLock {
private Thread owner;
public void lock() {
while (!CAS(owner, null, Thread.currentThread())) {}
}
public void unlock() {
this.owner = null;
}
}
5.3 CAS的ABA问题
5.3.1 ABA问题概述
什么是ABA问题:假设现在有两个线程共用一个共享变量num,初始值为A,此时线程t1,期望使用CAS机制将num值修改为Z,线程t1的CAS判定流程如下:
- 如果此时
num == A
,那么就将内存中的num值修改为Z - 如果此时
num != A
,那么就不进行修改,重新判定
但是此时中间穿插了线程t2执行将num值修改为了B,但是又重新修改为了A,所以尽管t1线程比较的预期结果是一致的,但是很可能已经是别人的形状了!
ABA导致的问题
ABA问题有可能会导致严重的后果,比如说我去银行ATM机取钱,考虑采用的时CAS机制,目前我的账户余额为1500,我按下确定按钮想要取出500元钱,但是ATM机卡住了,因此我又按下一次确定按钮,此时正常情况如下:
正常情况:
此时结果是符合预期的!扣款线程t1进行扣款操作,此时余额变为1000元,扣款线程t2判断当前余额已经不为1500了,说明已经扣款成功!于是不进行后续扣款操作!但是如果中间出现其他线程汇款操作,就会出现ABA问题,导致严重后果!
极端情况:
此时扣款线程t1完成扣款操作后,余额变为1000,但是中间穿插了汇款线程t3,刚好往账户中存入金额500,此时扣款线程t3判断余额仍然为1500,因此又进行了多余的一次扣款操作!!!这是相当不合理的
5.3.2 ABA问题解决思路
为了解决ABA带来的问题,我们可以考虑使用 版本号 的思想解决:
- CAS读取数据的时候,同时也要读取版本号
- 如果当前版本号与读取版本号一致,修改数据同时将版本号+1
- 如果当前版本号高于读取版本号,则说明数据已经被修改,当前操作非法
6. 线程安全的集合类
Java提供的集合类大部分都是线程不安全的
Vector,Stack,HashTable是线程安全的(但是官方不推荐使用)
6.1 多线程环境使用ArrayList
- 自己加锁(使用synchronized或者ReentrantLock实现)
- 使用
Collections.synchronizedList
,这是标准库提供的基于synchronized实现的线程安全的类,本质上是在关键方法上加了synchronized
修饰 - 使用CopyOnWriteArrayList,这是一个借助写时拷贝机制实现的容器,常用于配置文件等不经常修改,占用内存较小等场景
写时拷贝机制的核心就是可以对原容器进行并发的读,涉及写操作则先对原容器进行拷贝,然后向新容器中添加元素,最后修改引用,实现了读写分离!
6.2 多线程环境使用队列
- 自己加锁实现(synchronized或者ReentrantLock实现)
- 使用标准库提供的BlockingQueue接口及其实现类
6.3 多线程环境使用哈希表
-
使用HashTable
只是在关键方法上加上synchronized进行修饰
-
ConcurrentHashMap(常考面试题)
相比于Hashtable做出了一系列优化(以JDK1.8为例)
- 优化方式一:读操作没有加锁,只有写操作才会加锁,加锁的方式仍然使用synchronized,但是并不是锁整个对象,而是锁"桶"(使用链表的头结点作为锁对象),大大降低了锁冲突的概率
- 优化方式二:对于一些变量例如哈希表元素个数size,使用CAS机制避免重量级锁出现
- 优化方式三:优化了扩容方式,采用"化整为零","蚂蚁搬家"的方式,扩容期间新老数组同时存在,一次搬运只搬运少量元素,因此新增操作只需要在新数组中插入即可,查询操作需要在新老数组同时查询,删除操作也需要新老数组同时删除