java案例复盘提到的技战术短板在哪？

本文目录导读：

1. 并发与线程安全（“锁”的误用）
2. 性能与调优（“索引”与“内存”的忽视）
3. 事务管理（“范围”与“失效”）
4. 代码设计与架构（“面向过程”的回归）
5. 资源管理与I/O
6. 复盘的终极短板

在Java案例复盘（特别是团队内部的技术复盘、代码审查或面试复盘）中，提到的“技战术短板”通常不是指某个具体的语法错误，而是指在面对复杂业务或高并发场景下，“经验不足”与“思维定势”导致的问题。

如果要把这些短板梳理清楚，可以归结为以下五个维度的“重灾区”：

并发与线程安全（“锁”的误用）

这是最容易暴露短板的地方,也是最经典的技术考点。

• 锁粒度过粗：为了图省事，直接给整个方法或大段代码加 synchronized 或 Lock，导致系统吞吐量急剧下降，甚至引发死锁，复盘时往往发现,其实只需要锁住共享变量那一行代码。
• 并发容器使用不当：以为用了 ConcurrentHashMap 就万事大吉，却在复合操作（如“先查后改”或 putIfAbsent 与 get 之间的业务逻辑）上没有加锁，导致数据不一致，这是典型的“知道API，但不懂语义”的短板。
• 可见性问题：忽略了 volatile 的适用场景（只保证可见性，不保证原子性），或者错误地认为加了 volatile 就能解决所有并发问题。

性能与调优（“索引”与“内存”的忽视）

业务跑得通不代表技术过关,性能瓶颈往往是复盘的重头戏。

• SQL与索引陷阱：在Java中使用ORM（如MyBatis或Hibernate）时，没有关注生成的SQL是否能走索引，常见短板是在数据库查询条件前加了隐式转换、对索引列使用了函数运算，或者用了“前模糊”查询（LIKE '%xx'），导致索引失效,全表扫描拖垮数据库。
• JVM参数与内存泄漏：遇到OOM（内存溢出），第一反应是加堆内存，而不是通过 jmap 或 MAT 分析对象存活率，短板在于没有排查是否存在大对象未释放、静态集合容量无限增长（伪内存泄漏）或InputStream未关闭等低级但致命的问题。
• 频繁的GC（垃圾回收）：复盘时发现代码在循环体中创建了大量短生命周期对象，导致年轻代频繁触发Minor GC，不仅慢，而且造成CPU使用率极高，这反映了对对象复用和逃逸分析的理解不足。

事务管理（“范围”与“失效”）

交易系统中最怕的就是事务问题。

• 事务粒度过大：在 @Transactional 方法中执行了耗时的网络调用或大量不相关的无关数据库操作，导致数据库连接长期被占用,连接池被耗尽。
• 事务自调用失效：在同一个类中，this 调用了另一个带 @Transactional 的方法，因为Spring AOP基于代理机制，事务直接失效,这是非常经典且隐蔽的短板。
• 异常捕获导致回滚失败：在方法内部用 try-catch 吞掉了异常，且未抛出RuntimeException，导致事务无法回滚,产生脏数据。

代码设计与架构（“面向过程”的回归）

• 上帝类/长方法：类中塞满了各种不相关的功能，方法体动辄几百行，严重依赖 if-else 和临时的 Map 传参，复盘时常常发现，本应使用策略模式或状态模式的地方，被写成了面向过程的流程代码,导致后续需求难以扩展。
• 缺乏防御性编程：对下游接口返回的数据不校验，直接 get 或强转，导致 NullPointerException 或 ClassCastException 在线上偶发,非常被动。
• 调用链冗长：上下游调用之间同步阻塞，没有使用异步化（如MQ或CompletableFuture）来剥离非核心链路，导致接口RT（响应时间）极长,拖垮整体性能。

资源管理与I/O

• 连接泄漏：手动获取数据库连接、Redis连接或HttpClient连接，却因为异常分支忘了在 finally 中关闭，或者没有使用 try-with-resources,导致连接池耗尽。
• 非阻塞阻塞用：在使用 Netty 或 WebFlux 等非阻塞框架时，在事件循环线程里执行了阻塞操作（如强行走JDBC或Thread.sleep），导致整个事件循环卡死，线程被挂起,这是架构层面的隐形杀手。

复盘的终极短板

如果把这些具体问题抽象成一句话，最大的技战术短板其实是“缺乏底层原理与业务场景的映射能力”。

• 遇到问题：只求“跑通”，不求“跑稳”。
• 排查问题：喜欢猜（重启、加日志），而不是通过观测工具（Arthas、jstack、监控大盘）定位。
• 解决问题：喜欢用“轮子”（到处拷代码），但因为不懂内部实现,导致水土不服。

给复盘的建议：在复盘报告中，不要只写“我们用了并发HashMap”或“我们加了索引”，建议写清楚：我为什么选这个方案？在当时的数据规模下，这个方案的瓶颈会出现在哪里？如果数据量再大十倍，引擎是否会崩溃？ 这种系统性的逻辑推演能力，才是真正需要补的“技术战术”短板。