当前位置：首页 > article >正文

【面试题】技术场景 4、负责项目时遇到的棘手问题及解决方法

article 2025/1/13 17:19:46

工作经验一年以上程序员必问问题

面试题概述

问题为在负责项目时遇到的棘手问题及解决方法，主要考察开发经验与技术水平，回答不佳会影响面试印象。
提供四个回答方向，准备其中一个方向即可。

1、设计模式应用方向

以登录为例，未用设计模式时登录逻辑在一个业务类中，需求变更（如登录方式增减或更换）需频繁修改业务层代码。
采用工厂设计模式和策略模式后，解决了频繁修改业务层代码的问题，具体实现可参考相关案例，其他设计模式介绍方式类似。

2、线上 bug 方向

项目上线后可能出现测试环境未暴露的问题，如运行一段时间后 CPU 飙高、内存泄露、线程死锁等，线上调试困难。
介绍时需按问题、解决过程、最终解决方案的逻辑进行，可参考 DVM 和多线程课程案例。

3、调优方向

调优时最好给出指标数据，如接口调优前后的访问耗时。
重点讲述调优中间过程，可涉及 SQL 优化（加索引）、添加缓存、采用集群或高可用方案等。

4、组件封装方向

分布式锁和接口幂等可封装为小型工具或组件供多项目使用，支付和事务可封装为通用服务，但难度较高且需考虑高可用和通用性。
有经验可详细讲述，无经验可参考网上文章，实在想不到可从其他三个方向入手。

总结强调

此面试题高频出现，需提前准备，选择一个方向深入准备能体现技术水平。

具体问题

设计模式应用案例

在一个电商项目的用户登录功能开发中，最初的设计非常简单直接。登录逻辑全部集中在一个业务类 UserLoginService 中，代码如下：

public class UserLoginService {
    public boolean login(String username, String password) {
        // 直接在该方法中进行数据库查询验证
        if ("admin".equals(username) && "123456".equals(password)) {
            return true;
        }
        return false;
    }
}

随着业务发展，需要支持多种登录方式，如手机号验证码登录、第三方平台登录（微信、支付宝）等。每次增加新的登录方式，都需要在 login 方法中添加大量的条件判断逻辑，导致代码越来越臃肿，维护成本急剧上升。例如添加手机号验证码登录：

public class UserLoginService {
    public boolean login(String identifier, String credential) {
        if (identifier.matches("^1[3 - 9]\\d{9}$")) {
            // 手机号验证码登录逻辑，查询数据库验证验证码
            if ("validCode".equals(credential)) {
                return true;
            }
        } else if ("admin".equals(identifier) && "123456".equals(credential)) {
            // 用户名密码登录逻辑
            return true;
        }
        return false;
    }
}

为解决这个问题，引入了工厂设计模式与策略模式。首先定义一个登录策略接口 LoginStrategy：

public interface LoginStrategy {
    boolean login(String identifier, String credential);
}

然后分别实现用户名密码登录策略类 UsernamePasswordLoginStrategy 和手机号验证码登录策略类 PhoneCodeLoginStrategy：

public class UsernamePasswordLoginStrategy implements LoginStrategy {
    @Override
    public boolean login(String username, String password) {
        // 实际数据库查询验证逻辑
        if ("admin".equals(username) && "123456".equals(password)) {
            return true;
        }
        return false;
    }
}

public class PhoneCodeLoginStrategy implements LoginStrategy {
    @Override
    public boolean login(String phone, String code) {
        // 实际数据库查询验证逻辑
        if ("13800138000".equals(phone) && "validCode".equals(code)) {
            return true;
        }
        return false;
    }
}

接着创建一个登录策略工厂类 LoginStrategyFactory：

public class LoginStrategyFactory {
    public static LoginStrategy getLoginStrategy(String loginType) {
        if ("usernamePassword".equals(loginType)) {
            return new UsernamePasswordLoginStrategy();
        } else if ("phoneCode".equals(loginType)) {
            return new PhoneCodeLoginStrategy();
        }
        return null;
    }
}

