面试官：你负责项目的时候遇到了哪些比较棘手的问题?怎么解决的

面试官心理剖析

面试官在询问程序员关于项目中遇到的棘手问题及其解决方案时，其实是在进行多方面的考察，这背后蕴含着一些特定的心理活动和考量因素。

1. 探查你是小白或者只是个 CRUD 程序员

如果你回答我在项目中没有怎么遇到比较棘手的问题，那么面试官会觉得你要么是小白什么都不会，要么还是只个 CRUD 程序员没有负责具体的项目，对项目了解也不够深入也没有负责什么项目

2. 评估问题解决能力和判断技术实力

面试官首先关心的是应聘者的问题解决能力。他们想知道应聘者是如何面对挑战、分析问题的，以及是否具备足够的逻辑思维和解决问题的能力。通过询问具体的解决方案，面试官能够了解应聘者的技术实力和知识储备。他们会关注应聘者是否使用了恰当的技术手段、是否熟悉相关的工具和框架，以及是否能够有效地将理论知识应用于实际问题中。

回答思路

具体回答这个问题可以从这几个方面入手：

1. 设计模式

  工厂模式，策略模式，责任链模式等

2. 线上 bug

   CUP彪高，内存泄漏，线程死锁等

3. 调优

  慢sql，慢接口，缓存方案等

4. 组件封装

  接口幂等性，分布式锁，分布式事务，支付问题等

回答要从以下几个方面切入：

1. 什么背景（技术问题）

2. 过程（解决问题的过程）

3. 最终落地的方案

以上是面试这个问题的技术入手和回答问题的切入方向，面试其实只需要回答其中一个问题即可

举例

以单例模式为例

背景（技术问题）：

在一个大型的企业级应用中，经常需要操作一些关键配置文件，比如数据库连接配置、系统参数配置等。这些配置文件通常在应用启动时被加载，并在整个应用的生命周期中保持不变。为了避免多个组件同时操作同一个配置文件导致的数据不一致和冲突，需要确保在任何时候，只有一个组件能够操作这个文件。

过程（解决问题的过程）：

为了实现这一目标，可以使用单例模式来创建一个专门负责文件操作的类。这个类会负责文件的读取、写入和锁定等操作，并确保在任何时刻，只有一个实例存在。

最终落地的方案：

public class FileOperator {      
	// 私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载      
	private static FileOperator instance = null;            
	// 私有构造方法，防止被实例化      
	private FileOperator() {     
	}        
	
	// 静态工程方法，创建实例      
	public static synchronized FileOperator getInstance() {
	          if (instance == null) {
	               instance = new FileOperator();
	           }
	           return instance;
	}        
	// 文件读取方法      
	public String readFile(String filePath) {          
				// 读取文件的逻辑
	          return "读取到的文件内容";      
	} 
       // 文件写入方法
    public void writeFile(String filePath, String content) {
        // 写入文件的逻辑，包括文件锁定和解锁操作
    }
}

在这个例子中，FileOperator 类负责文件的读取和写入操作。通过单例模式，确保了整个应用中只有一个 FileOperator 的实例存在。这样，无论应用中的哪个组件需要操作文件，都会通过这个唯一的实例来进行，从而避免了冲突。在 getInstance 方法中，使用 synchronized 关键字来确保线程安全。当第一个线程调用 getInstance 方法时，它会创建 FileOperator 的实例。当其他线程再次调用该方法时，由于实例已经存在，它们将直接返回这个已经创建的实例。在 writeFile 方法中，可以实现文件锁定和解锁的逻辑，以确保在写入文件时，其他线程或进程无法同时修改该文件。这样可以保证文件内容的一致性和完整性。通过使用单例模式的 FileOperator 类，可以有效地管理文件操作，确保整个应用中文件操作的一致性和安全性。

以 CUP 过高为例

背景（技术问题）

