关于并发最常见的十道面试题

面试题一：说一下线程池的拒绝策略有哪些？实际工作中会使用哪种拒绝策略？为什么？

线程池的拒绝策略主要有以下四种：

1. AbortPolicy：这个是默认的策略，当任务被拒绝的时候会抛出一个异常类型是RejectExecutionException的RuntimeException。这种策略可以让你感知到任务被拒绝了，因此正在关键的业务中推荐使用该策略
2. DiscardPolicy：这种策略是会直接丢弃被拒绝的任务，但是不会抛出异常。使用此策略的时候，可能无法发现系统的异常，建议一些无关紧要的业务采用该策略
3. DiscardOldestPolicy：如果线程池没有被关闭且没有能力执行，则会丢弃任务队列的头节点，通常是存活时间最长的任务，然后重新提交被拒绝的任务。这种策略较比DiscardPolicy不同之处就是在于他丢弃的不是最新提交的，而是队列中存活时间最长的，这样会给新提交的任务留出空间，但是会有数据丢失的风险
4. CallerRunsPolicy：如果线程池没有被关闭且没有执行能力，谁提交任务，谁就要负责执行该任务。这样有两点好处，新提交的任务不会被丢弃，不会造成业务损失。第二点，由谁提交任务谁就执行该任务，所以提交任务线程被占用，也不会再提交新任务，可以减轻任务提交速度
5. 使用自定义拒绝策略：自定义策略通过new RejectedExecutionHander实现，并重写rejectedExecution方法来实现，如：

   public class MyRejectedExecutionHandler implements RejectedExecutionHandler {
       @Override
       public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
           // 这里可以添加你的自定义逻辑
           System.out.println("任务被拒绝了");
       }
   }
   
   // 使用自定义的拒绝策略
   ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 1,
           0L, TimeUnit.MILLISECONDS,
           new LinkedBlockingQueue<Runnable>(1),
           new MyRejectedExecutionHandler());
   

实际开发中我们会使用哪种拒绝策略呢？

实际开发中我们会使用自定义拒绝策略，因为在自定义拒绝策略灵活好控制，可以在自定义拒绝策略中发送一条通知给消息中心，让消息中心发送告警信息给开发者，这样可以实时的监控线程池的运行状况，并能及时发现和排查问题。

面试题二：如何判断线程池中的任务是否执行完成？

判断线程池任务执行是否完成，有以下几种方法：

?isTerminated（）：线程池提供了一个原生函数isTerminated()来判断线程池中的任务是否全部完成。当线程池中所有任务都执行完成之后，线程池就会进入终止状态，此时调用isTerminated（）方法返回的结果就是true

ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(5);
// 提交任务
executor.execute(() -> {
    // 任务代码
});
// 关闭线程池
executor.shutdown();
// 判断任务是否完成
if (executor.isTerminated()) {
    System.out.println("所有任务已完成");
}

getCompletedTaskCount（）：我们可以通过判断线程池中计划执行任务和已完成任务，来判断线程池是否已经执行完成。如果相等就代表已经执行完成了

ThreadPoolExecutor executor = (ThreadPoolExecutor) Executors.newFixedThreadPool(5);
// 提交任务
executor.execute(() -> {
    // 任务代码
});
// 判断任务是否完成
if (executor.getTaskCount() == executor.getCompletedTaskCount()) {
    System.out.println("所有任务已完成");
}

FutureTask（）：当你提交一个Callable或者RRunnable任务到达线程池的时候，你可以将它包装到一个FutureTask对象中。然后调用FutureTask的get（）方法来获取任务的结果，如果任务没有完成，get（）方法将会阻塞，直到任务完成并且结果可用。所以，只要get（）方法有返回结果，就直到任务是否完成

// 创建一个 Callable 任务
Callable<Integer> task = new Callable<Integer>() {
    @Override
    public Integer call() throws Exception {
        // 执行任务，返回结果
        return doSomeWork();
    }
};

// 创建一个 FutureTask 对象来包装任务
FutureTask<Integer> futureTask = new FutureTask<>(task);

// 提交任务到线程池
ExecutorService executor = Executors.newFixedThreadPool(1);
executor.execute(futureTask);

// 获取任务结果
try {
    Integer result = futureTask.get();  // 这里会阻塞，直到任务完成
    System.out.println("任务已完成，结果是：" + result);
} catch (InterruptedException | ExecutionException e) {
    e.printStackTrace();
}

?面试题三：?导致线程安全问题的因素有哪些

导致线程安全问题的主要问题有以下几点：

