Java 面试高频场景题：Full GC、秒杀、幂等性与高可用设计

2. 场景题 2：秒杀场景下，如何防止超卖和库存不一致？

这是电商、零售行业面试高频题，考察'高并发下的数据一致性处理'，核心是'怎么控制库存修改的原子性'。

答题框架（从'防超卖'到'高可用'）：

• 第一步：明确秒杀场景的核心问题

  • 秒杀是'短时间内大量请求抢少量库存'，容易出现：
    • 超卖：比如库存 100，最后卖了 101 件（多线程并发修改库存，没控制好）；
    • 库存遗留：比如用户下单占了库存，但没付款，导致库存被锁死，其他人买不到。

• 第二步：防超卖的 3 种核心方案（按可靠性排序）

  • ① 数据库悲观锁（适合并发量不高的场景）：

    • 原理：用 select ... for update 给库存记录加行锁，确保同一时间只有一个线程能修改库存；
    • 注意：必须用事务，且 for update 要在事务内，否则锁会立即释放；适合并发量 1000 以内的场景，并发太高会导致锁等待，接口超时。

    // 1. 加锁查询库存（for update 锁定行，避免其他线程修改）
    @Select("select stock from product where id = #{productId} for update")
    Integer getStockWithLock(@Param("productId") Long productId);
    
    // 2. 扣减库存（只有拿到锁的线程能执行）
    @Update("update product set stock = stock - 1 where id = #{productId} and stock > 0")
    int decreaseStock(@Param("productId") Long productId);
    
    // 业务逻辑
    @Transactional
    public boolean seckill(Long productId) {
        // 查库存（加锁）
        Integer stock = productMapper.getStockWithLock(productId);
        if (stock == null || stock <= 0) {
            return false; // 库存不足
        }
        // 扣库存
        int rows = productMapper.decreaseStock(productId);
        return rows > 0; // 扣减成功返回 true
    }
    

  • ② 数据库乐观锁（适合并发量中等的场景）：

    • 原理：不加锁，靠版本号或库存判断实现原子性，比如扣库存时加 stock = #{oldStock} 条件，确保库存没被其他线程修改；
    • 优势：无锁等待，并发量比悲观锁高；缺点：重试会增加接口耗时，适合并发量 1000-5000 的场景。

    // 1. 查询库存和版本号
    @Select("select stock, version from product where id = #{productId}")
    ProductStock getStockAndVersion(@Param("productId") Long productId);
    
    // 2. 扣减库存（加版本号条件，确保原子性）
    @Update("update product set stock = stock - 1, version = version + 1 " +
            "where id = #{productId} and stock > 0 and version = #{version}")
    int decreaseStockWithVersion(@Param("productId") Long productId, @Param("version") Integer version);
    
    // 业务逻辑（重试机制，防止一次失败）
    public boolean seckill(Long productId) {
        int retryCount = 3; // 最多重试 3 次
        while (retryCount > 0) {
            ProductStock stock = productMapper.getStockAndVersion(productId);
            if (stock == null || stock.getStock() <= 0) {
                return false;
            }
            // 扣库存
            int rows = productMapper.decreaseStockWithVersion(productId, stock.getVersion());
            if (rows > 0) {
                return true;
            }
            retryCount--;
            Thread.sleep(10); // 重试前等 10ms，减少冲突
        }
        return false; // 重试 3 次都失败，返回 false
    }
    

  • ③ Redis + Lua 脚本（适合高并发场景，秒杀并发 1 万 +）：

    • 原理：Redis 是单线程，Lua 脚本能保证'查库存 + 扣库存'原子执行，避免并发冲突；先在 Redis 预存库存，秒杀时先改 Redis，再异步同步到数据库（最终一致性）；
    • 注意：要处理 Redis 宕机的情况，比如用 Redis 集群 + 持久化（RDB+AOF），避免库存数据丢失；还要防止'黄牛'用脚本抢购，比如加验证码、限流（IP 限流、用户 ID 限流）。

    @Autowired
    private StringRedisTemplate redisTemplate;
    
    // Lua 脚本：查库存 + 扣库存，原子执行
    private static final String SECKILL_LUA = "local stockKey = KEYS[1]\n" +
            "local stock = redis.call('get', stockKey)\n" +
            "if not stock or tonumber(stock) <= 0 then\n" +
            " return 0\n" +
            "end\n" +
            "redis.call('decr', stockKey)\n" +
            "return 1";
    
    public boolean seckillWithRedis(Long productId) {
        String stockKey = "seckill:stock:" + productId;
        // 执行 Lua 脚本
        DefaultRedisScript<Long> script = new DefaultRedisScript<>(SECKILL_LUA, Long.class);
        Long result = redisTemplate.execute(script, Collections.singletonList(stockKey));
        return result != null && result == 1;
    }
    
    // 异步同步 Redis 库存到数据库（用定时任务或消息队列）
    @Scheduled(fixedRate = 5000) // 每 5 秒同步一次
    public void syncStockToDb() {
        Set<String> stockKeys = redisTemplate.keys("seckill:stock:*");
         (String key : stockKeys) {
               Long.parseLong(key.split()[]);
               redisTemplate.opsForValue().get(key);
            
            productMapper.updateStock(productId, Integer.parseInt(redisStock));
        }
    }
    