最后，修改业务类 UserLoginService，通过工厂获取相应的登录策略：

public class UserLoginService {
    public boolean login(String loginType, String identifier, String credential) {
        LoginStrategy strategy = LoginStrategyFactory.getLoginStrategy(loginType);
        if (strategy!= null) {
            return strategy.login(identifier, credential);
        }
        return false;
    }
}

通过这种方式，当需要添加新的登录方式时，只需要创建新的策略类并在工厂类中添加相应的获取逻辑，无需修改业务层的核心代码，大大提高了代码的扩展性和维护性。

线上 bug 处理案例

在一个大型的在线教育平台项目上线一段时间后，运维人员反馈系统出现 CPU 使用率持续飙高的情况，导致部分课程直播卡顿，严重影响用户体验。由于线上环境复杂，难以在测试环境复现相同问题，增加了调试难度。

首先，利用 jstack 命令获取当前 Java 进程的线程堆栈信息，通过分析堆栈信息，发现有一个线程一直在执行某个方法 calculateCourseScore，该方法用于计算课程的综合得分，代码如下：

public class CourseScoreCalculator {
    public double calculateCourseScore(List<StudentAnswer> answers) {
        double totalScore = 0;
        for (StudentAnswer answer : answers) {
            // 复杂的计算逻辑，包含多层嵌套循环
            for (int i = 0; i < answer.getOptions().size(); i++) {
                for (int j = 0; j < answer.getOptions().get(i).getSubOptions().size(); j++) {
                    totalScore += answer.getOptions().get(i).getSubOptions().get(j).getScore();
                }
            }
        }
        return totalScore;
    }
}

从代码逻辑上看，多层嵌套循环导致计算量过大，在高并发情况下容易使 CPU 使用率飙升。针对这个问题，对计算逻辑进行了优化。通过减少不必要的循环嵌套，将部分重复计算的逻辑提取出来，优化后的代码如下：

public class CourseScoreCalculator {
    public double calculateCourseScore(List<StudentAnswer> answers) {
        double totalScore = 0;
        for (StudentAnswer answer : answers) {
            List<Option> options = answer.getOptions();
            for (Option option : options) {
                List<SubOption> subOptions = option.getSubOptions();
                for (SubOption subOption : subOptions) {
                    totalScore += subOption.getScore();
                }
            }
        }
        return totalScore;
    }
}

同时，监控系统资源，发现数据库查询操作也占用了较多资源。通过对数据库查询语句进行分析，发现部分查询没有使用合适的索引。例如，在查询学生课程学习记录时，原 SQL 语句为：

SELECT * FROM student_course_record WHERE student_id = 12345;

表 student_course_record 数据量较大，而 student_id 字段没有添加索引，导致查询效率低下。为 student_id 字段添加索引：

CREATE INDEX idx_student_id ON student_course_record(student_id);

经过这些优化措施，再次监控系统，CPU 使用率恢复到正常水平，线上直播卡顿问题得到解决。

系统调优案例

在一个电商订单系统中，有一个查询订单详情的接口 getOrderDetail，调优前该接口的平均响应时间为 2 秒，严重影响用户体验。为了提升系统性能，对该接口进行了优化。

首先，对接口涉及的 SQL 查询语句进行分析。原 SQL 语句为：

SELECT * FROM orders 
JOIN order_items ON orders.order_id = order_items.order_id 
JOIN products ON order_items.product_id = products.product_id 
WHERE orders.order_id = 12345;

通过 EXPLAIN 关键字分析查询执行计划，发现 JOIN 操作效率较低，因为相关表没有合适的索引。为 orders 表的 order_id 字段、order_items 表的 order_id 和 product_id 字段、products 表的 product_id 字段添加索引：