1. 多线程同时执行：多个线程同时执行是造成并发问题的根本原因
2. 操作共享数据：当多个线程访问和修改同一块数据时，可能导致数据覆盖，数据可见性等问题
3. 非原子操作：某些操作看起来是单个语句，但是在计算机内部被分为多个步骤。如果这些操作在多线程环境下没有适当同步，就会导致线程安全问题
4. 指令重排序：编译器和处理器为了优化性能，可能会对代码进行重新排序。这种重排序在单线程环境下是安全的，但是在多线程环境下可能就会出现意料之外结果
5. 内存可见性：在多线程之下，一个线程对共享变量的修改不能立即被其他线程所发现。这是因为每一个线程都有自己的本地缓存，而且编译器和处理器可能会进行各种优化

面试题四：解决线程安全问题的手段有哪些？

解决线程安全问题的手段主要有以下几种：

• 使用锁：Java中提供了synchronized关键字和ReentrantLock类来实现锁机制。通过在可能出现线程安全问题的代码块或者方法上锁，可以确保只有一个线程可以执行这部分代码
• 使用线程本地变量：ThreaadLocal类可以为每一个线程提供一个独立的变量副本。通过使用线程本地变量，可以让每个线程都有自己的变量，从而避免线程间的数据冲突

• // 创建一个 ThreadLocal 对象
  ThreadLocal<String> threadLocal = new ThreadLocal<>();
  
  // 在每个线程中设置和获取线程本地变量的值
  new Thread(() -> {
      threadLocal.set("线程1的值");
      System.out.println(Thread.currentThread().getName() + ": " + threadLocal.get());
  }).start();
  
  new Thread(() -> {
      threadLocal.set("线程2的值");
      System.out.println(Thread.currentThread().getName() + ": " + threadLocal.get());
  }).start();
  

• 使用乐观锁机制：乐观锁是一种并发控制的策略，它假设多个线程在执行时不会发生冲突，只在提交操作的时候才会检查是否存在冲突。如果存在，就会重新尝试操作，直到没有冲突
• 使用线程安全的容器：如ConcurrentHashMap、CopyOnWriteArrayList

面试题五：synchronized 底层是如何实现的？

synchronized是Java中的一个关键字，用于实现线程同步，保证在同一时刻，只有一个线程执行特定的代码块。它的实现主要是依赖于JVM中的一个叫做监视器锁（monitor）的机制，而监视器又是以来操作系统的互斥锁Mutex实现的

当一个线程进入到一个synchronized代码块的时候，它需要获取一个与该代码块关联的monitor对象的所有权。如果获取成功，那么该线程就可以执行synchronized代码块的代码。当代码执行完毕后，线程会释放monitor对象的所有权。这样，其他线程就可以获取monitor对象的所有权，进入到代码块中。

public class SynchronizedToMonitorExample {
    private static int count = 0;

    public static void main(String[] args) {
        synchronized (SynchronizedToMonitorExample.class) {
            for (int i = 0; i < 10; i++) {
                count++;
                System.out.println(count);
            }
        }
    }
}

当我们将上诉代码编译成字节码之后，得到的结果是：

我们可以看出在main方法中多了一对monitorenter和monitorexit的指令，他们的含义是：

• monitorenter：表示进入监视器
• monitorexit：表示退出监视器

由此可知，synchronized是依赖Monitor监视器实现的

面试题六：说一下 synchronized 锁升级的流程？

synchronized锁的升级流程主要分为以下几步：

1. 无锁状态：的当一个对象刚刚被创建的时候，它处于无锁状态
2. 偏向锁：当一个线程首次访问一个synnchronized代码块时，JVM会将对象投中的锁标志位设置成01，表示偏向锁。同时，JVM会将对象头中的线程ID设置成当前线程的ID。这样，当同一个线程再次访问该synchronized代码块的时候，JVM只需要检查对象头中的线程ID是否与当前线程ID相同，如果相同，那么就可以直接进入synchronized代码块中，无需进行其他同步操作
3. 轻量级锁：当有其他线程试图访问同一个synchronized代码块的时候，偏向锁则会升级成轻量级锁。此时，JVM会暂停已经进入synchronized的代码块的线程，撤销其在对象头中的偏向锁，然后将对象头中的锁标志位设置成00，表示轻量级锁。然后，JVM会让两个竞争的线程分别进行一次CAS操作，尝试获取轻量级锁。如果有一个线程的CAS操作成功，那么这个线程就可以进入synchronized代码块
4. 重量级锁：如果轻量级锁的竞争失败，那么锁就会升级成重量级锁。此时，JVM会将对象头中的标志位设置成10，表示重量级锁。然后，JVM会将所有请求该锁的线程放入到一个等待队列，这些线程会被阻塞，直到获取到锁

