Java并发

如何让Java的线程池顺序执行任务？

典型回答 Java中的线程池本身并不提供内置的方式来保证任务的顺序执行的，因为线程池的设计目的是为了提高并发性能和效率，如果顺序执行的话，那就和单线程没区别了。但是如果被问到想要实现这个功能该怎么做，有以下两种方式。 1、使用单线程线程池我们可以使用SingleThreadExecutor这种线程池来执行任务，因为这个线程池中只有一个线程，所以他可以保证任务可以按照提交任务被顺序执行。 1 2 3 4 5 6 ExecutorService executor = Executors.newSingleThreadExecutor(); executor.submit(task1); executor.submit(task2); executor.submit(task3); // 任务按照提交的顺序逐个执行 executor.shutdown(); 2、使用有依赖关系的任务调度方式可以使用ScheduledThreadPoolExecutor结合ScheduledFuture来实现任务的顺序执行。将任务按照顺序提交给线程池，每个任务的执行时间通过ScheduledFuture的get()方法等待前一个任务完成。 1 2 3 4 5 6 ScheduledExecutorService executor = Executors.newScheduledThreadPool(1); ScheduledFuture<?> future1 = executor.schedule(task1, 0, TimeUnit.MILLISECONDS); ScheduledFuture<?> future2 = executor.schedule(task2, future1.get(), TimeUnit.MILLISECONDS); ScheduledFuture<?> future3 = executor.schedule(task3, future2.get(), TimeUnit.MILLISECONDS); // 任务会按照依赖关系和前一个任务的执行时间逐个执行 executor.shutdown();

有了CAS为啥还需要volatile？

典型回答在AQS的实现中，维护了一个volatile的int类型的state变量。state变量的值修改的动作通过CAS来完成的。 CAS大家都知道，底层其实是在总线上面加了锁的，那为啥这里还需要这个volatile呢？没有回有什么问题吗？ ✅CAS在操作系统层面是如何保证原子性的？这个问题有的时候也这么问：解决并发问题，用CAS就够了么？其实，CAS只能保证原子性，即一个修改命令，以原子性的操作完成，中间不会被中断。但是并发编程中，我们要解决的问题还包括有序性和可见性。 ✅什么是Java内存模型？因为，CAS虽然提供了一种无锁的方式来原子地更新值，但它本身并不能保证变量修改的可见性。也就是说，一个线程可能已经通过CAS成功地改变了一个变量的值，但这个新值可能还没有被其他线程所看到，因为这个值可能仅仅存储在当前线程的本地内存中。这里可能有人还有疑惑，在https://www.yuque.com/hollis666/ec96i7/ed72dt8guaf4fvn8 中明明说"cmpxchg是基于 CPU 缓存一致性协议实现的，在多核 CPU 中，所有核心的缓存都是一致的。“这里咋又不保证可见性了呢？主要是因为这里把多核CPU的缓存之间的一致性和Java的多线程本地内存之间的一致性搞混了。即没有正确的理解MESI和JMM的作用。可以看下：https://www.yuque.com/hollis666/ec96i7/yx29gk7wsw26ec4r 而想要实现一个变量的可见性，就需要使用 volatile了。通过将AQS的状态变量声明为 volatile，我们可以确保这个变量的读写都是直接对主内存，这保证了一个线程对这个变量的修改对其他线程立即可见。这对于避免同步问题和内存一致性错误是至关重要的。 volatile除了可以保证数据的可见性之外，还有一个强大的功能，那就是他可以禁止指令重排优化，这就保证了代码的程序会严格按照代码的先后顺序执行。 ✅volatile是如何保证可见性和有序性的？所以，CAS和 volatile 在AQS中是互补的：**CAS提供原子性操作以避免锁的使用，而 volatile 确保修改的可见性和内存操作的有序性。**两者结合，使得AQS能够以一种高效且线程安全的方式管理同步状态。

有了MESI为啥还需要JMM？

