2024年4月18号技术面试总结-CSDN博客

本文链接：https://blog.csdn.net/wodetongnian/article/details/137976321

1.什么是微服务雪崩？微服务雪崩的解决方案？

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩。服务A依赖于服务B，服务A依赖于服务D。现在假设，服务D出现了故障！

它访问这个服务D就必然要等待服务D的结果,那因为服务D出现了故障，那必然不能返回结果，结果就是它会阻塞在这里。
这就导致了服务A内部的这个业务是不是也会阻塞在这里？阻塞就会导致它不会释放服务器的连接。假如再有其他服务它们依赖于服务A，那么这些依赖于服务A的这些业务是不是也会拖垮？
到最后出现故障的服务越来越多，那么整个微服务群都不可用了，这不就是雪崩了。

微服务雪崩的解决方案：
1.1.超时处理
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。当服务A它的业务，依赖于服务D时，它最多等一秒。如果服务D故障以后，这个等待超过了一秒，
它会立即结束这个请求，不再返回给用户一个提示信息。现在假设新的请求速度是每秒钟两个，释放的速度没有进入的速度快，终有一天服务A的资源也有可能会被耗尽？
所以，你设置超时时间也只是起到了一个缓解作用，并没有从根本上解决这个问题。

1.2.舱壁模式
限定每个业务使用的线程数，避免耗尽整个Tomcat的资源，因此也叫线程隔离。服务A可以看成整艘船，然而我们该怎么避免整个Tomcat挂掉呢？
我们就把Tomcat里面的资源，也就是线程，划分成一个一个的独立的线程池。比方说给服务A中的业务1分配10个线程池，业务2分配10个。
那么，现在业务1进来之后，它依赖于服务D。那它最多使用10个线程，访问业务2，它依赖于服务C。那现在服务C出现故障了，那这个业务就会阻塞，占用我们的线程，但是，它最多占用10个。那这个时候它能够使用的Tomcat 资源是不是有限呢？是不是就把这个故障隔离到了10个线程内了？
对此，这个模式也叫线程隔离模式，它其实啊就避免了整个Tomcat资源耗尽的这种情况。
当然这个模式它确实解决了超时处理方案所遗留的问题，只不过资源可能会有一些浪费。比如说，服务C宕机挂了，接下来你还是会尝试区请求这个服务C，明知道它已经挂掉了，你还要尝试访问，还要暂用我10个线程，是不是一种浪费？

1.2.3 熔断降级
由断路器统计业务执行的异常比例，如果超出阈值会熔断该业务，拦截访问该业务的一切请求。在这个业务里面，出现故障的请求和正常的请求之间的一个比例是什么样子的？如果超出了阈值，则会熔断这个业务，什么是熔断，就是拦截访问该业务的一切请求。

1.2.4 流量控制
限制业务访问的QPS，避免服务因流量的突增而故障。
比如说，这里有一个受保护的服务，它能承受的最大QPS是2，也就是每秒钟最多处理两个请求，但是，现在有无数的请求涌过来，那你说他能承受得了吗？那肯定是不行的呀，这不被打成筛子了。而一旦这个服务出现了故障，那依赖于这个服务的其他服务是不是也都跟着会出现故障，那岂不是也会出现雪崩状况，所以，我们一定要尽可能的避免服务因为流量过高而引起故障。
那我们该怎么办呢？这就用到了我们的Sentinel了。
假如真的有无数个请求融入过来，而Sentinel，它可以按照这个服务所能够承受的一个频率去释放请求，这个时候我们的微服务不久能从容应对这些请求了吗？

2."&"与"||"的区别?

2.1."&" 与 "&&" 的区别：
&是按位与运算符，在整数类型（如 int 或 long）之间进行位操作时，它会逐位比较两个操作数，如果两个对应位都是1，则结果位为1，否则为0。
&&是逻辑与运算符，用于布尔表达式。当它用于布尔值时，只有当两个操作数都为 true 时，整个表达式的结果才为 true。关键的不同在于，&& 具有短路特性，这意味着如果左侧表达式为 false，那么右侧的表达式将不会被执行。

2.2."|" 与 "||" 的区别：
|是按位或运算符，同样适用于整数类型，它逐位比较两个操作数，如果任一位为1，则结果位为1。
||是逻辑或运算符，用于布尔表达式。只要两个操作数中有任意一个是 true，整个表达式的结果就是 true。跟 && 类似，|| 运算符也具有短路性质，若左侧表达式为 true，则不会执行右侧表达式。