• 第三步：解决'库存遗留'问题

  • 用'库存过期释放'机制：用户下单后，给库存加个'过期时间'，比如 10 分钟未付款，自动释放库存；
  • 实现方式：Redis 用 expire 给库存锁定记录加过期时间，或用消息队列发送'延迟消息'（比如 RabbitMQ 的延迟队列），10 分钟后检查订单状态，未付款则释放库存。

3. 场景题 3：分布式系统中，如何保证接口的幂等性？

这是微服务面试必考题，考察'分布式数据一致性'，核心是'避免同一请求被重复执行导致副作用'（比如重复扣款、重复创建订单）。

答题框架（先定义，再给方案，分场景选方案）：

• 第一步：明确幂等性的定义

  • '同一接口，相同请求参数，无论调用多少次，结果都一样'——比如用户重复点击'支付'，只会扣一次款；重复调用'创建订单'，只会生成一个订单。

• 第二步：常见的幂等性实现方案（按适用场景分类）

  • ① 基于唯一 ID（适合有唯一标识的请求，比如订单 ID、支付流水号）：

    • 原理：给每个请求分配一个唯一 ID（比如前端生成 UUID，或后端生成雪花 ID），第一次请求时，把 ID 存到数据库/Redis，后续请求先查 ID 是否存在，存在则拒绝执行；
    • 适用场景：支付接口、订单创建接口、退款接口——这些接口必须有唯一标识（如支付流水号、订单号）。

    @Autowired
    private StringRedisTemplate redisTemplate;
    
    // 幂等性处理注解（简化版，实际可自定义注解+AOP）
    public boolean checkIdempotent(String requestId, long expireTime) {
        String key = "idempotent:" + requestId;
        // Redis 的 setIfAbsent 相当于'不存在则设置'，原子操作
        Boolean success = redisTemplate.opsForValue().setIfAbsent(key, "1", expireTime, TimeUnit.SECONDS);
        if (success == null || !success) {
            return false; // 已存在，重复请求
        }
        return true; // 第一次请求，通过
    }
    
    // 支付接口（幂等处理）
    public String pay(String requestId, Long orderId, BigDecimal amount) {
        // 1. 先检查幂等性
        boolean idempotent = checkIdempotent(requestId, 300); // 请求 ID 有效期 5 分钟
        if (!idempotent) {
            return "重复支付请求，已拒绝";
        }
        // 2. 执行支付逻辑（扣减余额、生成支付记录）
        try {
            paymentService.doPay(orderId, amount);
            return "支付成功";
        } catch (Exception e) {
            // 异常时删除幂等 Key，避免正常请求被拦截（可选，根据业务调整）
            redisTemplate.delete("idempotent:" + requestId);
            throw new RuntimeException("支付失败：" + e.getMessage());
        }
    }
    

  • ② 基于状态机（适合有明确状态流转的业务，比如订单状态）：

    • 原理：业务数据有明确状态（比如订单状态：待支付→支付中→已支付→已完成），每次操作前检查当前状态是否允许执行，不允许则拒绝；
    • 示例：订单支付接口，只有'待支付'状态能执行支付，'已支付''已取消'状态都拒绝。

    @Update("update order set status = '已支付', pay_time = now() " +
            "where id = #{orderId} and status = '待支付'")
    int payOrder(@Param("orderId") Long orderId);
    
    public String payOrder(Long orderId, BigDecimal amount) {
        // 执行支付 SQL，只有状态是'待支付'才会更新成功
        int rows = orderMapper.payOrder(orderId);
        if (rows == 0) {
            // 状态不对，可能是重复支付，或订单已取消
            Order order = orderMapper.getOrderById(orderId);
            return "支付失败：订单当前状态为【" + order.getStatus() + "】，不允许支付";
        }
        // 支付成功，后续处理（如通知用户）
        return "支付成功";
    }
    

    • 优势：无需额外存储幂等 ID，依赖业务自身状态，适合订单、工单等有状态流转的业务。

  • ③ 基于 Token（适合前端重复提交，比如表单提交）：

    • 原理：前端先请求'获取 Token 接口'，后端生成 Token 存到 Redis；前端提交表单时携带 Token，后端验证 Token 是否存在，存在则执行并删除 Token；
    • 流程：
      1. 前端：进入支付页面→调用/getToken 接口→获取 Token 并存储；
      2. 前端：提交支付→携带 Token 到/pay 接口；
      3. 后端：验证 Token 存在→执行支付→删除 Token；
    • 适用场景：表单提交（如注册、下单）、按钮重复点击——前端容易出现重复提交的场景。

