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

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

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方法,也改变了“一些东西”,那么通过“这些东西”,可以起到具有返回值的作用


f42177ed937640bd83cb09925514b172.png

1.1.2 FutureTask对象包装Callable对象

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


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

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


c5da7bf26d294f93a926d8bca4738ba4.png

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

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


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

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


b3fce74463d5480788abb3404a9a45d1.png

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

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

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

7726e32b05be4e259ab851e77f7122ac.png


1.1.5 测试

结果正常~

f520f5f4748740fda3c7a9e5e87d4495.png


1.1.6 知识点补充

Callable是一个函数式接口

52f67a624bb0416aa3ebd0cceae55cb1.png


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

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 一个简单的例子

正常写法

2f246426a59b42f486f6f425a5477d54.png


用匿名的方法则是:

a46d2f1ebf414c1e8dd3e3a32c9dd630.png


1.2 ReentrantLock可重入锁


c901bc84db314cf2b4f16ab3ae09fb1d.png

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

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

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

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

ReentrantLock是一个重要的补充!


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

而ReentrantLock 还提供了个 tryLock方法

加锁成功返回true

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

加锁失败后,拿这个false干什么呢?

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

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

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

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

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


19188d468a8a4b3885a0136fdb8f6d6b.png

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

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

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

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

没有代码演示~

1.3 原子类 AtomicXXX

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

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

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

6dfddcf48993467e8a0959d3686c99de.png


1.4 线程池 ExecutorService、Executors

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

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

4c7acdea65a248288f564a36bdbe64ea.png


顺便提一嘴:


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


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

客观要求主观喜好

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


1.5 信号量 Semaphore

bc13a22209d04087a8028e1283b7cf85.png


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的资源

也可以管理多个资源~


f2ce28a05442474891dcdd2028683883.png

1.6 CountDownLatch

CountDownLatch ==> 倒数弹簧锁


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


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

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

604516b724d24f93b79b6772d52615bd.gif


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

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


f3428670d3dc4262a6898af9b5ea7509.png


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


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

2d57bfd0ba4846be9f92195c583464a7.gif


使用方式:


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计算得到全部下场了,就接触原线程的阻塞状态~


31445b2851334e14bce90d8971a8b955.png

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



9da1aaf9af1f45c19d061877c38bb1f6.png

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

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

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

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

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

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

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

2.1 线程安全的表

2.1.1 线程安全的顺序表 — Vector

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

这个集合类是上古时期的,实际上并不建议使用(标准库说的)

2.1.2 Collections.synchronizedList 套壳方法

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

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

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

套完后以返回值形式输出


877b7dba45c44aa197a4485fd8983b48.png

可见,List的子孙都能传入

2.1.3 CopyOnWriteArrayList “顺序表写时拷贝”

这种只有顺序表有~


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


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


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

34152efe0cb749f0a65c6f13f6f578b0.png



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

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

一个例子:


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

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

因为加锁就涉及阻塞等待,体验不好!

96bbd96795f34ffc9ea7a6f4a9ebbc3c.png


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


结果:


aa45d0908cea48e882bb195dc6c99e27.png


手动加锁:



d51905c6c467432b8b650e8179cb581c.png

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

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


c9e56dc3b440454d8e2a40f4d21f7365.png

 

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



其他两种一样~



e10a33a3146f42e4b3bb2d73984c0d30.png2.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);
    }

b60be8e80c8c4c1596eef183799601c3.png

必须手动套锁这些操作:


c17d0110d5e14a87b9b3aa26af866f25.png


其他方式也一样:



022f33dcbad244809bb7eaec7474593f.png

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是针对整个哈希表加锁,任何增删改查都会触发锁竞争!


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


1b73098a74a4437082828135c3e7facc.png

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

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

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

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


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

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

f7ddb96b96894e8e9ee17b6062ec32f8.png


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


分段锁:


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


5a825a03a28e4131b88620f3933990a9.png

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

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


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

优化扩容机制

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


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

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

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


一次性搬运

而ConcurrentHashMap很好解决了这个问题


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

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


而是只搬运一小部分

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

55d35c4370c34aafb92121e0395af9cd.png


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

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

