给你比个心，渴望留住你 ^ 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是一个重要的补充！

1. synchronized只能加锁和解锁，加锁的时候发现锁被占用，就得阻塞等待
   • 而ReentrantLock 还提供了个 tryLock方法
   • 加锁成功返回true
   • 加锁失败不会阻塞而是返回false
     • 加锁失败后，拿这个false干什么呢？
     • 不会阻塞等待，让程序员灵活地自己决定接下来做什么
       • 也可以自旋，也可以挂起等待······
2. synchronized 是非公平锁 ---- 概率相等但是不遵循先来后到~
   • ReentrantLock 提供了公平锁和非公平锁两种工作模式
     • 构造方法传入 true ==> 开启公平锁，false ==> 开启非公平锁

3. 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本质其实就是个特殊的计数器，描述“可用资源”个数

1. P操作，申请资源，计数器-1 ===> accquire方法
2. 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);
}

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

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

   • 注意：一个线程结束，要调用countDownLatch.countDown方法，“宣布此选手下场”
     • 这也是绑定线程和countDownLatch的方式，并且线程安全！
     • 并且countDownLatch会暗中去计算还差几个人没下场

3. 然后调用countDownLatch.await()方法

   • 注意：在await方法调用前，必须有十个线程参赛，否则就无法退出阻塞！
   • 一旦countDownLatch计算得到全部下场了，就接触原线程的阻塞状态~

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

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

• Java中有很多现成的类是线程不安全的
  • 例如：ArrayList 、 LinkedList 、 HashMap 、Queue 、 Deque 、 PriorityQueue ······
  • DataSource只是读了数据源，是后续的一些操作去修改数据库，所以这也是线程安全的
• 在多线程环境下，我们要使用这些类，但是又害怕线程不安全，咋办？

1. 使用锁直接手动保证 — 对于修改操作加锁
2. 使用标准库提供的线程安全的集合类

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

结果：

手动加锁：

1. 因为非原子性，导致有些无效插入
2. 因为含扩容机制，导致未扩容完毕却被插入到未申请的位置！

    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 的区别

1. 加锁粒度的不同 — 核心区别！
   • 锁范围不同即触发锁冲突概率不同

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

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

• 如果是HashTable 则那些没被修改和读取的一样会被锁到
  • 那么我们在修改蓝区域和红区域的时候，就不能并发进行了！！！
  • 而我们知道，多线程修改不同变量是不会有线程安全的！

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

• 实现起来比较简单，因为计算哈希值后获取下标，得到链表头结点是线程安全的
• 之后获得的头结点针对性的加锁就行了

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

分段锁：

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

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

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

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

3. 优化扩容机制

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

• 而一旦表内元素太多太多了，那么每个键值是需要重新放在扩容后的表里的！搬运成本太高了！
• 指不定哪次的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编程的重要手段！

敬请期待后续内容！

---