• 第三步：避坑点

  • 幂等 Key 的有效期：要大于业务处理时间 + 网络延迟，比如支付接口处理需要 1 分钟，有效期设 5 分钟，避免正常重试被拦截；
  • 异常处理：执行失败时，是否删除幂等 Key？比如支付接口因'余额不足'失败，应该删除 Key，允许用户充值后重新请求；如果是'系统异常'，可保留 Key，避免重复执行；
  • 分布式环境：基于数据库的幂等方案，要确保数据库是主从同步的，避免主从延迟导致重复请求通过（比如主库已记录幂等 ID，但从库还没同步，此时读从库会认为是第一次请求）——解决方案是'写主库，读主库'，或用分布式锁（如 Redis 分布式锁）确保幂等检查的原子性。

4. 场景题 4：缓存使用中，如何解决缓存穿透、缓存击穿、缓存雪崩问题？

这是缓存设计高频题，考察'高并发下缓存可靠性'——缓存虽能提高性能，但配置不当会导致'缓存失效，所有请求打数据库'，引发数据库雪崩。

答题框架（先定义问题，再给对应方案）：

• 第一步：明确三个问题的区别

  • 缓存穿透：请求查询'不存在的数据'（如查 id=-1 的用户），缓存和数据库都没有，请求一直打数据库；
  • 缓存击穿：热点数据（如秒杀商品缓存）过期，大量请求同时查这个数据，缓存没命中，全打数据库；
  • 缓存雪崩：大量缓存同时过期，或缓存服务宕机，所有请求打数据库，导致数据库崩溃。

