川川和洋洋实战项目避坑指南：5个致命Bug让面试直接挂

上周陪一个做Java后端的朋友面大厂，他简历上写着“负责高并发订单系统”，结果面试官问一句“你的分布式锁是怎么保证互斥性的？”，他愣了三秒，说“用了Redis，设了过期时间”。面试官直接摇头。这就是典型的面试被问原理答不上来，平时写代码能跑就行，一深挖就露馅。

很多开发者都有这个毛病：手里攥着几个实战项目，代码写得飞起，但底层逻辑一团浆糊。特别是像“川川和洋洋”这种典型的业务系统场景（比如用户权限、数据同步、库存扣减），坑多且隐蔽。今天不整虚的，直接拆解五个我在实际项目中踩过的深坑，从现象到源码级原因，再到修复方案，全是干货。

坑一：并发下的“超卖”幻象

现象：大促期间，库存明明只剩1件，结果卖出去了10件。监控没报错，数据库里库存字段是负数，客服电话被打爆。

根本原因：这不是代码逻辑错了，是并发竞态条件。传统写法 select * from stock where id=1; update stock set count=count-1 where id=1; 在单线程下没问题，但在高并发下，两个线程同时读到 count=1，都判断大于0，都执行减1。数据库没有加行级锁，或者锁粒度不对，导致数据不一致。

错误写法：