3.创建线程的方式

创建线程的方式在Java中主要有如下几种：
3.1.继承Thread类
3.2.实现Runnable接口
3.3.使用Callable和Future
3.4.使用Lambda表达式
3.5.使用线程池

3.1.继承 Thread 类：
创建一个新的类，让它继承自 java.lang.Thread 类。重写 Thread 类中的 run() 方法，这个方法包含了线程需要执行的任务。创建该子类的一个实例。调用该实例的 start() 方法来启动线程。
示例代码：

Java
public class MyThread extends Thread {
public void run() {
// 这里是线程需要执行的任务
}

public static void main(String[] args) {
MyThread thread = new MyThread();
thread.start();
}
}

3.2.实现 Runnable 接口：
创建一个类，实现 java.lang.Runnable 接口。重写 Runnable 接口中的 run() 方法。
创建 Thread 类的一个实例，并将实现了 Runnable 接口的对象作为构造函数的参数传递进去。
调用该 Thread 对象的 start() 方法启动线程。
示例代码：

Java
public class MyRunnable implements Runnable {
public void run() {
// 这里是线程需要执行的任务
}

public static void main(String[] args) {
MyRunnable task = new MyRunnable();
Thread thread = new Thread(task);
thread.start();
}
}

3.3.实现 Callable 接口：
创建一个类，实现 java.util.concurrent.Callable 接口，并重写 call() 方法。使用 FutureTask 封装 Callable 实例，因为 Callable 本身不直接产生线程，而是通过 FutureTask 来关联到线程。创建一个 Thread 对象，并将 FutureTask 作为其构造函数的参数。调用 Thread 对象的 start() 方法启动线程。
示例代码：
Java
import java.util.concurrent.Callable;
import java.util.concurrent.FutureTask;

public class MyCallable implements Callable<String> {
public String call() throws Exception {
// 这里是线程需要执行的任务，可以有返回值
return "Callable result";
}

public static void main(String[] args) throws ExecutionException, InterruptedException {
MyCallable task = new MyCallable();
FutureTask<String> futureTask = new FutureTask<>(task);
Thread thread = new Thread(futureTask);
thread.start();
String result = futureTask.get(); // 获取Callable任务的结果
}
}

3.4.使用Lambda表达式
在Java 8及更高版本中，可以使用Lambda表达式来简化线程的创建和执行。通过将逻辑代码封装在Lambda表达式中，你可以更加简洁地创建线程。让我们看看下面的示例：
Thread thread = new Thread(() -> {
// 线程的执行逻辑
System.out.println("线程执行逻辑");
});

// 启动线程
thread.start();

3.5.使用线程池（ExecutorService）：
不直接创建线程，而是通过 java.util.concurrent.ExecutorService 和相关的 ThreadPoolExecutor 类来管理线程池。提交实现了 Runnable 或 Callable 的任务给线程池的 execute() 或 submit() 方法。
示例代码（使用 ExecutorService）：

Java
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ThreadPoolExample {
public static void main(String[] args) {
ExecutorService executor = Executors.newFixedThreadPool(5); // 创建固定大小的线程池
Runnable task = () -> {
// 这里是线程需要执行的任务
};

executor.execute(task); // 执行任务

// 最终记得关闭线程池
executor.shutdown();
}
}

4.线程的生命周期

Java线程的生命周期包括新建、可运行、运行、阻塞、等待和销毁等阶段。
Java线程的生命周期可分为以下几个阶段：

新建（New）：线程对象被创建，但尚未启动。此时线程状态为NEW。

可运行（Runnable）：调用线程的start()方法后，线程进入可运行状态，等待获取CPU执行时间片。线程调度器会从可运行的线程中选择一个来执行。此时线程状态为RUNNABLE。

运行（Running）：获取到CPU执行时间片后，线程进入运行状态，执行线程的run()方法中的代码。此时线程状态为RUNNING。

阻塞（Blocked）：线程可能会由于某种原因而阻塞，比如等待I/O操作或等待获取某个锁。在这种情况下，线程的状态为BLOCKED。

等待（Waiting）：线程调用wait()方法，或者join()方法，或者LockSupport.park()方法，使线程进入等待状态。此时线程状态为WAITING。

