川川和洋洋实战项目避坑指南：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里也没有，下次请求还会进来查DB
user = 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次查询
ListOrder 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倍以上。
规避建议与总结
这些坑，每一个都可能在你的实战项目中重现。面试时被问到原理，答不上来，不是因为你没写过代码，而是因为你只知其然，不知其所以然。
并发问题：永远不要相信应用层的“先查后改”，用数据库的原子操作。
缓存问题：空值缓存+布隆过滤器是标配，参考Redis官方文档设置合理的过期时间。
事务问题：显式声明 rollbackFor，不要吞异常。
时间问题：使用 java.time 包，明确时区。
查询问题：警惕N+1，使用JOIN或批量加载。
技术没有银弹，但有避坑指南。把这些原理刻在脑子里，面试时才能从容应对。
还有什么不懂的？评论区留言挨个回。 特别是关于分布式事务、消息队列幂等性的问题，最近问的人很多，我会专门写一篇。 
长河君 · 2026/9/21 19:30:59 · 阅读 1.2k 川川和洋洋实战项目避坑指南：5个致命Bug让面试直接挂
川川和洋洋实战项目避坑指南：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里也没有，下次请求还会进来查DB
user = 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次查询
ListOrder 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倍以上。
规避建议与总结
这些坑，每一个都可能在你的实战项目中重现。面试时被问到原理，答不上来，不是因为你没写过代码，而是因为你只知其然，不知其所以然。
并发问题：永远不要相信应用层的“先查后改”，用数据库的原子操作。
缓存问题：空值缓存+布隆过滤器是标配，参考Redis官方文档设置合理的过期时间。
事务问题：显式声明 rollbackFor，不要吞异常。
时间问题：使用 java.time 包，明确时区。
查询问题：警惕N+1，使用JOIN或批量加载。
技术没有银弹，但有避坑指南。把这些原理刻在脑子里，面试时才能从容应对。
还有什么不懂的？评论区留言挨个回。 特别是关于分布式事务、消息队列幂等性的问题，最近问的人很多，我会专门写一篇。