• 第二步：针对性解决方案

  • ① 缓存穿透的解决（2 种核心方案）：

    • 方案 1：缓存空值 / 默认值 —— 对不存在的数据，缓存一个空值（如'null'），并设置短有效期（如 5 分钟），避免同一不存在的 key 反复查数据库；

    public User getUserById(Long userId) {
        String key = "user:" + userId;
        // 1. 先查缓存
        String userJson = redisTemplate.opsForValue().get(key);
        if (userJson != null) {
            if ("null".equals(userJson)) {
                return null; // 缓存空值，直接返回
            }
            return JSON.parseObject(userJson, User.class);
        }
        // 2. 缓存没命中，查数据库
        User user = userMapper.getUserById(userId);
        if (user == null) {
            // 缓存空值，有效期 5 分钟
            redisTemplate.opsForValue().set(key, "null", 5, TimeUnit.MINUTES);
            return null;
        }
        // 3. 数据库有数据，缓存到 Redis，有效期 1 小时
        redisTemplate.opsForValue().set(key, JSON.toJSONString(user), 1, TimeUnit.HOURS);
        return user;
    }
    

    • 方案 2：布隆过滤器（适合数据量大的场景）—— 在缓存前加布隆过滤器，存储'存在的 key'，请求先过过滤器，不存在的 key 直接拦截，不查缓存和数据库；
    • 原理：布隆过滤器用多个哈希函数将 key 映射到二进制数组，判断 key 是否存在（有极小误判率，可通过调整数组大小降低）；
    • 适用场景：用户 ID、商品 ID 等海量数据，比如电商平台有 1 亿商品，用布隆过滤器过滤不存在的商品 ID。

  • ② 缓存击穿的解决（3 种核心方案）：

    • 方案 1：热点数据永不过期 —— 对秒杀商品、首页推荐等热点数据，不设置缓存有效期，通过后台定时任务更新缓存（如每 10 分钟更新一次）；
    • 方案 2：互斥锁（分布式锁） —— 缓存没命中时，只有一个线程能查数据库，其他线程等待，避免大量请求打数据库；

    public Product getSeckillProduct(Long productId) {
        String key = "seckill:product:" + productId;
        // 1. 查缓存
        String productJson = redisTemplate.opsForValue().get(key);
        if (productJson != null) {
            return JSON.parseObject(productJson, Product.class);
        }
        // 2. 缓存没命中，加分布式锁
        String lockKey = "lock:seckill:product:" + productId;
        boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS);
        if (locked) {
            try {
                // 3. 拿到锁，查数据库
                Product product = productMapper.getProductById(productId);
                if (product != null) {
                    // 缓存热点数据，有效期 30 分钟（后续用定时任务更新）
                    redisTemplate.opsForValue().set(key, JSON.toJSONString(product), 30, TimeUnit.MINUTES);
                }
                return product;
            } finally {
                // 4. 释放锁
                redisTemplate.delete(lockKey);
            }
        } else {
            // 5. 没拿到锁，等待 100ms 后重试
            Thread.sleep();
             getSeckillProduct(productId); 
        }
    }
    

  • ③ 缓存雪崩的解决（4 种核心方案）：

    • 方案 1：缓存过期时间加随机值 —— 给不同缓存 key 设置不同的有效期，避免大量缓存同时过期（如默认 1 小时，加 0-30 分钟随机值，有效期变成 1-1.5 小时）；

    // 生成随机过期时间（1 小时~1.5 小时）
    long baseExpire = 3600; // 基础有效期 1 小时
    long randomExpire = new Random().nextInt(1800); // 0~30 分钟随机值
    long totalExpire = baseExpire + randomExpire;
    redisTemplate.opsForValue().set(key, value, totalExpire, TimeUnit.SECONDS);
    

    • 方案 2：缓存集群（高可用） —— 用 Redis 集群（如主从 + 哨兵、Redis Cluster），避免单台缓存服务器宕机导致所有缓存失效；
    • 方案 3：服务熔断 / 降级 —— 用 Sentinel、Hystrix 等组件，当数据库压力过大时，暂时返回缓存旧数据或默认值，避免数据库崩溃；
    • 方案 4：数据库限流 —— 在数据库前加限流组件（如 Nginx 限流、网关限流），限制每秒请求数，避免数据库被压垮。

5. 场景题 5：数据库分库分表后，如何解决跨库跨表查询和事务问题？