查询运算,查询两表

删除元素,查询两表删除

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


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

补充: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打印方法不同,刚好相反~
}



测试结果:


7c0a53a4085b484b944e26af1a28b790.gif


3.StringBuffer 和 StringBuilder

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

5a575db750014082aae74088c23e8805.png


不过不用担心,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());
}


测试结果:

bdde8c318c9d4b6aa8ce181796046bd7.gif


目录
相关文章
|
10天前
|
设计模式 安全 Java
Java面试题:设计模式如单例模式、工厂模式、观察者模式等在多线程环境下线程安全问题,Java内存模型定义了线程如何与内存交互,包括原子性、可见性、有序性,并发框架提供了更高层次的并发任务处理能力
Java面试题:设计模式如单例模式、工厂模式、观察者模式等在多线程环境下线程安全问题,Java内存模型定义了线程如何与内存交互,包括原子性、可见性、有序性,并发框架提供了更高层次的并发任务处理能力
27 1
|
10天前
|
设计模式 存储 安全
Java面试题:设计一个线程安全的单例类并解释其内存占用情况?使用Java多线程工具类实现一个高效的线程池,并解释其背后的原理。结合观察者模式与Java并发框架,设计一个可扩展的事件处理系统
Java面试题:设计一个线程安全的单例类并解释其内存占用情况?使用Java多线程工具类实现一个高效的线程池,并解释其背后的原理。结合观察者模式与Java并发框架,设计一个可扩展的事件处理系统
21 1
|
10天前
|
设计模式 SQL 安全
Java面试题:设计一个线程安全的内存管理器,使用观察者模式来通知所有线程内存使用情况的变化。如何确保在添加和移除内存块时的线程安全?如何确保任务的顺序执行和调度器的线程安全?
Java面试题:设计一个线程安全的内存管理器,使用观察者模式来通知所有线程内存使用情况的变化。如何确保在添加和移除内存块时的线程安全?如何确保任务的顺序执行和调度器的线程安全?
11 0
|
10天前
|
存储 设计模式 监控
Java面试题:如何在不牺牲性能的前提下,实现一个线程安全的单例模式?如何在生产者-消费者模式中平衡生产和消费的速度?Java内存模型规定了变量在内存中的存储和线程间的交互规则
Java面试题:如何在不牺牲性能的前提下,实现一个线程安全的单例模式?如何在生产者-消费者模式中平衡生产和消费的速度?Java内存模型规定了变量在内存中的存储和线程间的交互规则
19 0
|
10天前
|
设计模式 安全 NoSQL
Java面试题:结合单例模式与Java内存管理,设计一个线程安全的单例类?分析Java多线程工具类ExecutorService与Java并发工具包中的工具类,设计一个Java并发框架的分布式锁实现
Java面试题:结合单例模式与Java内存管理,设计一个线程安全的单例类?分析Java多线程工具类ExecutorService与Java并发工具包中的工具类,设计一个Java并发框架的分布式锁实现
17 0
|
12天前
|
Java
实现Java多线程中的线程间通信
实现Java多线程中的线程间通信
|
13天前
|
Java
实现Java多线程中的线程间通信
实现Java多线程中的线程间通信
|
8天前
|
缓存 Linux 编译器
【Linux】多线程——线程概念|进程VS线程|线程控制(下)
【Linux】多线程——线程概念|进程VS线程|线程控制(下)
19 0
|
8天前
|
存储 Linux 调度
【Linux】多线程——线程概念|进程VS线程|线程控制(上)
【Linux】多线程——线程概念|进程VS线程|线程控制(上)
25 0
|
10天前
|
设计模式 并行计算 安全
Java面试题:如何使用设计模式优化多线程环境下的资源管理?Java内存模型与并发工具类的协同工作,描述ForkJoinPool的工作机制,并解释其在并行计算中的优势。如何根据任务特性调整线程池参数
Java面试题:如何使用设计模式优化多线程环境下的资源管理?Java内存模型与并发工具类的协同工作,描述ForkJoinPool的工作机制,并解释其在并行计算中的优势。如何根据任务特性调整线程池参数
13 0