典型回答 MESI协议和Java内存模型（JMM）虽然都旨在解决多线程环境中的数据一致性问题，但它们工作在不同的层面上，并且解决的问题范围和目的不同。 **MESI协议是硬件层面的缓存一致性协议，用于确保在多核处理器系统中，不同处理器缓存中的缓存内容保持数据一致性。**它主要关注的是处理器缓存之间的一致性问题，通过四种状态（Modified, Exclusive, Shared, Invalid）来控制和维护缓存数据的有效性和一致性。MESI协议是处理器设计和缓存协调机制的一部分，对于操作系统和上层应用来说是透明的。 ✅什么是MESI缓存一致性协议 Java内存模型（JMM）是一个Java中抽象出来的概念，它定义了Java程序中各种变量（线程共享变量）的访问规则，以及在JVM中将变量存储到内存和从内存中读取变量这两个操作的底层细节。在可见性方面，主要解决的是多个线程的本地内存之间的一致性问题。 JMM处理的是线程如何通过共享内存进行交互的问题，包括变量的读写、锁的获取释放以及volatile关键字的语义等。JMM旨在确保Java应用程序在多线程环境中能够正确地执行，提供了一系列规则和保证，以便开发者能够编写出线程安全的代码。 ✅什么是Java内存模型？所以他们有以下区别：抽象层次不同：MESI工作在硬件层面，直接处理CPU缓存之间的一致性；而JMM工作在软件层面，为Java程序提供跨平台的内存可见性和线程同步的抽象。目标不同：MESI的目标是降低多核处理器系统中缓存一致性维护的复杂度和开销，而JMM的目标是为Java程序提供一致且明确的内存访问行为。解决的问题范围：MESI解决的是缓存层面的数据一致性问题，而JMM解决的是线程之间通过共享内存交互时的可见性、原子性和有序性问题。应用的普适性：MESI是特定于处理器架构的实现，不同的处理器可能有不同的缓存一致性协议；JMM则是Java语言的一部分，适用于所有Java应用程序，无论它们运行在什么硬件平台上。总结一句话就是，MESI协议和JMM解决的是不同层次上的问题。MESI确保了底层硬件中多核CPU间缓存的一致性，而Java内存模型解决了Java的多个线程的本地内存之间的一致性（和几个核没关系）。所以，即使有了MESI这样的硬件层面的缓存一致性协议，Java内存模型仍然是必需的，它提供了软件层面上的Java中本地内存间的可见性和线程同步的保证。

sychronized是非公平锁吗，那么是如何体现的？

典型回答在多线程环境中，公平锁保证了等待获取锁的线程按照请求锁的顺序来获取锁。也就是说，先请求锁的线程会先获得锁。非公平锁则不保证等待获取锁的线程的执行顺序。这意味着即使某个线程最早请求锁，也可能会在其他后来请求锁的线程之后获得锁。非公平锁可能会导致“饥饿”问题，但通常具有更高的吞吐量。 ✅公平锁和非公平锁的区别？ synchronized 并没有明确规定锁的公平性，但在实际行为上来看，它是一种非公平锁。主要是因为**JVM在管理等待锁的线程时，并不遵循先来先服务的原则。**在多线程环境下，当多个线程尝试进入由 synchronized 保护的同步块或方法时，JVM 和操作系统的调度器并不保证哪个线程会首先获得锁。这意味着一个刚刚请求锁的线程可能会在已经等待较长时间的线程之前获得锁。这样的设计主要是出于性能考虑。非公平锁通常比公平锁具有更高的吞吐量，因为维护一个等待队列并确保线程按顺序获得锁会增加额外的开销。在大多数情况下，非公平锁能够提供更好的性能，而且简化了锁的实现。尽管 synchronized 的这种非公平性可能导致某些线程饥饿（即永远获取不到锁），但在实际应用中，由于大多数锁持有时间较短，这种情况出现的频率并不高。此外，JVM 的锁优化机制（如偏向锁、轻量级锁和锁膨胀）以及操作系统层面的线程调度策略也有助于减少饥饿问题的发生。

如何实现无锁化编程？

典型回答所谓无锁化编程是指在多线程环境下避免使用传统的锁（如 **synchronized** 或 **ReentrantLock**），从而减少由于锁竞争所带来的性能开销。但是需要注意，无锁化编程并非完全不使用锁，而是指通过原子操作保证线程之间的数据一致性和操作的原子性，而不需要显式的加锁和解锁操作。原子操作是指对某个共享变量的操作（如加法、减法、比较等）是不可分割的，不会被中断。在Java中，无锁化编程通常依赖于原子操作和 CAS机制。这些技术是硬件级别提供的支持，确保对共享数据的修改是不可中断的。原子操作是指在执行过程中不会被打断的操作，通常用于实现无锁的数据结构。Java 提供了一些支持原子操作的类，位于 java.util.concurrent.atomic 包下，如： AtomicInteger AtomicLong AtomicReference AtomicBoolean AtomicStampedReference AtomicMarkableReference 这些类通过内部的 CAS 操作来实现线程安全的原子操作，避免了显式锁的使用。 ✅什么是CAS？存在什么问题？扩展知识无锁编程的好处减少上下文切换：传统的锁在竞争时会引起线程上下文切换，导致性能下降。无锁化编程通过避免线程阻塞来减少这些开销。提高并发性：通过原子操作，多线程可以同时对共享资源进行操作，从而提高系统的并发性。避免死锁：无锁编程避免了锁的嵌套和资源争用，从而避免了死锁的发生。 cas真的无锁吗？ ✅CAS在操作系统层面是如何保证原子性的？

动态线程池的原理是什么？