超时等待（Timed Waiting）：线程调用带有超时参数的sleep()方法或wait()方法，使线程进入具有超时时间的等待状态。此时线程状态为TIMED_WAITING。

终止（Terminated）：线程执行完run()方法的代码，或者因异常而提前结束。线程的状态变为TERMINATED。

5.简述为什么要使用SpringBoot,使用SpringBoot的优势？

使用SpringBoot的理由:
快速构建项目 SpringBoot提供了各种启动器（starters），使得依赖管理变得简单，可以快速构建项目。内嵌的Tomcat、Jetty或Undertow 无需部署WAR文件，可以直接运行应用程序。
提供自动配置 SpringBoot能够根据项目中添加的依赖自动配置Spring应用。
无需繁琐的XML配置减少或消除了对XML配置文件的需求。

使用SpringBoot的优势：
简化配置 SpringBoot的自动配置和启动器依赖大大简化了Spring应用的配置。
易于管理依赖通过SpringBoot的starter依赖，可以管理所有相关的依赖。
快速开发与部署通过内嵌的HTTP服务器，可以快速运行和部署应用。

6.在SpringBoot项目中，存在一、二级包目录、类三级目录,默认哪些目录会被注解扫描到？

在SpringBoot中使用@ComponentScan()注解进行组件扫描加载类时，默认的扫描范围是启动类([ProjectName]Application)所在包(直接父包)的子包。也即需要被扫描的包下的类要位于启动类所在路径下。

7.@Controller注解与@RestController注解的区别？

@RestController无法返回指定页面，而@Controller可以；前者可以直接返回数据，后者需要@ResponseBody辅助。

8.使用过了微服务的哪些组件？

Spring Cloud Eureka
各个微服务在启动时将自己注册到Eureka Server中，并且各个服务中的Eureka Client又能从注册中心获取各个服务的实例地址清单。
Spring Cloud Ribbon
各个服务相互调用的时候，通过Ribbon来进行客户端的负载均衡，从多个实例中根据一定的策略选择一台进行请求。
Spring Cloud Feign
基于动态代理机制，根据注解和参数拼接URL，选择具体的服务实例发起请求，简化了服务间相互调用的开发工作。
Spring Cloud Hystrix
调用每个服务的时候都是通过线程池中的线程来发起的，不同的服务走不同的线程池，实现了服务的隔离，而且服务不可用时还提供了熔断机制以及支持降低措施。
Spring Cloud Zuul
外部请求统一通过Zuul网关来进入，支持自定义路由规则，自定义过滤规则，可以实现同一的鉴权、限流、认证等功能。

9.在java中，存在几种参数传递的方式？

数组是引用传递。

10.一条SQL变慢了，怎样优化？

10.1 慢查询日志记录慢SQL
如何定位慢SQL呢、我们可以通过慢查询日志来查看慢SQL。默认的情况下呢，MySQL数据库是不开启慢查询日志（slow query log）呢。所以我们需要手动把它打开。
查看下慢查询日志配置，我们可以使用show variables like 'slow_query_log%'命令

10.2 explain分析SQL的执行计划

10.3 profile 分析执行耗时
explain只是看到SQL的预估执行计划，如果要了解SQL真正的执行线程状态及消耗的时间，需要使用profiling

10.4 Optimizer Trace分析详情
profile只能查看到SQL的执行耗时，但是无法看到SQL真正执行的过程信息，即不知道MySQL优化器是如何选择执行计划。这时候，我们可以使用Optimizer Trace，它可以跟踪执行语句的解析优化执行的全过程。我们可以使用set optimizer_trace="enabled=on"打开开关，接着执行要跟踪的SQL，最后执行select * from information_schema.optimizer_trace跟踪。

10.5 确定问题并采用相应的措施
多数慢SQL都跟索引有关，比如不加索引，索引不生效、不合理等，这时候，我们可以优化索引。
我们还可以优化SQL语句，比如一些in元素过多问题（分批），深分页问题（基于上一次数据过滤等），进行时间分段查询。SQl没办法很好优化，可以改用ES的方式，或者数仓。
如果单表数据量过大导致慢查询，则可以考虑分库分表
如果数据库在刷脏页导致慢查询，考虑是否可以优化一些参数，跟DBA讨论优化方案
如果存量数据量太大，考虑是否可以让部分数据归档