这是大数据量场景高频题，考察'分布式数据库设计能力'——当单库数据量超过 1000 万、单表超过 500 万时，需分库分表，但会带来跨库查询和事务难题。

答题框架（先讲分库分表基础，再解决核心问题）：

• 第一步：明确分库分表的常见方式

  • 水平分表（同库分表）：将一张大表按'行'拆分（如用户表按 user_id 取模，拆成 10 张表：user_0~user_9），仍在同一数据库；
  • 水平分库（异库分表）：将大表按'行'拆分到不同数据库（如 user_0user_4 在 db1，user_5user_9 在 db2）；
  • 垂直分表：将一张表按'列'拆分（如用户表拆成 user_base（存基础信息）和 user_ext（存扩展信息））；
  • 垂直分库：将不同业务表拆分到不同数据库（如用户库、订单库、商品库）。

• 第二步：解决跨库跨表查询问题（4 种方案）

  • **① 全局表（适合公共数据）：**将'字典表、配置表'等公共数据，在每个分库中都存一份，避免跨库查询（如每个库都有 region_dict 地区字典表）；
  • **② ER 表（适合关联紧密的表）：**将关联表按同一规则拆分（如订单表和订单项表，都按 order_id 取模拆分），确保关联查询在同一库（如 order_0 和 order_item_0 都在 db1）；
  • **③ 分页查询优化（适合按范围拆分的表）：**若表按时间范围拆分（如订单表按 create_time 拆成每月一张表），跨表分页查询时，先查各表的分页数据，再在应用层合并排序；
    • 示例：查询'2025 年 1-3 月的订单，分页第 2 页（每页 10 条）'——先查 202501_order、202502_order、202503_order 的前 20 条数据，再合并后取 11-20 条；
  • **④ 使用中间件（适合复杂查询）：**用 Sharding-JDBC、MyCat 等分库分表中间件，中间件自动处理跨库查询（如 Sharding-JDBC 通过 SQL 解析，将跨库查询拆成多个单库查询，再合并结果）。

• 第三步：解决跨库事务问题（3 种方案）

  • ① 2PC 分布式事务（强一致性，适合核心业务）：
    • 原理：分'准备阶段'和'提交阶段'——协调者先让所有参与者（分库）执行 SQL 但不提交，确认所有参与者都准备好后，再通知所有参与者提交；若有一个参与者失败，通知所有参与者回滚；
    • 实现：用 Seata 的 AT 模式（自动事务），或 Spring Cloud Alibaba + Seata 集成，无需手动写事务逻辑；
    • 注意：2PC 性能较差，适合并发量不高的核心业务（如支付、转账）。
  • ② TCC 事务（最终一致性，适合自定义逻辑）：
    • 原理：分'Try（尝试）、Confirm（确认）、Cancel（取消）'三步——Try 阶段预留资源（如扣减库存前先冻结库存），Confirm 阶段确认执行（如冻结库存转实际扣减），Cancel 阶段回滚（如取消订单，解冻库存）；
    • 示例：跨库下单（订单库和库存库）：
      1. Try：订单库创建'待确认'订单，库存库冻结商品库存；
      2. Confirm：订单库将订单状态改为'已确认'，库存库将冻结库存改为'已扣减'；
      3. Cancel：订单库删除'待确认'订单，库存库解冻冻结库存；
    • 适用场景：需要自定义事务逻辑的场景，如跨多个业务库的复杂操作。
  • ③ 本地消息表（最终一致性，适合非核心业务）：
    • 原理：在本地库建'消息表'，业务操作和记录消息在同一本地事务中，再通过定时任务将消息同步到消息队列（如 RabbitMQ），其他库消费消息执行对应操作；
    • 示例：跨库同步用户数据（用户库和日志库）：
      1. 用户库：更新用户信息，同时在本地消息表插入'用户更新消息'（同一事务）；
      2. 定时任务：将用户库的消息表数据同步到 RabbitMQ；
      3. 日志库：消费 RabbitMQ 消息，记录用户更新日志；
    • 优势：实现简单，无锁等待，适合非核心业务（如日志同步、数据统计）。