典型回答所谓动态线程池，就是可以在运行时根据系统负载自动调整线程数量，相比传统固定线程池，它能更智能地应对流量波动，优化资源利用。这里面有3个关键点： 1、运行时 2、根据系统负载 3、调整线程数量这里面的第一点和第三点比较好理解，也很好实现，比如我们Java中的**ThreadPoolExecutor**来说，他提供了可以在运行时调整线程数量的方法，分别可以用**setCorePoolSize()**、**setMaximumPoolSize()**来调整核心线程数和最大线程数，调用之后立即生效。（只是数量生效，并不一定会立即创建这么多线程，真的用到才会再创建）除了线程数量，其实有时候还可能调整其他的东西，比如线程池中的队列的容量，这里可以用ResizableCapacityQueue来作为队列，这样就可以运行期对它进行调整了。那另外一个“根据系统负载”就不好理解了。想要根据系统负载作动态调整，那么首先得知道负载是什么情况，这就需要涉及到监控指标的采集，需要能采集到这些指标才行，具体哪些指标呢？我认为比较关键的是下面这几个：任务队列饱和度（当前队列大小 / 最大容量）线程活跃度（活跃线程数 / 总线程数）任务处理延迟（任务平均执行时间/排队时间）系统资源指标（CPU利用率、内存使用率、load等）怎么采集监控指标这个其实有很多办法，比如基于日志采集、比较简单，就是定时的调一下线程池的查询线程数、查询队列容量、队列大小等等的方法。至于机器上的其他的指标，比如load ，cpu这些也可以考成熟的采集工具，比如Prometheus，很多动态线程池也支持用Prometheus来做监控。（在我的数藏项目课中有演示过如果基于prometheus来配置线程池的监控以及动态调整）什么时候提高线程数？什么时候可以提升线程数？那肯定是线程数不够了，并且提高也不会对系统造成影响的情况下。什么时候可以认为线程数不够了？任务队列快满了，比如容量的80%都被占用了，说明很多任务在堆积了。什么时候可以认为不会对系统造成影响？那就是当CPU的利用率、Load处于一个正常水平的时候，比如Cpu利用率在70%以下，Load在0.75以下（这是单核的指标，如果是多核要乘以对应的核数）。 ✅4C8G的机器，各项系统指标，什么范围算是正常？那么也就是说，当任务队列增长到占了容量的80%，并且当前CPU利用率Cpu利用率在70%以下，Load在0.75以下，可以提升线程数。什么时候减小线程数为什么要减小线程数？因为线程数如果过多的话，会导致大量的上下文切换，100个任务，5个线程执行，和10个线程执行，上下文切换的次数肯定不一样。 ✅什么是多线程中的上下文切换？什么时候减小线程数？那肯定是用不上那么多线程的时候，比如当前空闲线程已经超过了50%，那么就可以减少线程池中的线程数量了。其他调整一些成熟的动态线程池框架，比如dynamicTp，不仅支持线程数调整，还支持队列容量和拒绝策略的调整。但是一般改的都不多。

如何在 Java 中实现高效的异步编程？如何避免回调地狱？

