直入主题：
Q1：为什么要用分布式锁？
在分布式系统中，多个进程或线程可能会同时访问共享资源，这可能会导致数据不一致、并发性问题、性能下降等问题。为了解决这些问题，我们通常会使用分布式锁来协调多个进程或线程对共享资源的访问。
分布式锁是一种协调机制，它通过在共享资源上设置锁来防止多个进程或线程同时访问它。分布式锁的主要作用如下：
保证数据的一致性：通过分布式锁来控制对共享资源的访问，可以避免多个进程或线程同时修改同一份数据而导致的数据不一致问题。
提高并发性：通过使用分布式锁，可以保证每个进程或线程在访问共享资源时都是排他的，从而避免了并发访问的问题，提高了系统的并发性。
避免死锁：分布式锁通常会设置超时时间，当一个进程或线程获取到锁后在一定时间内未能完成操作，锁会自动释放，避免了死锁的问题。
总之，使用分布式锁可以帮助我们在分布式系统中实现数据的一致性、提高系统的并发性和稳定性，从而保证系统的可靠性和高可用性。
Q2：分布式锁用的redis的哪种结构？
Redis提供了多种实现分布式锁的方式，常见的有以下两种：
基于SETNX命令的实现方式：该方式利用Redis的SETNX命令实现分布式锁，具体实现流程如下：
- 在Redis中创建一个键值对，键为锁的名称，值为任意字符串；
- 当某个进程需要获取锁时，它通过SETNX命令尝试在Redis中创建该锁对应的键值对，如果创建成功（即返回1），则该进程获取到锁，如果创建失败（即返回0），则该进程获取锁失败；
- 当某个进程需要释放锁时，它通过DEL命令删除该锁对应的键值对。
基于Redlock算法的实现方式：该方式是一种分布式锁的算法，由Redis官方提出，基于多个Redis实例之间的协调实现分布式锁，具体实现流程如下：
- 在多个Redis实例上创建相同的锁，即相同的锁名称和锁值；
- 当某个进程需要获取锁时，它依次在多个Redis实例上获取锁，每个Redis实例的获取锁过程与上述基于SETNX命令的方式类似；
- 当某个进程需要释放锁时，它依次在多个Redis实例上释放锁，每个Redis实例的释放锁过程与上述基于SETNX命令的方式类似；
- Redlock算法规定，只有当大多数（超过半数）的Redis实例上的锁都被某个进程获取时，该进程才算获取到了锁。
以上两种方式都是基于Redis的数据结构实现的分布式锁，具体实现方式有所不同，但都可以有效地解决分布式系统中的并发问题。
Q3：为什么字符串结构不能用来做分布式？
Redis中的字符串结构可以用来存储数据，但不能用来实现分布式锁。这是因为，在分布式系统中，多个进程或线程可能同时访问共享资源，为了保证数据的一致性和正确性，需要实现对共享资源的互斥访问。而字符串结构并不支持互斥访问，也就无法保证共享资源的正确性和一致性。
另外，即使是对于单机环境，使用字符串结构来实现锁也是不可行的。因为在Redis中，字符串是原子操作的，即每次操作都是原子性的，但在分布式系统中，多个进程或线程之间的操作是不可预测的，可能会导致竞态条件（race condition）和锁失效的问题。
因此，在分布式系统中实现锁需要使用Redis提供的其他数据结构，如上文提到的基于SETNX命令的实现方式和基于Redlock算法的实现方式。这些数据结构支持互斥访问和分布式协作，可以实现分布式系统中的锁功能，从而保证数据的正确性和一致性。
Q4：分布式锁可能会失效的场景是什么？
在分布式系统中，分布式锁是用来协调多个进程或线程之间对共享资源的访问的，以保证数据的正确性和一致性。但由于分布式系统的复杂性，分布式锁可能会出现一些失效的场景，如下：
网络延迟或丢包：由于网络不可靠，分布式系统中的消息可能会出现延迟或丢失的情况，如果分布式锁的实现依赖于网络通信，这些问题就可能导致锁失效。
节点故障：在分布式系统中，节点故障是常见的情况，如果锁实现依赖于某个节点或实例，当该节点或实例故障时，锁也可能会失效。
时钟不同步：分布式系统中的时钟可能不同步，导致各个节点之间无法达成一致，如果锁实现依赖于时间戳或过期时间等机制，就可能导致锁失效。
重入问题：如果一个线程已经获得了分布式锁，并且在持有锁的情况下再次尝试获取锁，就会导致死锁或者其他异常情况。
锁误释放：如果持有锁的进程或线程在释放锁时出现异常，比如进程崩溃或者网络故障等，就可能导致锁没有正确释放，其他进程或线程无法获得锁，从而导致锁失效。
针对上述场景，可以通过一些技术手段来减少分布式锁失效的风险，比如增加重试机制、使用心跳机制等。但是要注意，分布式锁的失效场景是很复杂的，需要根据具体的业务场景和系统架构进行综合分析和解决。
Q5：spring声明式事务失效场景有哪些？
Spring声明式事务是通过AOP实现的，它的原理是对被@Transactional注解的方法进行代理，然后在方法执行前后进行一些操作，如开启和提交事务、回滚等。在以下场景中，声明式事务可能会失效：
事务传播行为设置不当：Spring声明式事务默认使用Propagation.REQUIRED传播行为，如果在调用方法的过程中使用了不同的传播行为，就可能导致事务失效。
异常被吞掉：在方法中捕获了异常但没有将其重新抛出或者没有将其抛给调用方，则可能会导致事务无法回滚。
基于接口的代理：如果使用了基于接口的代理，且在实现类中调用了自己的另一个方法，那么该方法调用将不会被事务管理。
多线程情况：当使用多线程时，若子线程的事务处理方法没有被@Transactional注解，则可能会导致事务失效。
数据库引擎不支持事务：如果使用的数据库引擎不支持事务，则声明式事务将会失效。
注解放错位置：如果@Transactional注解放置在类上而不是方法上，则事务将不会生效。
不同的异常类型：如果使用了不同的异常类型，例如RuntimeException而不是Exception，那么事务可能不会回滚。
总之，要确保声明式事务的有效性，应该在调用方法上正确使用@Transactional注解，设置正确的传播行为，避免吞掉异常，同时注意多线程和数据库引擎等因素。
Q6：嵌套事务有什么影响？
在Spring中，嵌套事务是一种事务传播行为，它允许一个事务在另一个事务的上下文中开启，形成一个事务嵌套的结构。
使用嵌套事务可能会对事务的行为产生一些影响，例如：
回滚行为：当嵌套事务的回滚行为发生时，会影响到外层事务的状态。如果内层事务回滚，则会导致外层事务也回滚；而外层事务的回滚不会影响到内层事务。
性能开销：每个嵌套的事务都需要开启和提交或回滚，这会带来一些性能开销。
数据一致性：使用嵌套事务时，需要确保内层事务的提交不会影响到外层事务的数据一致性，否则会导致不一致的结果。
因此，在使用嵌套事务时，需要考虑以上因素，并确保在需要使用嵌套事务时，合理地设置事务传播行为和隔离级别，以保证数据一致性和事务性能。
Q7：springboot怎么进行异步处理？
在Spring Boot中进行异步处理有多种方式，其中一些常见的方式包括：
- 使用@Async注解：通过在方法上添加@Async注解，使方法在异步线程中执行，可以使用Spring Boot自带的线程池来管理线程。需要在启动类中添加@EnableAsync注解开启异步处理。
示例代码：
@Servicepublic class MyService { @Async public CompletableFuture asyncMethod() { // 异步方法逻辑 return CompletableFuture.completedFuture("异步方法执行完成"); }}
- 使用CompletableFuture类：CompletableFuture类提供了方便的异步处理方式，可以通过supplyAsync或runAsync方法创建一个异步任务，并指定异步任务的执行逻辑。通过thenApply等方法可以对异步任务的执行结果进行处理。
示例代码：
@Servicepublic class MyService { public CompletableFuture asyncMethod() { return CompletableFuture.supplyAsync(() -> { // 异步方法逻辑 return "异步方法执行完成"; }); }}
- 使用@Scheduled注解：可以使用@Scheduled注解创建定时任务，在任务执行时指定执行逻辑。
示例代码：
@Servicepublic class MyService { @Scheduled(fixedDelay = 1000) public void scheduledMethod() { // 定时任务执行逻辑 }}需要注意的是，使用异步处理可能会引发一些并发问题，例如线程安全问题、死锁问题等，需要根据实际场景进行合理的设计和优化。
Q8：spring注解使用默认线程池还是自定义线程池？
Spring中默认情况下使用的是简单的线程池（SimpleAsyncTaskExecutor），该线程池没有队列容量限制，每次调用都会创建一个新的线程，不适用于大规模的并发请求。因此，在实际应用中，应该使用自定义的线程池来处理异步任务。
可以使用ThreadPoolTaskExecutor或者ConcurrentTaskExecutor来创建自定义的线程池，具体选择哪种线程池取决于具体的应用场景。ThreadPoolTaskExecutor是一种基于Java线程池的实现，可以灵活地配置核心线程数、最大线程数、队列容量等参数；而ConcurrentTaskExecutor是一种基于Java并发包的实现，可以实现更高的并发性能，但是线程池的配置选项较少。
在使用自定义线程池时，可以通过配置ThreadPoolTaskExecutor或者ConcurrentTaskExecutor的相关参数来优化线程池的性能，例如配置核心线程数、最大线程数、队列容量、线程存活时间等参数。同时，在设计应用程序时，还需要根据实际情况合理地使用线程池，避免线程安全问题和线程饥饿等问题的发生。
以下是一个简单的自定义线程池的示例代码：
import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;import org.springframework.scheduling.annotation.EnableAsync;import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;import java.util.concurrent.Executor;@Configuration@EnableAsyncpublic class AppConfig { @Bean public Executor asyncExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); // 核心线程数 executor.setMaxPoolSize(10); // 最大线程数 executor.setQueueCapacity(25); // 队列容量 executor.setThreadNamePrefix("MyExecutor-"); // 线程名前缀 executor.initialize(); // 初始化线程池 return executor; }} 上述代码中，通过@Bean注解将创建的ThreadPoolTaskExecutor类实例化为Spring的Bean，并使用@EnableAsync注解启用异步处理功能。在创建线程池时，可以通过setCorePoolSize、setMaxPoolSize、setQueueCapacity等方法设置线程池的核心线程数、最大线程数和队列容量等参数，并通过setThreadNamePrefix方法设置线程名前缀。最后通过initialize方法初始化线程池，并将线程池返回为一个Executor类型的Bean。
使用上述自定义线程池的示例：
import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;import java.util.concurrent.CompletableFuture;import java.util.concurrent.Executor;@Servicepublic class MyService { @Autowired private Executor asyncExecutor; // 注入自定义线程池 public CompletableFuture asyncMethod() { return CompletableFuture.supplyAsync(() -> { // 异步方法逻辑 return "异步方法执行完成"; }, asyncExecutor); // 指定使用自定义线程池 }}在上述示例代码中，通过@Autowired注解将自定义的线程池注入到MyService类中，并在异步方法中通过supplyAsync方法指定使用自定义线程池来执行异步任务。
Q9：说一下常见的几个线程池？
在Java中，线程池是一种重要的并发编程工具，可以避免创建和销毁线程带来的性能开销和资源浪费，提高应用程序的性能和稳定性。Java标准库中提供了许多不同类型的线程池，常见的几个线程池包括：
FixedThreadPool：固定线程池，所有任务都在同一个固定大小的线程池中执行，适用于需要保证并发线程数不超过指定数量的场景。
CachedThreadPool：缓存线程池，可以动态调整线程数，适用于需要处理大量短时间任务的场景。
SingleThreadExecutor：单线程池，只有一个线程在执行任务，适用于需要按顺序执行任务或保证任务的线程安全性的场景。
ScheduledThreadPool：调度线程池，支持按照指定的时间间隔或者时间点执行任务，适用于需要按照特定时间执行任务的场景。
WorkStealingPool：工作窃取线程池，可以动态调整线程数并支持线程间任务窃取，适用于需要处理大量短时间任务且任务之间存在依赖关系的场景。
ForkJoinPool：分治线程池，支持任务拆分和合并，适用于需要处理大量并行计算任务的场景。
这些线程池都有各自的优点和适用场景，在实际应用中需要根据具体的需求选择合适的线程池。同时，在使用线程池时，还需要合理地配置线程池参数，以充分利用计算机的资源，提高线程池的执行效率。
Q10：讲下核心线程数，最大线程数，超时时间，等待队列等
在Java中，线程池是一种重要的并发编程工具，常见的线程池参数包括：
核心线程数（corePoolSize）：指线程池中最少保持的活动线程数，当线程池中的线程数小于该值时，新任务将会创建新的线程来处理。对于FixedThreadPool和SingleThreadExecutor，核心线程数即为线程池的大小；对于其他线程池，核心线程数将会一直保持活动状态，直到线程池关闭。
最大线程数（maximumPoolSize）：指线程池中最大可创建的线程数。当线程池中的线程数达到该值时，新任务将会被阻塞，直到有空闲线程可用。对于FixedThreadPool，最大线程数即为线程池的大小；对于其他线程池，最大线程数可以根据实际需求进行配置。
超时时间（keepAliveTime）：指线程池中空闲线程的存活时间。当线程池中的线程数超过核心线程数时，空闲线程将会在指定时间内被回收。对于其他线程池，如果空闲线程超过该时间，也会被回收。
等待队列（workQueue）：指线程池中的任务队列，用于存放等待执行的任务。线程池中的任务将会依次被放入该队列中，直到有空闲线程可用。对于FixedThreadPool和SingleThreadExecutor，任务队列为空；对于其他线程池，任务队列可以根据实际需求进行配置，常见的队列类型包括有界队列（ArrayBlockingQueue、LinkedBlockingQueue）和无界队列（SynchronousQueue）。
这些线程池参数都会对线程池的性能和行为产生影响，需要根据实际应用场景进行合理的配置。例如，如果任务的执行时间较长，可以适当增加线程池的最大线程数，以避免任务阻塞；如果任务的数量较多，可以增加等待队列的大小，以缓解线程池的压力。同时，还需要注意线程池的可扩展性和性能，以避免线程池成为应用程序的瓶颈。
暂未结束，下篇见~