6. 场景题 6：如何设计一个高可用的接口？

这是架构设计高频题，考察'系统稳定性设计能力'——高可用接口需满足'低延迟、高并发、抗故障'，核心是'预防故障'和'故障后快速恢复'。

答题框架（从'设计层面'到'保障层面'）：

• 第一步：接口设计核心原则（3 个基础）

  • **① 无状态设计：**接口不存储用户会话信息（如登录状态），用 Token（如 JWT）或 Redis 存储会话，便于水平扩展（多台服务器部署）；
  • **② 参数校验：**接口入口严格校验参数（如必填项、数据格式、取值范围），用 Hibernate Validator 等工具，避免非法参数导致业务异常；

    @PostMapping("/createOrder")
    public Result createOrder(@Valid @RequestBody OrderDTO orderDTO, BindingResult bindingResult) {
        // 参数校验失败，返回错误信息
        if (bindingResult.hasErrors()) {
            String errorMsg = bindingResult.getFieldErrors().stream()
                    .map(FieldError::getDefaultMessage)
                    .collect(Collectors.joining(","));
            return Result.fail(errorMsg);
        }
        // 业务逻辑
        orderService.createOrder(orderDTO);
        return Result.success();
    }
    
    // OrderDTO 参数校验注解
    @Data
    public class OrderDTO {
        @NotNull(message = "用户 ID 不能为空")
        private Long userId;
        @NotNull(message = "商品 ID 不能为空")
        private Long productId;
        @Min(value = 1, message = "购买数量不能小于 1")
        private Integer count;
        @NotNull(message = "支付金额不能为空")
        @DecimalMin(value = "0.01", message = "支付金额不能小于 0.01")
        private BigDecimal amount;
    }
    

  • **接口版本控制：**用 URL 路径（如/api/v1/createOrder）或请求头（如 X-API-Version: 1）做版本控制，避免接口升级影响旧版本用户（如 V1 和 V2 版本同时在线）。

• 第二步：高可用保障措施（5 个核心）

  • **① 缓存优化：**热点数据用 Redis 缓存，减少数据库查询；接口响应结果用本地缓存（如 Caffeine）缓存，减少重复计算（如首页推荐列表）；
  • **② 异步处理：**非实时业务用异步（如消息队列），避免长耗时操作阻塞接口（如下单后发送短信通知，用 RabbitMQ 异步发送）；
  • **③ 限流：**在网关层或服务层进行限流，防止突发流量冲垮系统；
  • **④ 熔断降级：**当依赖服务不可用时，快速失败并返回兜底数据，保护主流程；
  • **⑤ 监控告警：**建立完善的监控体系，及时发现异常并介入处理。

总结：场景题备考的核心思路

Java 面试场景题的本质，是'考察你将技术知识转化为解决实际问题的能力'。备考时别死记'方案列表'，要做到：

1. **理解底层逻辑：**比如知道'Redis 分布式锁为什么要加过期时间'，而不是只记'要加过期时间'；
2. **结合业务场景：**比如'秒杀用 Redis+Lua''普通订单用数据库乐观锁'，根据业务并发量和一致性要求选方案；
3. **积累实战案例：**哪怕没实际做过，也可以通过'看技术文章 + 模拟场景'积累案例，比如'假设我做秒杀系统，会先压测，再用 Redis 缓存库存，最后加限流'——有逻辑的'模拟案例'比空泛的方案更有说服力。

最后，面试时遇到不会的场景题，别慌！可以先跟面试官'确认场景细节'（如'这个接口的并发量大概是多少？对数据一致性要求高吗？'），一方面给自己思考时间，另一方面体现你'先分析再解决'的思维——很多时候，面试官更看重你的思维过程，而非完美答案。

• 方案 3：热点数据预热 —— 秒杀活动开始前，提前将商品数据加载到缓存（如用脚本批量导入 Redis），避免活动开始后缓存未命中。