?面试题七：synchronized 是固定自旋次数吗？

在Java中，synchronized锁的自旋次数是不固定的。自旋次数是通过JVM在运行时收集的统计信息，动态调整自旋锁的自旋次数上界，这种机制称为自适应自旋锁。

自旋：就是当一个线程尝试去获取一个已经被其他线程所持有的锁时，它并不是立即阻塞，而是进行一个无意义的循环，看看是否锁已经释放并直接进行竞争上岗步骤，如果竞争不到继续自旋循环，循环过程中线程状态一直处于running状态

虽然自旋锁方式省去了阻塞线程的时间和空间（队列的维护等）开销，但是长时间自旋也是很低效的。所以自旋的次数一般控制在一个范围内，例如10,50等，在超出这个范围后，线程就进入排队队列

面试题八：synchronized 和 ReentrantLock 有什么区别？

synchronized和ReentrantLock都是Java中的同步机制，用于在多线程环境中保护共享资源的访问，但是它们之间存在着一些区别：

1. 实现方式：synchronized是JVM层面的锁，通过monitor对象来完成的，而ReentrantLock是从JDK 1.5以来提供的API层面上的锁
2. 锁的释放：synchronized不需要用户去手动释放锁，当synchronized代码执行完后系统会自动让线程对锁进行释放；而ReentrantLock则需要用户去手动的释放锁，如果没有手动释放，就会导致死锁的现象。一般通过lock（）和unlock进行操作
3. 响应中断：synchronized是不可中断类型的锁，除非加锁的代码中出现了异常或者正常执行完成；而ReentrantLock则可以响应中断，可以通过 tryLock(long timeout, TimeUnit unit) 设置超时方法或者将 lockInterruptibly() 放到代码块中，调用 interrupt 方法进行中断
4. 公平性：synchronized是非公平锁，而ReentrantLock可以选择时公平锁还是非公平锁，通过构造方法 new ReentrantLock() 时传入 boolean 值进行选择，为空默认 false 非公平锁，true 为公平锁（公平锁是一种锁的机制，它保证了多个线程按照申请锁的顺序去获得锁。也就是说，如果多个线程同时请求同一个锁，那么最先请求的线程将最先获得锁。这种机制确保了所有的线程都有机会获得锁，不会出现某个线程长时间等待锁而无法获得的情况）

ReentrantLock的代码举例：

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockExample {
    private final ReentrantLock lock = new ReentrantLock();
    private int count = 0;

    public void incrementCount() {
        lock.lock();  // 加锁
        try {
            count++;
        } finally {
            lock.unlock();  // 释放锁
        }
    }

    public int getCount() {
        return count;
    }
}

面试题九：volatile 能保证线程安全吗？为什么？

volatile不能保证线程的安全。volatile的作用有两个：保证内存的可见性和禁止指令重排序。

• 保证内存可见性：当一个线程修改了 volatile 修饰的变量后，其他线程能够立即读取到该变量的最新值。
• 禁止指令重排序：volatile 变量的读写操作不会被编译器优化而进行重排序。

由于volatile不能保证原子性，而原子性也是导致线程不安全的因素之一，所以volatile不能保证线程安全

面试题十：volatile 在实际工作中，有那些使用场景？

volatile 在实际工作中，使用场景如下：

单例模式（双重检查锁定）：在单例模式等场景下，volatile可以配合使用双重检查锁定来确保只有一个实例被创建。在获取实例的时候，通过队实力对象进行volatile见你查，确保其他线程能够正确读取已创建实例，如代码：

public class Singleton {
    private Singleton() {}

    private static volatile Singleton instance = null;

    public static Singleton getInstance() {
        if (instance == null) {  // 1
            synchronized (Singleton.class) {
                if (instance == null) {  // 2
                    instance = new Singleton();  // 3
                }
            }
        }
        return instance;
    }
}

定时任务控制标志：在一些定时任务中，可能需要用到标志位来控制任务的启停。通过将标志位声明为volatile，确保在修改标志位的时候能够立即被其他线程所见，并即使停止或者启动相关任务

public class MyThread extends Thread {
    private volatile boolean flag = true;

    public void stopThread() {
        flag = false;
    }

    @Override
    public void run() {
        while (flag) {
           
        }
    }
}

线程间消息通知：当一个线程需要向另一个线程发送通知的时候，可以使用volatile作为信号量。当一个线程修改了volatile变量的值时，其他线程能够立即看到变化，从而得知有新消息发送

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??