CREATE INDEX idx_order_id_orders ON orders(order_id);
CREATE INDEX idx_order_id_order_items ON order_items(order_id);
CREATE INDEX idx_product_id_order_items ON order_items(product_id);
CREATE INDEX idx_product_id_products ON products(product_id);

经过索引优化后，SQL 查询效率得到显著提升。同时，考虑到订单数据相对稳定，添加缓存机制。使用 Redis 作为缓存，在查询订单详情时，首先从 Redis 中查询是否有缓存数据，如果有则直接返回，避免了数据库查询。代码实现如下：

public OrderDetail getOrderDetail(long orderId) {
    OrderDetail orderDetail = (OrderDetail) redisTemplate.opsForValue().get("order:" + orderId);
    if (orderDetail!= null) {
        return orderDetail;
    }
    // 如果缓存中没有，从数据库查询
    orderDetail = orderDao.getOrderDetail(orderId);
    if (orderDetail!= null) {
        redisTemplate.opsForValue().set("order:" + orderId, orderDetail);
    }
    return orderDetail;
}

经过上述优化，该接口的平均响应时间从 2 秒缩短到了 500ms，系统性能得到了大幅提升。

组件封装案例

分布式锁封装
在一个分布式电商库存扣减系统中，为了保证库存扣减的原子性，避免超卖现象，需要使用分布式锁。封装了一个简单的分布式锁工具类 DistributedLockUtil，使用 Redis 实现分布式锁。代码如下：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;

@Component
public class DistributedLockUtil {
    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    public boolean tryLock(String lockKey, String requestId, int expireTime) {
        return redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, expireTime, TimeUnit.SECONDS);
    }

    public void unlock(String lockKey, String requestId) {
        if (requestId.equals(redisTemplate.opsForValue().get(lockKey))) {
            redisTemplate.delete(lockKey);
        }
    }
}

在库存扣减业务代码中使用该分布式锁：

public class StockService {
    @Autowired
    private DistributedLockUtil distributedLockUtil;

    public boolean deductStock(long productId, int quantity) {
        String lockKey = "stock:" + productId;
        String requestId = UUID.randomUUID().toString();
        if (distributedLockUtil.tryLock(lockKey, requestId, 10)) {
            try {
                // 检查库存并扣减
                int stock = stockDao.getStock(productId);
                if (stock >= quantity) {
                    stockDao.deductStock(productId, quantity);
                    return true;
                }
            } finally {
                distributedLockUtil.unlock(lockKey, requestId);
            }
        }
        return false;
    }
}

这个分布式锁工具类可以在多个电商相关项目中复用，保证了分布式环境下关键业务的一致性。

支付通用服务封装
在一个综合性电商平台项目中，涉及多种支付方式，如微信支付、支付宝支付、银行卡支付等。为了提高代码的复用性和系统的可维护性，封装了一个支付通用服务 PaymentService。

首先定义一个支付接口 PaymentProcessor：

public interface PaymentProcessor {
    String processPayment(PaymentRequest request);
}

然后分别实现微信支付处理器 WeChatPaymentProcessor、支付宝支付处理器 AlipayPaymentProcessor 和银行卡支付处理器 BankCardPaymentProcessor：

public class WeChatPaymentProcessor implements PaymentProcessor {
    @Override
    public String processPayment(PaymentRequest request) {
        // 调用微信支付 API 进行支付处理
        // 返回支付结果
        return "微信支付成功";
    }
}

public class AlipayPaymentProcessor implements PaymentProcessor {
    @Override
    public String processPayment(PaymentRequest request) {
        // 调用支付宝支付 API 进行支付处理
        // 返回支付结果
        return "支付宝支付成功";
    }
}

public class BankCardPaymentProcessor implements PaymentProcessor {
    @Override
    public String processPayment(PaymentRequest request) {
        // 调用银行卡支付 API 进行支付处理
        // 返回支付结果
        return "银行卡支付成功";
    }
}

接着创建支付服务类 PaymentService，通过策略模式选择具体的支付处理器：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.HashMap;
import java.util.Map;