在我负责的一个实时数据分析项目中，我们遇到了 CPU 使用率异常高的问题。项目需要对海量数据进行实时处理和分析，并生成相应的报表。起初，系统运行正常，但随着数据量的增长和业务的复杂化，CPU 使用率逐渐攀升，最终导致了系统响应变慢甚至崩溃。通过对系统的监控和分析，我们发现有几个关键模块在处理数据时存在性能瓶颈，导致了 CPU 资源的过度消耗。这些模块涉及到大量的数据处理和计算，包括数据排序、聚合以及复杂的业务逻辑处理。

过程（解决问题的过程）

为了解决 CPU 使用率过高的问题，我们采取了一系列调优措施：首先，我们对存在性能瓶颈的模块进行了代码审查，寻找可能的优化点。我们重点关注了循环、递归以及不必要的对象创建等可能导致 CPU 资源过度消耗的代码段。其次，我们利用性能分析工具对系统进行了全面的性能剖析。通过收集和分析运行时数据，我们确定了几个关键的热点函数和代码段，这些代码在执行时占用了大量的 CPU 时间。接下来，我们针对这些热点函数和代码段进行了优化。我们采用了更高效的数据结构和算法，减少了不必要的计算和内存分配。同时，我们也对业务逻辑进行了简化，避免了不必要的复杂操作。除了代码级别的优化，我们还对系统架构进行了调整。我们引入了缓存机制，减少了对数据库的频繁访问；同时，我们也对系统进行了分布式部署，将计算任务分散到多个节点上，提高了系统的并行处理能力。

最终落地的方案

经过一系列的调优措施，我们成功降低了系统的 CPU 使用率，提高了系统的性能和稳定性。具体的落地方案包括：

• 对关键模块进行了代码优化，减少了不必要的计算和内存分配；

• 引入了更高效的数据结构和算法，提高了数据处理的速度和效率；

• 简化了业务逻辑，避免了不必要的复杂操作；

• 引入了缓存机制，减少了数据库的访问次数；

• 进行了系统架构的调整，实现了分布式部署和负载均衡。

这些方案的实施使得系统的 CPU 使用率得到了有效控制，系统性能得到了显著提升。同时，我们也建立了一套完善的性能监控和预警机制，能够及时发现并解决潜在的性能问题，确保系统的稳定运行。通过这次调优经历，我深刻体会到了性能调优在项目开发中的重要性。在未来的工作中，我将更加注重代码质量和性能优化，努力提升系统的性能和用户体验。

更多细节技术分享至： https://www.besthub.tech/archives/1709822360617

以慢 sql 为例

背景（技术问题）

在我负责的一个电商项目中，随着业务的发展和用户量的增长，数据库查询性能逐渐下降，特别是在高峰期，部分关键业务功能的响应时间明显延长，严重影响了用户体验。通过监控和日志分析，我们发现某些 SQL 查询执行特别慢，成为了性能瓶颈。这些慢 SQL 查询主要涉及复杂的关联查询、大数据量的筛选以及缺乏有效索引的字段。由于数据库表结构设计不合理、索引使用不当以及查询逻辑复杂等原因，导致查询效率低下，CPU 和 IO 资源消耗过高。

过程（解决问题的过程）

为了解决这些慢 SQL 问题，我们采取了一系列调优措施：首先，我们对慢 SQL 查询进行了定位和分析。利用数据库的性能监控工具，我们找出了执行时间最长、资源消耗最多的 SQL 语句。然后，对这些 SQL 语句进行了详细的解释分析，查看了查询计划、扫描行数、索引使用情况等信息，确定了性能瓶颈所在。接下来，我们针对每个慢 SQL 查询进行了优化。对于复杂的关联查询，我们尝试简化查询逻辑，减少不必要的关联操作；对于大数据量的筛选，我们优化了筛选条件，减少了返回结果集的大小；对于缺乏有效索引的字段，我们添加了合适的索引，提高了查询速度。在优化过程中，我们还对数据库表结构进行了调整。根据业务需求和查询特点，我们重新设计了部分表结构，提高了数据的存储和查询效率。同时，我们也对索引进行了重建和维护，确保索引的有效性和准确性。除了上述措施外，我们还对数据库进行了整体性能调优。包括调整数据库参数、优化缓存策略、增加硬件资源等，以提高数据库的整体性能。

