面试——并发篇

但盼风雨来能留你在此

已于 2022-10-15 15:15:15 修改

阅读量570

点赞数

分类专栏：面试文章标签：面试

于 2021-11-13 13:37:17 首次发布

本文链接：https://blog.csdn.net/weixin_56697114/article/details/121220525

版权

面试专栏收录该内容

7 篇文章 0 订阅

订阅专栏

4、lock vs synchronized

7、Hashtable vs ConcurrentHashMap

1、线程状态

线程的六种状态：

五种状态：

五种状态的说法来自于操作系统层面的划分

就绪：可以分到cpu

运行：分到cpu

阻塞：不能分到cpu

RUNNABLE涵盖了就绪、运行、阻塞I/O

2、线程池

线程池的 7 大核心参数

corePoolSize 核心线程数目 —— 池中会保留的最多线程数
maximumPoolSize 最大线程数目 —— 核心线程+救急线程的最大数目
keepAliveTime 生存时间 —— 救急线程的生存时间，生存时间内没有新任务，此线程资源会释放
unit 时间单位 —— 救急线程的生存时间单位，如秒、毫秒等
workQueue —— 阻塞队列，当没有空闲核心线程时，新来任务会加入到此队列排队，队列满会创建救急线程执行任务
threadFactory 线程工厂 —— 可以定制线程对象的创建，例如设置线程名字、是否是守护线程等
handler 拒绝策略 —— 当所有线程都在繁忙，workQueue 也放满时，会触发拒绝策略

抛异常 java.util.concurrent.ThreadPoolExecutor.AbortPolicy
        由调用者执行任务 java.util.concurrent.ThreadPoolExecutor.CallerRunsPolicy
        丢弃任务 java.util.concurrent.ThreadPoolExecutor.DiscardPolicy
        丢弃最早排队任务 java.util.concurrent.ThreadPoolExecutor.DiscardOldestPolicy

3、wait vs sleep

共同点

wait() ，wait(long) 和 sleep(long) 的效果都是让当前线程暂时放弃 CPU 的使用权，进入阻塞状态

不同点

方法归属不同

sleep(long) 是 Thread 的静态方法
而 wait()，wait(long) 都是 Object 的成员方法，每个对象都有

醒来时机不同

执行 sleep(long) 和 wait(long) 的线程都会在等待相应毫秒后醒来
wait(long) 和 wait() 还可以被 notify 唤醒，wait() 如果不唤醒就一直等下去
它们都可以被打断唤醒

锁特性不同（重点）

wait 方法的调用必须先获取 wait 对象的锁，而 sleep 则无此限制
wait 方法执行后会释放对象锁，允许其它线程获得该对象锁（我放弃 cpu，但你们还可以用）
而 sleep 如果在 synchronized 代码块中执行，并不会释放对象锁（我放弃 cpu，你们也用不了）

4、lock vs synchronized

语法层面

synchronized 是关键字，源码在 jvm 中，用 c++ 语言实现
Lock 是接口，源码由 jdk 提供，用 java 语言实现
使用 synchronized 时，退出同步代码块锁会自动释放，而使用 Lock 时，需要手动调用 unlock 方法释放锁

功能层面

二者均属于悲观锁、都具备基本的互斥、同步、锁重入功能
Lock 提供了许多 synchronized 不具备的功能，例如获取等待状态、公平锁、可打断、可超时、多条件变量
Lock 有适合不同场景的实现，如 ReentrantLock， ReentrantReadWriteLock

性能层面

在没有竞争时，synchronized 做了很多优化，如偏向锁、轻量级锁，性能不赖
在竞争激烈时，Lock 的实现通常会提供更好的性能

公平锁

公平锁的公平体现

已经处在阻塞队列中的线程（不考虑超时）始终都是公平的，先进先出
公平锁是指未处于阻塞队列中的线程来争抢锁，如果队列不为空，则老实到队尾等待
非公平锁是指未处于阻塞队列中的线程来争抢锁，与队列头唤醒的线程去竞争，谁抢到算谁的

公平锁会降低吞吐量，一般不用

条件变量

ReentrantLock 中的条件变量功能类似于普通 synchronized 的 wait，notify，用在当线程获得锁后，发现条件不满足时，临时等待的链表结构与 synchronized 的等待集合不同之处在于，ReentrantLock 中的条件变量可以有多个，可以实现更精细的等待、唤醒控制

static Condition c1 = LOCK.newCondition("c1");
static Condition c2 = LOCK.newCondition("c2");

当持锁线程条件不满足，不能运行接下来的代码，进入c1.await()中等待，当条件满足就会c1.singal()唤醒，从停止的地方继续开始执行。

5、volatile

线程安全要考虑的三个方面：可见性、原子性、有序性

volatile只能保证可见性、有序性，不能保证原子性

原子性

一个线程内多行代码以一个整体运行，运行期间不能其它线程的代码插队

起因：多线程下，不同线程的指令发生了交错导致的共享变量的读写混乱
解决：用悲观锁或乐观锁解决，volatile 并不能解决原子性

可见性

一个线程对共享变量修改，其它线程能看到最新的结果

起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化，导致的对共享变量所做的修改另外的线程看不到
解决：用 volatile 修饰共享变量，能够防止编译器等优化发生，让一个线程对共享变量的修改对另一个线程可见

有序性

一个线程内代码按编写顺序执行

起因：由于编译器优化、或缓存优化、或 CPU 指令重排序优化导致指令的实际执行顺序与编写顺序不一致
解决：用 volatile 修饰共享变量会在读、写共享变量时加入不同的屏障，阻止其他读写操作越过屏障，从而达到阻止重排序的效果
注意：

volatile 变量写**加的屏障是阻止上方其它写操作越过屏障排到 **volatile 变量写**之下
volatile 变量读**加的屏障是阻止下方其它读操作越过屏障排到 **volatile 变量读**之上
volatile 读写加入的屏障只能防止同一线程内的指令重排

6、悲观锁 vs 乐观锁

悲观锁的代表是 synchronized 和 Lock 锁

其核心思想是【线程只有占有了锁，才能去操作共享变量，每次只有一个线程占锁成功，获取锁失败的线程，都得停下来等待】
线程从运行到阻塞、再从阻塞到唤醒，涉及线程上下文切换，如果频繁发生，影响性能
实际上，线程在获取 synchronized 和 Lock 锁时，如果锁已被占用，都会做几次重试操作，减少阻塞的机会

乐观锁的代表是 AtomicInteger，使用 cas 来保证原子性

其核心思想是【无需加锁，每次只有一个线程能成功修改共享变量，其它失败的线程不需要停止，不断重试直至成功】
由于线程一直运行，不需要阻塞，因此不涉及线程上下文切换
它需要多核 cpu 支持，且线程数不应超过 cpu 核数

    //AtomicInteger的底层Unsafe，对于乐观锁，修改共享变量的操作是一个原子操作
    static final Unsafe U = Unsafe.getUnsafe();
    //变量的偏移位置
    static final long BALANCE = U.objectFieldOffset(Account.class, "balance");

    static class Account {
        volatile int balance = 10;
    }

    private static void basicCas(Account account) {
        while (true) {
            //修改之前的旧值
            int o = account.balance;
            int n = o + 5;
            //比较并交换，在修改之前，其它线程完成了修改，o会与balance比较，不一致则false
            if(U.compareAndSetInt(account, BALANCE, o, n)){
                break;
            }
        }
        System.out.println(account.balance);
    }