@Service
public class PaymentService {
    private Map<String, PaymentProcessor> paymentProcessorMap = new HashMap<>();

    @Autowired
    public PaymentService(WeChatPaymentProcessor weChatPaymentProcessor,
                          AlipayPaymentProcessor alipayPaymentProcessor,
                          BankCardPaymentProcessor bankCardPaymentProcessor) {
        paymentProcessorMap.put("wechat", weChatPaymentProcessor);
        paymentProcessorMap.put("alipay", alipayPaymentProcessor);
        paymentProcessorMap.put("bankCard", bankCardPaymentProcessor);
    }

    public String processPayment(PaymentRequest request) {
        String paymentType = request.getPaymentType();
        PaymentProcessor processor = paymentProcessorMap.get(paymentType);
        if (processor!= null) {
            return processor.processPayment(request);
        }
        return "不支持的支付方式";
    }
}

在订单支付业务中使用该支付服务：

public class OrderService {
    @Autowired
    private PaymentService paymentService;

    public String payOrder(Order order) {
        PaymentRequest request = new PaymentRequest();
        request.setPaymentType(order.getPaymentType());
        request.setAmount(order.getTotalAmount());
        return paymentService.processPayment(request);
    }
}

通过这种方式，将支付相关的复杂逻辑封装在 PaymentService 中，其他业务模块只需调用该服务即可，提高了系统的通用性和可维护性，同时也方便扩展新的支付方式。

总结

设计模式应用

主要内容：电商项目用户登录功能，从初始逻辑集中导致维护困难，到引入工厂与策略模式解决问题。
核心概念：工厂设计模式用于创建对象，策略模式将算法逻辑封装。
关键知识点：理解两种设计模式作用，明白如何结合使用提高代码扩展性与维护性。

总结：

设计模式可优化代码结构，解决业务变更时代码频繁修改问题。
工厂模式负责对象创建，策略模式处理不同业务逻辑实现，二者结合使代码更灵活。

线上 bug 处理

主要内容：在线教育平台上线后 CPU 飙高，通过分析线程堆栈和 SQL 语句定位并解决问题。
核心概念：利用工具获取线程堆栈信息辅助定位问题，关注数据库索引对查询性能影响。
关键知识点：掌握获取和分析线程堆栈方法，了解索引优化 SQL 查询原理。

总结：

线上 bug 因环境复杂难调试，需借助工具精准定位。
优化代码逻辑和数据库查询，可有效解决性能问题。

系统调优

主要内容：电商订单系统查询订单详情接口，从 2 秒响应优化到 500ms，通过 SQL 优化和缓存实现。
核心概念：使用 EXPLAIN 分析查询执行计划，运用缓存减少数据库查询压力。
关键知识点：学会分析查询执行计划，掌握缓存机制及应用场景。

总结：

系统调优需关注数据库查询和缓存策略，以提升接口响应速度。
索引优化可提高 SQL 查询效率，缓存能快速返回常用数据。

组件封装

分布式锁封装
- 主要内容：电商库存扣减系统使用分布式锁保证原子性，封装基于 Redis 的分布式锁工具。
- 核心概念：分布式锁确保分布式环境下操作一致性，Redis 提供实现方式。
- 关键知识点：理解分布式锁原理，掌握基于 Redis 实现分布式锁方法。
总结：
- 分布式锁用于解决分布式场景下数据一致性问题。
- Redis 的 setIfAbsent 等操作可实现分布式锁基本功能。
支付通用服务封装
- 主要内容：电商平台多种支付方式，通过封装支付通用服务提高复用性与可维护性。
- 核心概念：利用策略模式实现不同支付方式处理，封装复杂支付逻辑。
- 关键知识点：理解策略模式应用，学会封装通用服务。
总结：
- 策略模式可根据不同条件选择不同支付处理器。
- 封装通用服务能提升代码复用，便于维护和扩展新支付方式。