// 错误：非原子操作，存在并发窗口
public void decreaseStock(Long itemId) {Stock stock = stockMapper.selectById(itemId);if (stock.getCount() > 0) {stock.setCount(stock.getCount() - 1);stockMapper.updateById(stock); // 这里两个线程可能同时执行，覆盖对方数据}
}

正确写法：利用数据库的乐观锁或原子更新。MySQL的 UPDATE 语句本身是原子的，只要带上版本号或状态条件，就能避免竞态。

// 正确：利用SQL原子性，条件更新
public void decreaseStock(Long itemId) {// 利用 where count > 0 保证库存充足，update 是原子操作int rows = stockMapper.decreaseCount(itemId);if (rows == 0) {throw new BusinessException("库存不足");}
}// Mapper XML
// <update id="decreaseCount">
//   UPDATE stock SET count = count - 1 WHERE item_id = #{itemId} AND count > 0
// </update>

复现与修复：在JMeter里压测100线程同时买1件库存为1的商品。错误写法会出现超卖，正确写法只有1个请求返回成功，其余99个抛出异常。修复关键在于把判断和更新合并成一条SQL，让数据库引擎来处理并发，而不是在应用层。

坑二：缓存穿透与雪崩的“隐形杀手”

现象：系统CPU瞬间飙高到90%，接口响应时间从10ms变成5s。日志里全是“DB Connection Timeout”。检查代码，发现有个接口频繁查询不存在的用户ID（比如恶意爬虫传的随机ID）。

根本原因： 缓存穿透。请求的key在Redis里没有，每次都要去查MySQL。恶意攻击者故意构造大量无效ID，绕过缓存，直接打垮数据库。如果是大量热点Key同时过期，还会引发缓存雪崩。

错误写法：

// 错误：未处理缓存未命中情况，直接查库
public User getUserById(Long id) {String key = "user:" + id;User user = redisTemplate.opsForValue().get(key);if (user == null) {// 问题：如果DB里也没有，下次请求还会进来查DBuser = userMapper.selectById(id);if (user != null) {redisTemplate.opsForValue().set(key, user, 30, TimeUnit.MINUTES);}return user;}return user;
}

正确写法：引入空值缓存和布隆过滤器。对于肯定不存在的数据，在Redis里存一个标记（如"null"），设置短过期时间。同时，在入口层用布隆过滤器拦截大部分无效请求。

// 正确：空值缓存 + 布隆过滤器
public User getUserById(Long id) {// 1. 布隆过滤器预判（假设已初始化）if (!bloomFilter.mightContain(id)) {return null; // 直接返回，不查Redis和DB}String key = "user:" + id;User user = redisTemplate.opsForValue().get(key);if (user != null) {if ("null".equals(user.getJsonStr())) {return null; // 命中空值缓存}return user;}user = userMapper.selectById(id);if (user == null) {// 2. 缓存空值，防止穿透，设置较短过期时间防止内存泄漏redisTemplate.opsForValue().set(key, "null", 2, TimeUnit.MINUTES);} else {redisTemplate.opsForValue().set(key, user, 30, TimeUnit.MINUTES);}return user;
}

复现与修复：用脚本随机生成10万个不存在的ID发起请求。错误写法下，MySQL QPS瞬间激增，CPU打满。正确写法下，布隆过滤器拦截99%的请求，剩余1%命中空值缓存，数据库压力几乎为零。参考Redis开发者文档，SETEX 命令设置过期时间是标准做法，切勿手动计算过期时间戳，容易因时钟漂移导致失效。

坑三：事务回滚失败的“假成功”

现象：用户下单扣款成功，但积分没加。用户投诉，查日志发现订单表有记录，积分表无记录。代码里明明用了 @Transactional，为什么没回滚？

根本原因： 异常被吞掉或事务传播属性错误。最常见的情况是：在Service层抛出了RuntimeException，但被外层catch住了，没有重新抛出。Spring的事务拦截器捕获不到异常，默认提交事务。或者，在同一个事务中，某个方法抛出的是受检异常（Checked Exception），Spring默认不回滚受检异常。

错误写法：

// 错误：捕获异常但未重新抛出，导致事务提交
@Transactional
public void placeOrder(Order order) {try {orderService.save(order);userService.addPoints(order.getUserId());} catch (Exception e) {log.error("下单失败", e);// 致命错误：这里吞掉了异常，Spring认为方法正常执行完，提交事务}
}

正确写法：确保异常向上抛出，或者手动回滚。同时，指定 rollbackFor = Exception.class，确保所有异常都触发回滚。

// 正确：重新抛出异常，并指定回滚范围
@Transactional(rollbackFor = Exception.class)
public void placeOrder(Order order) {try {orderService.save(order);userService.addPoints(order.getUserId());} catch (Exception e) {log.error("下单失败", e);// 必须重新抛出，或者调用 TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();throw new RuntimeException("下单处理异常", e);}
}

复现与修复：模拟积分服务抛出异常。错误写法下，订单和积分都保存成功（如果积分服务内部没回滚）或只有订单成功（取决于具体实现）。正确写法下，订单和积分都不保存，数据一致性得到保证。切记，不要依赖默认行为，显式声明 rollbackFor 是最佳实践。

坑四：时间处理的“时区陷阱”

现象：国内用户看到订单时间是下午2点，美国用户看到是凌晨4点。导出Excel后，时间乱码或偏移8小时。

根本原因： 时区处理不当。JVM默认使用服务器时区，而数据库存储的可能是UTC时间，前端展示又用了本地时区。SimpleDateFormat 不是线程安全的，多线程下会出错。

错误写法：

// 错误：使用SimpleDateFormat（非线程安全），且未指定时区
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
String timeStr = sdf.format(new Date()); // 依赖JVM默认时区

正确写法：使用 java.time 包（Java 8+），明确指定时区。

// 正确：使用LocalDateTime和ZonedDateTime
public String formatTime(LocalDateTime localDateTime) {// 明确指定时区，例如北京时间ZonedDateTime zonedTime = localDateTime.atZone(ZoneId.of("Asia/Shanghai"));DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");return zonedTime.format(formatter);
}

复现与修复：在服务器上设置不同TZ环境变量运行代码。错误写法输出时间随服务器时区变化，正确写法始终输出指定时区的时间。参考Java SE开发者文档，DateTimeFormatter 是不可变的、线程安全的，性能优于 SimpleDateFormat。

坑五：N+1查询的性能黑洞

现象：查询100个订单，每个订单要查100个用户信息。数据库执行了101次查询，接口耗时5秒。

根本原因： ORM框架的懒加载陷阱。在循环中访问关联对象，触发多次单条查询。

错误写法：

// 错误：循环中访问关联对象，触发N次查询
List<Order> orders = orderMapper.selectAll();
for (Order order : orders) {User user = order.getUser(); // 每次调用都会执行一次 select * from user where id=?System.out.println(user.getName());
}

正确写法：使用预加载（Eager Loading）或批量查询。在MyBatis中，使用 collection 标签配置嵌套查询，并确保使用 fetchType="JOIN" 或批量加载。

// 正确：使用JOIN查询一次性获取数据
// Mapper XML
// <select id="selectAllWithUser" resultType="Order">
//   SELECT o.*, u.name as user_name
//   FROM orders o
//   LEFT JOIN users u ON o.user_id = u.id
// </select>

复现与修复：开启SQL日志，错误写法下看到101条SQL语句。正确写法下只有1条SQL语句。性能提升10倍以上。