最终落地的方案

经过一系列的调优措施，我们成功解决了慢 SQL 查询问题，提高了数据库查询性能。具体的落地方案包括：

• • 优化了多个关键业务的 SQL 查询逻辑，减少了不必要的关联和筛选操作；

• • 添加了多个缺失的索引，提高了查询速度和效率；

• • 调整了部分表结构，使其更符合业务需求和查询特点；

• • 对数据库进行了整体性能调优，提高了稳定性和响应速度。

在实施这些方案后，我们进行了性能测试和验证。通过对比优化前后的数据，我们发现关键业务的响应时间明显缩短，数据库资源消耗也大大降低。同时，用户体验也得到了显著提升，满意度明显提高。这次慢 SQL 调优的经历让我深刻体会到了性能调优在项目开发中的重要性。在未来的工作中，我将更加注重代码质量和数据库性能的优化，努力提升系统的性能和用户体验。

以接口幂等性为例

背景（技术问题）

在我负责的一个分布式系统中，我们封装了多个组件接口以实现业务逻辑的解耦和复用。然而，随着系统规模的扩大和调用量的增长，我们逐渐发现部分接口在并发调用时出现了重复处理或数据不一致的问题。这些接口往往涉及到一些重要的业务操作，如订单支付、库存扣减等，一旦处理不当，将会导致严重的业务损失。经过分析，我们发现这些问题主要是由于接口调用不具备幂等性所导致的。幂等性指的是多次执行同一操作与单次执行该操作的结果相同。在我们的系统中，由于网络抖动、超时重试等原因，导致同一个请求被多次发送到后端接口，进而引发了重复处理和数据不一致的问题。

过程（解决问题的过程）

为了解决接口幂等性的问题，我们采取了以下步骤：首先，我们重新梳理了现有的接口调用流程，明确了哪些接口需要保证幂等性。对于需要保证幂等性的接口，我们分析了其业务逻辑和数据处理过程，确定了可能导致幂等性问题的原因。接下来，我们针对每个需要保证幂等性的接口设计了相应的解决方案。一种常见的做法是在接口调用时传入一个唯一的请求 ID 或令牌（Token），并在后端接口中对该 ID 或令牌进行校验。如果接口已经处理过具有相同 ID 或令牌的请求，则直接返回处理结果，不再重复执行业务逻辑。为了实现这一方案，我们需要在后端接口中增加对请求 ID 或令牌的存储和校验逻辑。考虑到系统的分布式特性，我们使用了 Redis 等内存数据库来存储这些信息，以确保在高并发场景下能够快速地进行校验。此外，我们还对接口的调用方进行了规范，要求其在发送请求时务必携带唯一的请求 ID 或令牌，并在必要时进行重试。同时，我们也对接口的错误处理和异常机制进行了完善，以确保在出现问题时能够及时发现和处理。

最终落地的方案

经过上述步骤的实施和优化，我们成功解决了接口幂等性的问题。具体的落地方案包括：

• 对于需要保证幂等性的接口，我们在调用时传入唯一的请求 ID 或令牌；

• 在后端接口中增加对请求 ID 或令牌的存储和校验逻辑，确保不会重复处理相同的请求；

• 使用 Redis 等内存数据库来存储请求 ID 或令牌信息，提高校验速度；

• 规范接口的调用方行为，要求携带唯一的请求 ID 或令牌，并进行必要的重试；

• 完善接口的错误处理和异常机制，确保问题的及时发现和处理。

通过这些措施的实施，我们成功地提高了系统的稳定性和可靠性，降低了因接口幂等性问题导致的业务损失。同时，这也为我们后续的项目开发和维护提供了宝贵的经验和参考。