典型回答（这个不算是面试题了，面试很少这么问，大家知道下什么是callback hell即可，但是内容大家可以看下，对于在工作中的使用还是有帮助的。）在 Java 中实现高效的异步编程通常依赖于异步执行模型，例如通过 **CompletableFuture**、**ExecutorService**、**Future** 等方式，来处理异步任务。同时，避免回调地狱是实现异步编程时的一大挑战，特别是在多个异步操作需要顺序执行并且它们之间可能会相互依赖的情况下。回调地狱(callback hell)是指在使用传统回调方法时，如果有多个依赖关系的异步任务，代码会变得难以阅读和维护。 ExecutorService ExecutorService 是 Java 提供的一个高效的线程池管理工具，它支持异步任务的提交和执行。通过 submit() 方法提交任务，返回 Future 对象可以用于获取任务的执行结果。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 import java.util.concurrent.*; public class ExecutorServiceExample { public static void main(String[] args) throws InterruptedException, ExecutionException { ExecutorService executorService = Executors.newFixedThreadPool(2); // 提交一个异步任务 Future<Integer> future = executorService.submit(() -> { // 模拟一些异步操作 Thread.sleep(1000); return 42; // 返回计算结果 }); // 获取任务结果，阻塞直到任务完成 Integer result = future.get(); // result = 42 System.out.println("异步任务的结果: " + result); executorService.shutdown(); } } CompletableFuture CompletableFuture 是 Java 8 引入的一个功能强大的工具，用于支持异步计算和组合多个异步任务。与传统的 Future 不同，CompletableFuture 不仅可以异步执行任务，还可以通过链式调用的方式进行任务的组合与控制。 ...

什么是活锁，和死锁有什么区别？

典型回答 ✅什么是死锁，如何解决？死锁指的是两个或多个线程因为互相等待对方释放资源而卡住，程序无法继续执行。而活锁，指的是两个或多个线程在持续运行并改变状态，但它们的工作无法取得任何实质性进展。线程没有被阻塞，而是在不断地响应对方的状态变化，陷入一种无意义的“忙等待”循环。一般来说，会发生活锁的原因，主要是过度协作或不当的重试策略导致线程相互“礼让”或“退让”，结果谁也无法获得执行关键操作所需的稳定条件。就像两个人过在独木桥相遇： A 和 B 迎面走来，A 说“你先走”，B 说“你先走”；双方都后退一步；然后又同时前进，又撞到；然后又同时后退……反复循环，永远过不了桥。发生活锁后，虽然程序没有“卡死”，相关线程仍在消耗 CPU 资源（因为它们还在执行代码）。表面上有活动（日志可能显示线程在重试、回退、响应），但整体任务无进展。很多人看到这里，会认为CAS的自旋是活锁。但是其实这种最多是像活锁，但是他不是一种活锁。因为我们前面说过，活锁主要是因为过度协作导致的礼让。活锁是：A看到B过来就让开，B看到A让开也想让A先走，结果两人在门口一直让路谁也过不去（协作逻辑导致僵局）。 CAS自旋是：每个人都不断尝试快速挤过桥（执行CAS），如果发现桥被堵住了（CAS失败），就等一会再尝试挤过去。虽然大家挤来挤去可能暂时都过不去，但每个人都在尝试相同的“挤”的动作，没有互相让路的协作逻辑。 ...

介绍下JUC，都有哪些工具类？

典型回答 Java 的 JUC（java.util.concurrent）是 Java 并发编程的核心工具包，几乎所有高性能、多线程的 Java 应用都会用到它。从 JDK 1.5 开始引入，由 Doug Lea 主导开发。在 JUC 出现之前，Java 开发者主要依赖 **synchronized** 和 **Object** 的 **wait()/notify()** 等方式进行线程之间的同步（保证并发安全）。但是有很多缺点：粒度粗： **synchronized** 锁住的是整个对象或类，容易导致不必要的线程阻塞，降低并发性能。功能有限：难以实现复杂的同步需求，如读写锁、信号量、屏障等。易出错：手动管理 **wait()** 和 **notify()** 容易导致死锁等问题，代码难以编写和维护。性能瓶颈： **synchronized**是重量级锁，他的性能可能成为瓶颈。于是就出现了JUC，说白了就是提供了很多并发安全的工具类，帮助开发者来在并发场景下使用。JUC中的工具类会**通过细粒度锁、CAS、并发数据结构等大幅提升高并发场景下的吞吐量和响应速度。** ...

Java中有哪些锁_

典型回答这个问题可太大了，因为所有的锁都可以回答。因为我们可以根据不同的分类方式进行介绍。如果只提Java内置的锁的话，那么主要就是**synchronized**** 和****ReentrantLock**这两种锁。 ✅synchronized和reentrantLock区别？通过**synchronized**** 和****ReentrantLock**的相同点和不同点来说的话，可以有这么几种锁的定义。 **阻塞锁&非阻塞锁：**拿不到锁时线程挂起，直到被唤醒，比如 synchronized 、ReentrantLock都是阻塞锁。可重入锁VS不可重入锁：可重入锁：一个线程可以多次获取同一把锁（计数器+1，释放时-1），比如 synchronized、ReentrantLock。公平锁VS非公平锁：synchronized 和 ReentrantLock 默认都是非公平锁。 ✅公平锁和非公平锁的区别？偏向锁、轻量级锁、重量级锁：涉及到synchronized的锁膨胀的过程。 ✅synchronized的锁升级过程是怎样的？乐观锁VS悲观锁：这是代码中比较常用的用来做并发防控的，一般在数据库层面出现的比较多。synchronized、ReentrantLock都是悲观锁，CAS是乐观锁 ✅乐观锁与悲观锁如何实现？ **读写锁 VS StampedLock：**StampedLock支持悲观读锁、写锁，还支持乐观读，比 ReadWriteLock 性能更好。 **自旋锁：**线程不会立即阻塞，而是通过循环等待锁释放，避免线程切换开销。JVM 在 synchronized 的轻量级锁中用到。 ✅CAS一定有自旋吗？分布式锁VS 单机锁： ✅锁和分布式锁的核心区别是什么？数据库锁 ✅介绍下InnoDB的锁机制？无锁：如volatile、不可变模式、ThreadLocal等。（为啥要提这个，因为他也是一种解决并发问题的方案） ✅如何实现无锁化编程？活锁 VS 死锁 ✅什么是活锁，和死锁有什么区别？

留言给博主