3个惨痛教训：我的汤姆猫2面试必问的避坑指南

面试官问：“讲讲你的并发处理机制，为什么用这个锁？”我愣了三秒，脑子一片空白。这种“面试必问”却答不上来的尴尬，每个后端人都经历过。

别笑，我也踩过。直到把【我的汤姆猫2】这个案例拆透，才发现很多坑根本不是技术难，而是对底层原理理解浮于表面。今天不聊虚的，直接上真实项目里的三个致命坑，全是血泪换来的。

坑一：内存泄漏伪装成性能瓶颈

现象： 服务运行三天后，CPU占用率缓慢爬升至80%，响应时间从50ms飙到2s。重启服务立刻恢复。监控面板显示内存使用率持续上涨，但无明显GC峰值。

根本原因： 在【我的汤姆猫2】的订单处理模块中，我们使用了HashMap缓存用户会话数据。问题出在：每次用户登录时，put了新Key，但从未remove过期Key。更致命的是，Value对象持有对数据库连接的引用，导致连接池无法回收。

这不是典型的内存泄漏（对象被GC回收），而是逻辑泄漏——对象本该释放，却被强引用链拖住。

错误写法：

// 错误：缓存无淘汰机制，连接对象被强引用
private static final Map<String, UserSession> sessionCache = new HashMap<>();public void login(String userId) {UserSession session = new UserSession();session.setDbConnection(getConnection()); // 危险：持有连接引用sessionCache.put(userId, session); // 永不删除
}public void logout(String userId) {// 遗漏：未从缓存中移除sessionCache.get(userId).getDbConnection().close();
}

正确写法：

// 正确：使用WeakReference + 定时清理
private static final Map<String, WeakReference<UserSession>> sessionCache = new ConcurrentHashMap<>();public void login(String userId) {UserSession session = new UserSession();session.setDbConnection(getConnection());sessionCache.put(userId, new WeakReference<>(session));
}public void logout(String userId) {WeakReference<UserSession> ref = sessionCache.remove(userId);if (ref != null && ref.get() != null) {ref.get().getDbConnection().close();}
}// 补充：定时任务清理失效引用
@Scheduled(fixedRate = 60000)
public void cleanExpiredSessions() {sessionCache.entrySet().removeIf(e -> e.getValue().get() == null);
}

复现与修复： 在测试环境模拟1000个用户登录不登出，监控JVM堆内存。错误写法下，30分钟后堆内存增长120MB；正确写法下，增长仅2MB（弱引用对象被GC回收）。

规避建议：

所有缓存必须设置最大容量或TTL，禁止无限增长
缓存Value中禁止持有外部资源引用（连接、流、线程）
定期用jmap -histo:live <pid>检查对象实例数，发现异常增长立即排查

坑二：SQL注入藏在“安全”的ORM背后

现象： 生产环境被黑，数据库被拖库。安全审计发现，漏洞来自【我的汤姆猫2】的用户查询接口。讽刺的是，我们全程使用MyBatis，以为ORM天然免疫SQL注入。

根本原因： MyBatis的#{}和${}区别没搞清楚。在动态排序字段场景下，我们误用了${}拼接用户输入。MyBatis文档明确警告：${}是字符串替换，不经过预编译，直接拼接进SQL语句。

错误写法：

<!-- 错误：排序字段使用${}，用户可注入恶意SQL -->
<select id="getUsers" resultType="User">SELECT * FROM users<where><if test="username != null">AND username = #{username}</if></where>ORDER BY ${sortField} ${sortOrder}
</select>

攻击者传入sortField=id; DROP TABLE users--，MyBatis直接替换，SQL变成：

SELECT * FROM users ORDER BY id; DROP TABLE users--

正确写法：

<!-- 正确：白名单校验 + #{}预编译 -->
<select id="getUsers" resultType="User">SELECT * FROM users<where><if test="username != null">AND username = #{username}</if></where>ORDER BY<choose><when test="sortField == 'id'">id</when><when test="sortField == 'name'">name</when><when test="sortField == 'createdAt'">created_at</when><otherwise>id</otherwise></choose><choose><when test="sortOrder == 'ASC'">ASC</when><otherwise>DESC</otherwise></choose>
</select>

复现与修复： 用SQLMap扫描器测试，错误写法下100%触发注入；正确写法下扫描器报0漏洞。修复后，增加单元测试覆盖所有排序字段组合，确保白名单完整。

规避建议：

严禁在MyBatis XML中使用${}处理用户输入
动态字段名必须白名单校验，禁止动态拼接
启用MyBatis的useGeneratedKeys和预编译，确保所有参数走?占位符
部署前用OWASP ZAP或SQLMap做自动化扫描，纳入CI/CD流程

坑三：线程池配置“拍脑袋”

现象： 【我的汤姆猫2】的支付回调接口，高峰期偶发超时。日志显示大量线程阻塞在await，CPU却只有30%利用率。重启无效，扩容也没用。

根本原因： 线程池核心参数完全凭感觉配置：corePoolSize=10，maxPoolSize=100，queue=LinkedBlockingQueue()（无界）。问题在于：

无界队列导致任务堆积，线程池永远不会扩容到maxPoolSize
支付回调涉及外部HTTP调用，平均耗时500ms，10个核心线程只能处理20TPS
队列无限增长，内存耗尽前不会触发拒绝策略

错误写法：

// 错误：无界队列 + 不合理线程数
ExecutorService paymentPool = new ThreadPoolExecutor(10,                              // corePoolSize100,                             // maxPoolSize（永远用不到）60L, TimeUnit.SECONDS,new LinkedBlockingQueue<>(),     // 无界队列，任务堆积new ThreadFactoryBuilder().setNameFormat("payment-%d").build(),new ThreadPoolExecutor.AbortPolicy()  // 永远触发不了
);

正确写法：

// 正确：有界队列 + 基于压测的参数
ExecutorService paymentPool = new ThreadPoolExecutor(50,                              // corePoolSize = 目标TPS / 单线程TPS50,                              // maxPoolSize = corePoolSize（IO密集型）60L, TimeUnit.SECONDS,new LinkedBlockingQueue<>(1000), // 有界队列，防止OOMnew ThreadFactoryBuilder().setNameFormat("payment-%d").build(),new ThreadPoolExecutor.CallerRunsPolicy()  // 降级策略：调用者线程执行
);

参数计算逻辑：